[AFS3-std] Standardization of GetCapabilties RPCs for AFS3 client and services

[Jeffrey Hutzelman]

On Monday, February 27, 2006 05:19:08 PM -0500 Jeffrey Altman 
<jaltman@secure-endpoints.com> wrote:

> I believe that whether RX/UDP or RX/TCP is used is an application level
> decision that is driven primarily by local configuration.  A capability
> flag may not be all that useful in this case since the ability to
> connect to the server with UDP or TCP may very well be affected by the
> network topology more so than the functionality of the application.

Also, this is not an application-level capability of the server; it's an 
rx-level capability.  I believe we determined in discussions at the last 
hackathon that if an application wishes to use TCP, the cost of trying it 
first and falling back to UDP is relatively low.  Likely, applications 
should only even attempt to use TCP for connections which are expected to 
carry relatively large amounts of data -- it's silly to establish a TCP 
connection for a single RPC, unless that RPC is something like 
AFSVolDumpVolume.

We may wish to add some form of capability negotiation to the Rx transport 
and/or session layers, but that's a separate issue.


> I can easily imagine a mobile client that is unable to connect via TCP
> because of an existing firewall rule from one location and then migrates
> to a new location and has no problem.  After RX/TCP becomes popular the
> reverse may be true as well.

It may even be true today.  Lots of people seem to think UDP is somehow 
inherently evil and not used for anything real, and so block all UDP 
traffic even while allowing outgoing TCP connections.

-- Jeff