🚀 go-pugleaf

In article <8411@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:

>I am in the process of re-implementing Sun RPC.  All the documentation
>I have are RFC1014 (XDR) and RFC1057 (RPC), and RFC1094 (NFS).  I have
>a question that isn't answered by these documents:
>
>When using the UDP version, how does the client recover from lost
>packets?  When the call packet is lost, a simple retransmission is
>enough, however, when a reply packet is lost, a retransmission can
>cause the request to be executed twice.  How does e.g. an NFS client
>handle this if the request is not idempotent (like RENAME)?  Is there
>a way for the client to tell from the failing reply from the second
>try that the first try must have succeeded even though the response
>got lost?
>Note that I need to know how the existing Sun RPC implementation
>handles this situation, not how it could be done in a hypothetical
>system (I know all about Amoeba's RPC, for instance).

Sun RPC over UDP does not guarantee at-most-once delivery. The way Sun RPC
over UDP (or any connectionless transport) works is to retransmit a request
repeatedly till either an answer is recieved or a total timeout value is
reached. So it is possible for the same request to be processed twice. You can
reduce the probability of this happening a lot by doing a svc_udpenablecache()
(svc_dgenablecache() in TIRPC) on the server side. This sets up a server side
cache which throws away duplicate requests. 

>Pointers to sources or documents are welcome!

Sun's freely licensed RPC/XDR implementation, RPCSRC 4.0, is 
available via anonymous ftp from bcm.tmc.edu and by email from the
archive-server@bcm.tmc.edu.

If you use the archive server, send mail to archive-server@bcm.tmc.edu
with a Subject of "send nfs index" to see all the names of the files.
Sending a message with the Subject "help" will return to you more
information about the archive server itself.

Abhijit