home *** CD-ROM | disk | FTP | other *** search
- 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
-
-