RFC 2054 (rfc2054) - Page 3 of 16

WebNFS Client Specification

RFC 2054              WebNFS Client Specification           October 1996


   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
   constant port assignment, 2049, for both UDP and TCP.

   To avoid the overhead of contacting the server's portmap service, and
   to facilitate transit through packet filtering firewalls, WebNFS
   clients optimistically assume that WebNFS servers register on port
   2049.  Most NFS servers use this port assignment already, so this
   client optimism is well justified. Refer to section 8 for further
   details on port binding.

4. NFS Version 3

   NFS version 3 corrects deficiencies in version 2 of the protocol as
   well as providing a number of features suitable to WebNFS clients
   accessing servers over high-latency, low-bandwidth connections.

4.1 Transfer Size

   NFS version 2 limited the amount of data in a single request or reply
   to 8 kilobytes.  This limit was based on what was then considered a
   reasonable upper bound on the amount of data that could be
   transmitted in a UDP datagram across an Ethernet.  The 8k transfer
   size limitation affects READ, WRITE, and READDIR requests. When using
   version 2, a WebNFS client must not transmit any request that exceeds
   the 8k transfer size.  Additionally, the client must be able to
   adjust its requests to suit servers that limit transfer sizes to
   values smaller than 8k.

   NFS version 3 removes the 8k limit, allowing the client and server to
   negotiate whatever limit they choose.  Larger transfer sizes are
   preferred since they require fewer READ or WRITE requests to transfer
   a given amount of data and utilize a TCP stream more efficiently.

   While the client can use the FSINFO procedure to request the server's
   maximum and preferred transfer sizes, in the interests of keeping the
   number of NFS requests to a minimum, WebNFS clients should
   optimistically choose a transfer size and make corrections if
   necessary based on the server's response.

   For instance, given that the file attributes returned with the
   filehandle from a LOOKUP request indicate that the file has a size of
   50k, the client might transmit a READ request for 50k.  If the server
   returns only 32k, then the client can assume that the server's



Callaghan                    Informational