RFC 2054 (rfc2054) - Page 3 of 16
WebNFS Client Specification
Alternative Format: Original Text Document
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