RFC 2055 (rfc2055) - Page 2 of 10
WebNFS Server Specification
Alternative Format: Original Text Document
RFC 2055 WebNFS Server Specification October 1996
1. Introduction
The NFS protocol provides access to shared filesystems across
networks. It is intended to be machine, operating system, network
architecture, and transport independent. The protocol currently
exists in two versions: version 2 [RFC 1094] and version 3 [RFC 1813],
both built on Sun RPC [RFC 1831] and its associated eXternal Data
Representation (XDR) [RFC 1832]. This document assumes some
familiarity with the NFS protocol and underlying RPC protocols.
WebNFS servers implement semantic extensions to both versions of the
NFS protocol to support a lightweight binding mechanism for
conventional or web browser clients that need to communicate with NFS
servers across the Internet. a WebNFS server supports the public
filehandle and multi-component lookup features described herein, as
well as meeting some additional requirements.
For a description of WebNFS client requirements, read RFC 2054.
2. TCP vs UDP
The NFS protocol is most well known for its use of UDP which performs
acceptably on local area networks. However, on wide area networks
with error prone, high-latency connections and bandwidth contention,
TCP is well respected for its congestion control and superior error
handling. A growing number of NFS implementations now support the
NFS protocol over TCP connections.
A WebNFS client will first attempt to connect to its server with a
TCP connection. If the server refuses the connection, the client
will attempt to use UDP. All WebNFS servers should support client
use of TCP and must support UDP.
3. Well-known Port
While Internet protocols are generally identified by registered port
number assignments, RPC based protocols register a 32 bit program
number and a dynamically assigned port with the portmap service which
is registered on the well-known port 111. Since the NFS protocol is
RPC-based, NFS servers register their port assignment with the
portmap service.
NFS servers are constrained by a requirement to re-register at the
same port after a server crash and recovery so that clients can
recover simply by retransmitting an RPC request until a response is
received. This is simpler than the alternative of having the client
repeatedly check with the portmap service for a new port assignment.
NFS servers typically achieve this port invariance by registering a
Callaghan Informational