home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / clients / 245 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.3 KB

  1. Path: sparky!uunet!usc!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!male.EBay.Sun.COM!exodus.Eng.Sun.COM!appserv.Eng.Sun.COM!camilla.Eng.Sun.COM!khale
  2. From: khale@camilla.Eng.Sun.COM (Abhijit Khale)
  3. Newsgroups: comp.client-server
  4. Subject: Re: Sun RPC time-out question
  5. Date: 19 Dec 1992 16:26:25 GMT
  6. Organization: Sun
  7. Lines: 40
  8. Message-ID: <lj6j9hINN6mk@appserv.Eng.Sun.COM>
  9. References: <8411@charon.cwi.nl>
  10. NNTP-Posting-Host: camilla
  11.  
  12. In article <8411@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
  13.  
  14. >I am in the process of re-implementing Sun RPC.  All the documentation
  15. >I have are RFC1014 (XDR) and RFC1057 (RPC), and RFC1094 (NFS).  I have
  16. >a question that isn't answered by these documents:
  17. >
  18. >When using the UDP version, how does the client recover from lost
  19. >packets?  When the call packet is lost, a simple retransmission is
  20. >enough, however, when a reply packet is lost, a retransmission can
  21. >cause the request to be executed twice.  How does e.g. an NFS client
  22. >handle this if the request is not idempotent (like RENAME)?  Is there
  23. >a way for the client to tell from the failing reply from the second
  24. >try that the first try must have succeeded even though the response
  25. >got lost?
  26. >Note that I need to know how the existing Sun RPC implementation
  27. >handles this situation, not how it could be done in a hypothetical
  28. >system (I know all about Amoeba's RPC, for instance).
  29.  
  30. Sun RPC over UDP does not guarantee at-most-once delivery. The way Sun RPC
  31. over UDP (or any connectionless transport) works is to retransmit a request
  32. repeatedly till either an answer is recieved or a total timeout value is
  33. reached. So it is possible for the same request to be processed twice. You can
  34. reduce the probability of this happening a lot by doing a svc_udpenablecache()
  35. (svc_dgenablecache() in TIRPC) on the server side. This sets up a server side
  36. cache which throws away duplicate requests. 
  37.  
  38. >Pointers to sources or documents are welcome!
  39.  
  40. Sun's freely licensed RPC/XDR implementation, RPCSRC 4.0, is 
  41. available via anonymous ftp from bcm.tmc.edu and by email from the
  42. archive-server@bcm.tmc.edu.
  43.  
  44. If you use the archive server, send mail to archive-server@bcm.tmc.edu
  45. with a Subject of "send nfs index" to see all the names of the files.
  46. Sending a message with the Subject "help" will return to you more
  47. information about the archive server itself.
  48.  
  49. Abhijit
  50.  
  51.  
  52.