On Sat, Feb 5, 2011 at 11:12 AM, Hartmut Reuter <[email protected]> wrote: > 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!
Good point. I suppose it's worth seeing what NFS is doing, also. _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
