Making a named pipe over NFS

[Thomas Truscott]

> > NFS does not support named pipes, because they (like devices) require
> > state on the server, and NFS servers are stateless.  FYI, RFS (that
> > other distributed file system) does support named pipes.
> 
> A Sun-3 client running SunOS 4.0_Export _can_ create a named pipe
> in an NFS file system mounted from a Sun-3 server.
> NFS servers don't maintain _connection_ state, but surely the state
> which is relevant to a named pipe is the _contents_.

Give me a break!  Modern versions of NFS can create named pipe _entries_
in remote filesystems, but the _contents_ of the pipe never
leave the client.  Processes on different clients
CAN NOT share data using a common named pipe,
because under NFS it just doesn't work that way.
Each different client gets its own local instance of the pipe.
To say that "NFS supports remote named pipes" is highly misleading.

FLAME ON
A lot of vendor literature for improved NFS
says things like "Access to named pipes and device files
is now supported with NFS" (usually along with other statements
such as "the network is the computer").
Your typical UNIX person might misinterpret this to mean
that NFS can now share the contents of remote named pipes
and that NFS can now do I/O to peripheral devices that are physically
connected to remote systems.

In fact, this misinterpretation happens a lot.
Our group at RTI has a neat distributed file/computing system
called Freedomnet, but when talking to vendors or company management
the following happens all too often:

FN:	Freedomnet supports remote devices and named pipes.
V/C:	"So does NFS!"

FN:	Freedomnet supports all locking mechanisms.
V/C:	"So does NFS!"  (Yeh.  lock daemon from hell.)

FN:	Freedomnet supports remote execution.
V/C.	"So does NFS!"

NFS does not support these things (for any normal meaning
of the word "support"), and never intended to,
but surprisingly few people are aware of that.
You can see how this can be rather frustrating.
	Tom Truscott