[AFS3-std] Re: first draft: ubik update proposal

[Derrick Brashear]

On Sat, Feb 5, 2011 at 11:12 AM, Hartmut Reuter <reuter@rzg.mpg.de> wrote:
> Derrick Brashear wrote:
>>
>> On Sat, Feb 5, 2011 at 4:09 AM, Jeffrey Hutzelman<jhutz@cmu.edu> =A0wrot=
e:
>>>
>>> --On Friday, February 04, 2011 10:14:23 AM -0600 Andrew Deason
>>> <adeason@sinenomine.net> =A0wrote:
>>>
>>>> On Fri, 4 Feb 2011 09:32:53 -0500
>>>> Derrick Brashear<shadow@gmail.com> =A0wrote:
>>>>
>>>>> struct UbikInterfaceInfo {
>>>>> =A0 =A0 =A0 =A0afsUUID uuid;
>>>>> =A0 =A0 =A0 =A0struct sockaddr_storage hostAddr[UBIK_MAX_INTERFACE_AD=
DR];
>>>>> };
>>>>
>>>> I thought struct sockaddr_storage can be different on different
>>>> implementations, and isn't guaranteed to store ~everything, just the
>>>> representations that host supports. This is something I've been a litt=
le
>>>> unclear about, actually; is there any existing standard for transmitti=
ng
>>>> generalized network addresses across platforms? Or does everyone just
>>>> come up with their own?
>>>
>>> Indeed, sockaddr_storage is an API artifact, and certainly not suitable
>>> for
>>> use in an Rx RPC signature. =A0The appropriate thing here is some kind =
of
>>> discriminated union. =A0We should probably define such a type as an
>>> extension
>>> to the "standard" types supported by Rx, rather than doing it in Ubik a=
nd
>>> again in VL and again in RXAFSCB and so on and so on.
>>
>> to that end, may i propose that rx define a type e.g.
>> typedef struct
>> {
>> =A0 /* The discriminator for the union below. */
>> =A0 rx_addrtype_t addr_type;
>> =A0 union
>> =A0 {
>> =A0 =A0 /* IPv4 address, in network byte order. */
>> =A0 =A0 struct in_addr ipv4;
>>
>> =A0 =A0 /* IPv6 address, in network byte order. */
>> =A0 =A0 struct in6_addr ipv6;
>> =A0 } addr;
>> } rxaddr_t;
>
>
> This will not work because in6_addr is a union and xdr cannot handle unio=
ns
> unless you have a switch variable which says which branch of the union
> should be used. 16 bytes are not the same as 4 int32 if you have differen=
t
> endianess!

Good point. I suppose it's worth seeing what NFS is doing, also.