Subject: Re: Delegation callbacks proposal

From: [email-masked]
Date: Mon, 17 Sep 2001 11:52:00 -0600 (MDT)

An observation on the problem of firewalls and NATs with respect
to v4 callbacks. If I recall my last reading of the RPC RFCs, an
RPC connection between a client and a server allows the server
to send RPC calls back to the client for execution.  Use of this
was discussed early in the v4 effort and discarded because
many (if not all) RPC implementations do not implement this
capability.

However in the current debate there appears to be a lack of support
for a complex solution to the "problem" Brent is outlining.  As an
alternative solution, NFSv4 can make a statement that servers
MAY use the RPC feature to send "reverse" requests back to the
client for callbacks.  Those client and server implementations
who wish to address Brent's problem can do so with virtually no
overhead to the rest of the implementations.  The RFC should also
include that clients MUST gracefully respond to such a reverse
request, which should be a trivial amount of code to write and
easy to test in a bake-off.

        -David

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 17 Sep 2001 15:04:26 -0400

The RFC should also

I don't think I'd agree, especially with UDP.  IIRC, ONC-NFS's
NFS client would allocate client handles, each bound to a separate local
port number, send a request and then either put the handle on a free
list or destroy it.  The code only listened for messages when it was
expecting a reply.  If it wasn't expecting a reply but got one anyway
(e.g. a response to a retransmitted request), that would sit on the
socket until the handle was reused - there was nothing to wake up to
process it.

Changing things around from waiting for messages to return to a event driven
"here's your next message" paradigm is not all that trivial.  Well, maybe
compared to NFSv4 it is, and it was worth the effort in Tru64, but it did
take a couple passes to get right.

	-Ric Werme

---

From: Brent <[email-masked]>
Date: Mon, 17 Sep 2001 16:33:16 -0700

> many (if not all) RPC implementations do not implement this

That's right.  I don't know of any ONCRPC protocols that required
callbacks - hence the feature has never been implemented.  

It's interesting to note that both Rx (the RPC of AFS) and SMB
(used by CIFS) both support reverse calls on the same connection
because their file access protocols require it.

So, I'm inclined to believe that it's not in ONCRPC simply because
it hasn't been needed up till now.

> easy to test in a bake-off.

While I think passing an "in-protocol" address for callbacks is
unnecessary and problematic for Internet performance, it would
provide an "out" for client RPC implementations that are
(for whatever reason) incapable of supporting reverse calls on
an outgoing connection.

We could provide a way for the client to notify the server that
it expects callbacks via reverse RPC.  For instance, in the
cb_client4 address:

              struct clientaddr4 {
                      /* see struct rpcb in RFC 1833 */
                      char *r_netid;  /* network id */
                      char *r_addr;   /* universal address */
              } cb_client4;

We could reserve an r_netid value to specify "Use reverse connection - ignore r_addr"

Then, if after a bakeoff or two, we find that everyone is using this, we could
vote on eliminating clientaddr4 altogether.

	Brent