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

[Derrick Brashear]

On Sat, Feb 5, 2011 at 4:09 AM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> --On Friday, February 04, 2011 10:14:23 AM -0600 Andrew Deason
> <adeason@sinenomine.net> wrote:
>
>> On Fri, 4 Feb 2011 09:32:53 -0500
>> Derrick Brashear <shadow@gmail.com> wrote:
>>
>>> struct UbikInterfaceInfo {
>>> =A0 =A0 =A0 =A0afsUUID uuid;
>>> =A0 =A0 =A0 =A0struct sockaddr_storage hostAddr[UBIK_MAX_INTERFACE_ADDR=
];
>>> };
>>
>> 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 little
>> unclear about, actually; is there any existing standard for transmitting
>> 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 f=
or
> 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 exten=
sion
> to the "standard" types supported by Rx, rather than doing it in Ubik and
> 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
{
  /* The discriminator for the union below. */
  rx_addrtype_t addr_type;
  union
  {
    /* IPv4 address, in network byte order. */
    struct in_addr ipv4;

    /* IPv6 address, in network byte order. */
    struct in6_addr ipv6;
  } addr;
} rxaddr_t;

where

typedef enum
{
  /* IPv4 address */
  RX_IPV4 =3D 0x1,
  /* IPv6 address */
  RX_IPV6 =3D 0x2
} rx_addrtype_t;



--=20
Derrick