On Sat, Feb 5, 2011 at 4:09 AM, Jeffrey Hutzelman <[email protected]> wrote:
> --On Friday, February 04, 2011 10:14:23 AM -0600 Andrew Deason
> <[email protected]> wrote:
>
>> On Fri, 4 Feb 2011 09:32:53 -0500
>> Derrick Brashear <[email protected]> wrote:
>>
>>> struct UbikInterfaceInfo {
>>> afsUUID uuid;
>>> struct 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 for
> use in an Rx RPC signature. The appropriate thing here is some kind of
> discriminated union. We should probably define such a type as an extension
> 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 = 0x1,
/* IPv6 address */
RX_IPV6 = 0x2
} rx_addrtype_t;
--
Derrick
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
