Path: utzoo!attcan!uunet!lll-winken!sun-barr!newstop!sun!terra.Eng.Sun.COM!brent From: brent@terra.Eng.Sun.COM (Brent Callaghan) Newsgroups: comp.protocols.nfs Subject: Re: NeFS -- where is the multiplexer? Keywords: NeFS, NFS Message-ID: <138584@sun.Eng.Sun.COM> Date: 9 Jul 90 17:54:43 GMT References: <1086@cluster.cs.su.oz> Sender: news@sun.Eng.Sun.COM Lines: 61 In article <1086@cluster.cs.su.oz>, bruce@cs.su.oz.au writes: > 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. For the first cut at this protocol we're not proposing anything very radical when it comes to NeFS "processes". Indeed, there's no process support at all (c.f. NeWS). The client typically sends a request and blocks while the request is executed on the server. This isn't any different from the RPC model that NFS uses. A request will run just as long as the server wants it to i.e. until it completes or it runs out of resources: memory or execution quota. It's possible that the a client (probably not a Unix one) could construct a request that could take a long time e.g. copy a big file on the server or walk the file tree doing a "find". The client has no way of knowing how long the request will take or indeed whether the request was received by the server at all (assuming something like UDP is used as the transport). The protocol already has the hooks to address these problems. There's no reason why a request should not be able to generate multiple responses. A request could be constructed that sends a "check-in" response back to the client when it gets to the server and begins execution. It could also generate progress reports to the client during execution at intervals smaller than the client's timeout. It gets tricky if the client wants to cancel a request that's executing on the server. For instance, a find executing on the server may send a response back to the client for each filesystem object as it is located. If the client receives a response that indicates that there's no point in further searching - how does it refer to the request in progress ? Something as simple as a "getpid" and "kill" ops could do the trick. Several have suggested adding a facility that lets a request fork multiple processes on the server where appropriate e.g. a search of a filesystem tree. This is a relatively rare filesystem operation. The extra complexity doesn't justify itself (KISS). -- Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051