RFC 1094 (rfc1094) - Page 2 of 27
NFS: Network File System Protocol specification
Alternative Format: Original Text Document
RFC 1094 NFS: Network File System March 1989
Specification is written using the RPC data description language.
For more information, see RFC 1014, "XDR: External Data
Representation Standard". Although automated RPC/XDR compilers exist
to generate server and client "stubs", NFS does not require their
use. Any software that provides equivalent functionality can be
used, and if the encoding is exactly the same it can interoperate
with other implementations of NFS.
1.3. Stateless Servers
The NFS protocol was intended to be as stateless as possible. That
is, a server should not need to maintain any protocol state
information about any of its clients in order to function correctly.
Stateless servers have a distinct advantage over stateful servers in
the event of a failure. With stateless servers, a client need only
retry a request until the server responds; it does not even need to
know that the server has crashed, or the network temporarily went
down. The client of a stateful server, on the other hand, needs to
either detect a server failure and rebuild the server's state when it
comes back up, or cause client operations to fail.
This may not sound like an important issue, but it affects the
protocol in some unexpected ways. We feel that it may be worth a bit
of extra complexity in the protocol to be able to write very simple
servers that do not require fancy crash recovery. Note that even if
a so-called "reliable" transport protocol such as TCP is used, the
client must still be able to handle interruptions of service by re-
opening connections when they time out. Thus, a stateless protocol
may actually simplify the implementation.
On the other hand, NFS deals with objects such as files and
directories that inherently have state -- what good would a file be
if it did not keep its contents intact? The goal was to not
introduce any extra state in the protocol itself. Inherently
stateful operations such as file or record locking, and remote
execution, were implemented as separate services, not described in
this document.
The basic way to simplify recovery was to make operations as
"idempotent" as possible (so that they can potentially be repeated).
Some operations in this version of the protocol did not attain this
goal; luckily most of the operations (such as Read and Write) are
idempotent. Also, most server failures occur between operations, not
between the receipt of an operation and the response. Finally,
although actual server failures may be rare, in complex networks,
failures of any network, router, or bridge may be indistinguishable
from a server failure.
Sun Microsystems, Inc.