🚀 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

>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.

Presumably it detects duplicates by checking the XID (transaction ID)
field of the request.

(For those who are curious, "dg" in the TIRPC version presumably stands
for "datagram"; TI, you see, stands for "transport-independent", so UDP
isn't the only datagram transport - I think it's been run atop the ISO
connectionless transport protocol as well, for example.)

guido@cwi.nl (Guido van Rossum) writes:

>Is there an expert on Sun RPC in this group?

>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:

I'm wondering why you do that, given that Sun's implementation is
publicxly available in source.

>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?

A client cannot know if his request got lost, or the response. Both
result in a timeout. The client will retransmit or give up, depending
on circumstance.

>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).

If the request is not idempotent, you need to activate the server
cache with svcudp_enablecache(). Note that is an undocumented
function. Get the 4.0 rpcxdr source and look there for details.

>Pointers to sources or documents are welcome!

Sources: see above, docs: RTFS ;-)
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  This is an unofficial  |
| suninfo!alanya!lupe (Sun Germany)              |  opinion of Christoph & |
| Res non sunt complicanda praeter necessitatem. |  Imschweiler Consulting |

Hi, Guido.  Happy New Year!

Get a copy of the book "Power Programming with RPC", by John Bloomer,
published by O'Reilly & Assoc.  ISBN 0-937175-77-3.  It's packed with
information on Sun RPC -- best reference I've seen yet.

Unfortunately, you'll find that what's called Sun TIRPC is really
a family of RPC protocols that share a common XDR and packet layout.
Questions such as the semantics of a call (idempotency, sequencing of
requests), or practical matters such as timeouts with UDP are left up
to the implementation, and thus are really part of the application,
rather than part of the RPC protocol.  Thus your questions need to be
answered on an application-by-application basis.

Bill
--
 Bill Janssen      janssen@parc.xerox.com      (415) 812-4763
 Xerox Palo Alto Research Center      FAX: (415) 812-4777
 3333 Coyote Hill Road, Palo Alto, California   94304