The Poor Man's WAN Optimizer

I have a problem. We have just opened an office in Toronto, which connects to our headquarters in Montreal through a VPN. No problem, it happens a lot everywhere. The problem is that the team lead in Toronto needs to access files on a Samba server here in Montreal. Whenever he tries to open a file, it locks him into Read-Only mode.

The answer is: chatty protocols do not work on wide are networks (WAN). Period. Chatty, here, means CIFS (formerly SMB), the protocol that makes Windows shares work; and NFS, the venerable protocol that permits easy mounting of network shares for UNIX.

Usually, when using a request-reponse protocol such as HTTP, FTP, sFTP or scp, the application or operating system issues a solitary command to get a file: GET URI "http://example.com/helloworld.html HTTP/1.0" Whoosh, over it goes. Although request-reponse protocols are not streaming per-se, they are not horribly slow over long distances. The bottleneck will be simply bandwidth.

On the other hand, chatty protocols issue many commands per file. As a result, latency over long distances will take affect: The client computer sends a command. The file server receives the command. The file server sends a 64K part of the file. Wait. Another command, another reception of the command, another part of the file. Wait. And so on. Here, the bottleneck is the speed of light.

To improve performance on SMB/CIFS over the LAN, the protocol uses "opportunistic locking," which controls the client file cacheing. Unfortunately, latency triggers the locks and the user finds himself using a read-only copy of the file he opened.

In order to get past the limitations of chatty protocols over WANs, wide-area file systems (WAFS) were developed, such as OpenAFS (IBM's version of the Andrews distributed file system) and Distributed File System (Windows). WAFS use the principle of having centralized files synchronized to remote servers, permitting the use of local area networks (LANs) for which the chatty protocols were designed. WAFS are limited in functionality and to deal with the limitations, WAN Optimizers were created. Among the many other benefits that WAN Optimizers bring (such as reducing bandwidth use), they anticipate and execute chatty protocol commands and then bundle the results over a stream.

Commercial WAN Optimizers are expensive! Open Source WAN Optimizers seem to be either dormant projects, new projects, or in the case of the most mature project, repellent due to the unfortunate web skills of its developer.

Now, I could just upgrade Samba to 3.6 and see if SMB 2.0 helps, but that will take a whack of change management. I could permit SCP directly to the file server, but no one is permitted shell access to the file server except IT, and changing the default login shell to sftp-server will lock IT out.

The other solution is kludgy but will work.

1. Create a linux server that permits shell access
2. Create a script that permits a user to mount his network drive
3. Have the user SSH into the linux server with PuTTY and execute the script
4. Use sFTP through, say, FileZilla, to get a local copy of the file through the mountpoint.
5. Use sFTP to replace the central copy with the local copy.
6. The user, through SSH, executes another script to umount the network drive on the linux server (this is important and probably abused)
7. ...
8. Profit!