Derrick Brashear wrote:
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;
This will not work because in6_addr is a union and xdr cannot handle unions
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 different endianess!
where
typedef enum
{
/* IPv4 address */
RX_IPV4 = 0x1,
/* IPv6 address */
RX_IPV6 = 0x2
} rx_addrtype_t;
--
-----------------------------------------------------------------
Hartmut Reuter e-mail [email protected]
phone +49-89-3299-1328
fax +49-89-3299-1301
RZG (Rechenzentrum Garching) web http://www.rzg.mpg.de/~hwr
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut fuer Plasmaphysik (IPP)
-----------------------------------------------------------------
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
