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.