For example, neither FTP nor HTTP supports the notion of file locking or exclusive access. Both of these protocols are designed for sequential transmission of the entire file and do not work to read bits and pieces from different areas of a file (random access).

Although the upcoming HTTP version 1.1 performs random access and greatly improves network efficiency, it cannot perform many basic file system services. In addition, it cannot report how much free space is left on a volume, has a poor concept of directories and lacks several rudimentary file system functions, such as the ability to rename a file.

Currently, using the Internet to edit documents involves downloading a file via HTTP or FTP, editing the file and subsequently uploading the entire file again. Adopting an Internet file system would permit in-place editing and seamless remote access, enabling direct file editing via an application and eliminating the download/upload burden. Furthermore, many collaborative applications, which are designed to work via a shared directory , could become instantly effective without having to be rewri tten for the Internet, perhaps as a client/ server application.

WebNFS = NFS + Tweaks The WebNFS protocol serves as a proposed standard to the Internet Engineering Task Force (IETF) from Sun Microsystems, creator of Network File System (NFS). NFS has been widely adopted as the de facto standard for Unix-based file servers, and it also has a healthy following in the PC market. In fact, NFS client software is available from numerous vendors for practically every operating system, and more than 50 percent of all installed NFS clients run on Microsoft Windows-based PCs. The most common flavor is NFS version 2. Version 3 is an update of the NFS protocol that addresses common limitations with version 2. WebNFS simply builds on NFS version 3, adding features to work better over the Internet.

The first Internet tweak requires WebNFS to run over TCP. Currently, NFS runs over User Datagram Protocol (UDP) or TCP. It more often runs over UDP. However, TCP is far better-suited for communication over the cha otic Internet: TCP guarantees delivery even if packets get lost, it guarantees information delivery in the proper order, and it contains network-congestion and flow-control algorithms.

Another tweak Sun made to NFS lets WebNFS work across Internet firewalls. NFS versions 2 and 3 use a remote procedure call (RPC) mechanism in several places. To use this RPC, the client sends a service request to the "portmapper" process, which is listening on the server at a well-known IP port. The portmapper responds with the port number where the NFS server can be found.

The problem is that few Internet firewalls are sophisticated enough to follow this transaction; most firewalls deal only with TCP communication on static, well-known ports. Since NFS already uses port 2049, it makes sense that WebNFS requires clients to bypass the portmapper process and simply connect to port 2049.

Obtaining a file handle from the NFS MOUNT daemon, which initializes a connect ion to an NFS server, also requires the portmapper. We bNFS avoids this step by using public file handles, analogous to a well-known port. These steps not only permit WebNFS to work across a firewall, they also significantly reduce the amount of back-and-forth communication, or turnarounds, required to initialize a connection. Considering the high network latency of the Internet, minimizing turnarounds has a profound impact on increasing responsiveness. When compared to NFS, the WebNFS protocol also reduces the number of turnarounds in other areas of the specification.

To download an Adobe Acrobat .pdf format version of Web File System Features charts, click here.