Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.internals
Subject: Re: (was slashes, now NFS devices)
Message-ID: <1991Mar9.084253.23423@Think.COM>
Date: 9 Mar 91 08:42:53 GMT
References: <12713:Mar708:07:3591@kramden.acf.nyu.edu> <1991Mar8.074048.13105@Think.COM> <20375:Mar906:16:4291@kramden.acf.nyu.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 61

In article <20375:Mar906:16:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>NFS is (supposedly) a filesystem. Somewhere inside the implementation is
>the NFS protocol.

Despite the expansion of the initials, NFS is not a filesystem.  It's a
remote file system access method.  A filesystem defines things like file
layout, disk allocation, etc., and NFS specifies none of these things.

>What these people are missing is that this ``statelessness'' is
>absolutely irrelevant to the external NFS filesystem. Files have state,
>and somehow NFS manages to work for files even though the server process
>doesn't keep its own state. Similarly, just because devices have state
>does *not* mean that NFS needs a ``fundamental change'' for them to
>work.

The statelessness isn't completely irrelevant.  If the server is required
to maintain state, then the protocol must include mechanisms for dealing
with client and server states getting out of sync.  The most visible effect
of this is that server crashes don't result in clients losing data (unless,
of course, the problem that caused the crash also affected the file system,
e.g. the crash was due to a head crash); it just looks like the server is
being very slow.

You're right, designing a protocol around stateless servers does provide an
easy excuse for the designers.  However, it is also a way to design a
relatively simple protocol, since resynchronization protocols can be a
difficult to design and implement.  If one of your goals is to encourage
many vendors to implement your protocol, with the hope of it becoming a de
facto standard, simplicity is a feature.  There are pros and cons of
stateful and stateless protocols.

Similar issues arise in other layers of network protocols.  The most
obvious one in recent years is the choice of connection-oriented vs
connectionless network layer protocols.  In TCP/IP, modules in the network
layer doesn't maintain state (e.g. routers process every packet
independently); instead, the transport (for TCP) or application layer (for
UDP) must maintain any necessary state.  In the ISO protocol stack, X.25 is
used at the network layer, and its virtual circuits are stateful.
Stateless network layers can automatically deal with component failures
when redundant components are available; stateful network layers cannot,
and therefore require upper layers to do so (this is one of the jobs of the
ISO session layer, and the reason why TCP/IP doesn't have an equivalent
layer).

By the way, there are a few aspects to the NFS protocol that make
completely stateless servers less useful.  There are a couple of operations
that aren't idempotent.  Since NFS uses an unreliable transport layer,
duplicate requests can be received.  A cache of recent transaction ids is
maintained so that duplicates can be recognized.  This is not required by
the protocol spec (I'm not sure it mentions retransmission at all), but it
is a good idea.

>[unmount /soapbox]

I'm sure you'll mount it again soon enough....

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar