🚀 go-pugleaf

Submitted-by: iand@labtam.labtam.oz.au (Ian Donaldson)

johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>Yeah.  The problem is that although the NFS calls are all individually
>idempotent, they aren't in combination, and there is no way to enforce
>exactly-once semantics in NFS.  Here's the classic example:

>client					server

>creat("foo")          ---------->	truncates "foo"
>		      +----------       ack creat
>		      | slow network
>creat("foo)" retry ---|------+
>receive ack       <---+      |
>write data		-----|--->      writes data
>receive ack             <----|---   	ack write
>			     +--->	truncates file again
>discard dup response         <---	ack creat

>So all of the requests were executed and acked, but the repeated creat()
>threw away the data.  Oops.

If each NFS_create transmission request had a different xid wouldn't this 
problem vanish?  This is provided that you don't start writing until you 
get a response to the last request you sent (ie: ignoring arrivals
of delayed earlier sent ones).

Isn't the current problem that many NFS client implementations
use clnt_call() once and it uses the same xid in each request it retransmits,
and returns when it gets any response with a matching xid?  Thus it doesn't
know if there are any further requests still on the way to the server,
because it can't tell which response it got.

If a different xid is used in each request, the host wouldn't need
to keep a cache of request-id's at all as each request would have
a unique xid, and this would make the problem of the "state" that
the server temporarily keeps about such requests, go away.  

The client would need to check for obvious errors in replies due to duplicated
attempts to do things that change server state such as mkdir/rmdir/unlink/chown,
due to lost replies from the server.

Anyway, isn't this also only a problem with popular UDP based NFS 
implementations?  With TCP this problem shouldn't exist.  

Ian Donaldson

Email:  iand@labtam.labtam.oz.au
Phone:  +61-3-587-1444
Fax:    +61-3-580-5581

[ I think followups should go to comp.protocols.nfs -- mod ]

Volume-Number: Volume 29, Number 38