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