[AFS3-std] Re: Encoding IPvN addresses (was Re: first draft: ubik update proposal)

[Derrick Brashear]

On Tue, Feb 8, 2011 at 11:09 AM, Hartmut Reuter <reuter@rzg.mpg.de> wrote:
> Simon Wilkinson wrote:
>>
>> On 8 Feb 2011, at 15:20, Derrick Brashear wrote:
>>
>>> struct {
>>> int addrtype;
>>> int addrlen;
>>> int addr<>
>>> } rx_addr;
>>>
>>> #define RX_ADDRTYPE_IPV4 1
>>> #define RX_ADDRTYPE_IPV6 2
>>
>> Why not just use an opaque? That way you don't get into any of the
>> ordering issues that ints bring with them.
>>
>> struct {
>> int addrtype;
>> opaque addr<>;
>> } rx_addr;
>
> opaque requires xdr_alloc and later xdr_free of the data and in the case =
of
> IPv4 the address typically is used as an integer which then would have be=
en
> first converted from the opaque (including changing host byte order).
>
> Therefore I had proposed in my change I8aa46a29:
> src/fsint/fs_rxosd_common.xg
> for both address types to use afs_uint32s:
>
> union ipadd switch(afs_int32 vsn) {
> case 4:
> =A0 =A0 =A0 =A0afs_uint32 ipv4;
> case 6:
> =A0 =A0 =A0 =A0afs_uint32 ipv6[4];
> };
>
> I also think instead of inventing new constants it's better to use the
> version numbers 4 and 6 directly.
>
> In the case of IPv6 the application easily can fill the contents into the
> host's struct in6_addr using the u6_addr32 fields while for IPv4 the addr=
ess
> can be used directly.

the only problem is we're back to a union with fixed discrimination
that doesn't allow us to add things later.

> If we create such a new struct one could think of also adding the port
> number and the service number as additional fields.

for things that don't want those, it's extra memory, though.

--=20
Derrick