home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / clients / 248 next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!news2me.EBay.Sun.COM!seven-up.East.Sun.COM!sungy!stasys!alanya!lupe
  2. From: lupe@ukw.uucp (Lupe Christoph)
  3. Newsgroups: comp.client-server
  4. Subject: Re: Sun RPC time-out question
  5. Message-ID: <1992Dec20.164620.13282@ukw.uucp>
  6. Date: 20 Dec 92 16:46:20 GMT
  7. References: <8411@charon.cwi.nl>
  8. Sender: news@stasys.sta.sub.org
  9. Organization: cic
  10. Lines: 40
  11.  
  12. guido@cwi.nl (Guido van Rossum) writes:
  13.  
  14. >Is there an expert on Sun RPC in this group?
  15.  
  16. >I am in the process of re-implementing Sun RPC.  All the documentation
  17. >I have are RFC1014 (XDR) and RFC1057 (RPC), and RFC1094 (NFS).  I have
  18. >a question that isn't answered by these documents:
  19.  
  20. I'm wondering why you do that, given that Sun's implementation is
  21. publicxly available in source.
  22.  
  23. >When using the UDP version, how does the client recover from lost
  24. >packets?  When the call packet is lost, a simple retransmission is
  25. >enough, however, when a reply packet is lost, a retransmission can
  26. >cause the request to be executed twice.  How does e.g. an NFS client
  27. >handle this if the request is not idempotent (like RENAME)?  Is there
  28. >a way for the client to tell from the failing reply from the second
  29. >try that the first try must have succeeded even though the response
  30. >got lost?
  31.  
  32. A client cannot know if his request got lost, or the response. Both
  33. result in a timeout. The client will retransmit or give up, depending
  34. on circumstance.
  35.  
  36. >Note that I need to know how the existing Sun RPC implementation
  37. >handles this situation, not how it could be done in a hypothetical
  38. >system (I know all about Amoeba's RPC, for instance).
  39.  
  40. If the request is not idempotent, you need to activate the server
  41. cache with svcudp_enablecache(). Note that is an undocumented
  42. function. Get the 4.0 rpcxdr source and look there for details.
  43.  
  44. >Pointers to sources or documents are welcome!
  45.  
  46. Sources: see above, docs: RTFS ;-)
  47. -- 
  48. | ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
  49. | lupe@ukw.UUCP       (German EUNet, domain)     |  This is an unofficial  |
  50. | suninfo!alanya!lupe (Sun Germany)              |  opinion of Christoph & |
  51. | Res non sunt complicanda praeter necessitatem. |  Imschweiler Consulting |
  52.