Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: Is RPC in SVR4 implemented in kernel or user level?
Keywords: SVR4
Message-ID: <3640@auspex.auspex.com>
Date: 13 Jul 90 16:47:51 GMT
References: <1990Jul10.032917.13692@cbnews.att.com> <103795@convex.convex.com> <2503@sequent.cs.qmw.ac.uk>
Organization: Auspex Systems, Santa Clara
Lines: 32


 >Interesting. Back in NFS 3.0 days there was a significant
 >difference in that kernel RPC is assumed to be for NFS purposes
 >and so assumes idempotence, whereas that user-level RPC stuff
 >doesn't make this assumption.
 >
 >The actual difference this makes is in the handling of the xid
 >when a request times out. In the kernel case (idempotent) the
 >xid for the retransmission is the same as the original request

Really?  Do you mean a timeout internal to RPC - i.e., one where the RPC
layer does the retransmission - or a timeout that RPC reflects to its
caller, which does the retransmission itself?

The NFSSRC4.0 user-mode UDP transport code appears to bump the XID on
each call (i.e., when "clntudp_call" is first called, and whenever it
decides to refresh its credentials), but not on RPC-level
retransmissions.

The only difference in the NFSSRC4.0 kernel-mode UDP transport code
appears to be that it doesn't bump the XID when it decides to refresh
its credentials.

In other words, neither the user-mode nor the kernel-mode UDP client
code appears to transmit the same XID on retransmissions initiated by
the caller of the RPC layer; in particular, once you get "NFS server xxx
not responding still trying", and the NFS code is doing its own
retransmissions for a hard mount, the XID gets bumped.  (This is
especially nasty on create operations; somebody turned off RPC-layer
retransmissions for create operations, so no retransmitted RPC operation
*ever* goes out with the same XID as the original operation, and the
duplicate request cache can't do its job.)