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

[Jeffrey Altman]

Ken Hornstein wrote:
>> CAPABILITY FLAGS:
>>
>> Capability Flags will be registered with registrar@grand.central.org
>> on a per-RPC basis.  The following capabilities are already in use:
>>
>> /* Viced Capability Flags */
>> const VICED_CAPABILITY_ERRORTRANS       = 0x0001;
>> const VICED_CAPABILITY_64BITFILES       = 0x0002;
>>
>> /* Cache Manager Capability Flags */
>> const CLIENT_CAPABILITY_ERRORTRANS      = 0x0001;
> 
> I was thinking of a capability flag for RxTCP, but I'm wondering if it makes
> sense to do that at the RPC level.  This presents a number of "interesting"
> issues.  Specifically:
> 
> - Do we have the Rx library do this automatically?  This may not work, as
>   that would mean the Rx library would have to make an "upper" level query
>   (assuming we didn't have an Rx-level capability query).
> 
> - Do we have applications (or associated helper libraries) perform the query
>   and then twiddle an Rx flag to tell it to use TCP?  This would make the
>   Rx library simpler, at the cost of requiring applications to specifically
>   request TCP usage.  This may be desirable; I'm not really sure.
> 
> --Ken

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.

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.   Therefore, the capability flags would be
informative but could not really provide a significant degree of hinting
to the caller.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3288 bytes
Desc: S/MIME Cryptographic Signature
Url : http://michigan-openafs-lists.central.org/archives/afs3-standardization/attachments/20060227/7a0e1426/smime-0001.bin