home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / clients / 244 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  1.4 KB
  1. Xref: sparky comp.client-server:244 comp.sys.sun.misc:5927
  2. Path: sparky!uunet!mcsun!sun4nl!cwi.nl!guido
  3. From: guido@cwi.nl (Guido van Rossum)
  4. Newsgroups: comp.client-server,comp.sys.sun.misc
  5. Subject: Sun RPC time-out question
  6. Message-ID: <8411@charon.cwi.nl>
  7. Date: 19 Dec 92 11:29:21 GMT
  8. Sender: news@cwi.nl
  9. Followup-To: comp.client-server
  10. Lines: 24
  11.  
  12. Is there an expert on Sun RPC in this group?
  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.  
  27. Note that I need to know how the existing Sun RPC implementation
  28. handles this situation, not how it could be done in a hypothetical
  29. system (I know all about Amoeba's RPC, for instance).
  30.  
  31. Pointers to sources or documents are welcome!
  32.  
  33. --Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
  34. "That was never five minutes just now!"
  35. "I'm afraid it was."
  36.