home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0036.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  2.1 KB  |  56 lines

  1. Submitted-by: iand@labtam.labtam.oz.au (Ian Donaldson)
  2.  
  3. johnl@iecc.cambridge.ma.us (John R. Levine) writes:
  4. >Yeah.  The problem is that although the NFS calls are all individually
  5. >idempotent, they aren't in combination, and there is no way to enforce
  6. >exactly-once semantics in NFS.  Here's the classic example:
  7.  
  8. >client                    server
  9.  
  10. >creat("foo")          ---------->    truncates "foo"
  11. >              +----------       ack creat
  12. >              | slow network
  13. >creat("foo)" retry ---|------+
  14. >receive ack       <---+      |
  15. >write data        -----|--->      writes data
  16. >receive ack             <----|---       ack write
  17. >                 +--->    truncates file again
  18. >discard dup response         <---    ack creat
  19.  
  20. >So all of the requests were executed and acked, but the repeated creat()
  21. >threw away the data.  Oops.
  22.  
  23. If each NFS_create transmission request had a different xid wouldn't this 
  24. problem vanish?  This is provided that you don't start writing until you 
  25. get a response to the last request you sent (ie: ignoring arrivals
  26. of delayed earlier sent ones).
  27.  
  28. Isn't the current problem that many NFS client implementations
  29. use clnt_call() once and it uses the same xid in each request it retransmits,
  30. and returns when it gets any response with a matching xid?  Thus it doesn't
  31. know if there are any further requests still on the way to the server,
  32. because it can't tell which response it got.
  33.  
  34. If a different xid is used in each request, the host wouldn't need
  35. to keep a cache of request-id's at all as each request would have
  36. a unique xid, and this would make the problem of the "state" that
  37. the server temporarily keeps about such requests, go away.  
  38.  
  39. The client would need to check for obvious errors in replies due to duplicated
  40. attempts to do things that change server state such as mkdir/rmdir/unlink/chown,
  41. due to lost replies from the server.
  42.  
  43. Anyway, isn't this also only a problem with popular UDP based NFS 
  44. implementations?  With TCP this problem shouldn't exist.  
  45.  
  46. Ian Donaldson
  47.  
  48. Email:  iand@labtam.labtam.oz.au
  49. Phone:  +61-3-587-1444
  50. Fax:    +61-3-580-5581
  51.  
  52. [ I think followups should go to comp.protocols.nfs -- mod ]
  53.  
  54. Volume-Number: Volume 29, Number 38
  55.  
  56.