Path: utzoo!attcan!uunet!samsung!munnari.oz.au!metro!cluster!bruce@cs.su.oz.au
From: bruce@cs.su.oz.au
Newsgroups: comp.protocols.nfs
Subject: NeFS -- where is the multiplexer?
Keywords: NeFS, NFS
Message-ID: <1086@cluster.cs.su.oz>
Date: 8 Jul 90 07:06:13 GMT
Sender: news@cluster.cs.su.oz
Reply-To: bruce@cs.su.oz.au
Lines: 61

Under the NFS protocol, client requests can be handled by
a single NFS server running on the remote machine.
This single-threadedness is possible because of the simple nature of each supported
RPC operation, (and because of restrictions imposed by the mount
protocol) and the resultant fact that each RPC request is
known to be executable in "a short time" on the server.
(The popular use of multiple nfsd's (4?, 8?) is inspired by
considerations of efficiency rather than necessity.)

Typically, a heavily used NFS server will continue to
serve all clients fairly (but perhaps this is more by accident than
by design) due to the fairness implicit in the way that
the underlying protocol "passes up" incoming requests.
Moreover, clients can behave very simply in the face of missing
RPC replies -- they just assume that any outstanding calls have
been lost and retransmit them.

An NeFS server must provide an execution environment for each client
request rather than just provide access to a set of bounded procedure
calls, as is done by an NFS server.
This is necessary because of the generality of the Postscript
language -- it is possible to write and execute requests of unbounded
execution time.
We now start to see an NeFS server more as an operating system
than as a file server.
Under this view, each client request corresponds to a process.
Thus the structure of an NeFS server needs to be significantly more
complex -- or at least contain more arbitrary decisions -- than
an NFS server.

When we look at NeFS servers from this alternate perspective
questions arise.
How do I find out details about what NeFS "processes" are currently
running on the server?
How do I name one of these NeFS processes?
How do I kill (abort) such an NeFS process?
Does the Postcript language already support such primitives (or
was Postscript targeted at a uniprocessing environment)?
[These primitives don't appear to be mentioned in the NeFS document.]
What primitives are provided to allow NeFS processes to communicate
with each other?  How about with the other "regular" processes
concurrently running on the remote machine but outside of the NeFS server(s)?
How about communication with processes back on the client machine?
How do I debug an NeFS process?
How are NeFS processes scheduled (e.g. what granularity of time-slicing)?
Can NeFS operations block in general?  NFS operations can not block but
under NeFS both a precedent ("lock") and a mechanism (via suspension
of an NeFS process' execution) are provided.

Cheers,
bruce.

Bruce Janson
Basser Department of Computer Science
University of Sydney
Sydney, N.S.W., 2006
AUSTRALIA

Internet:	bruce@basser.cs.su.oz.au
Telephone:	+61-2-692-3264
Fax:		+61-2-692-3838