On Wed, Feb 9, 2011 at 7:31 PM, Jason Edgecombe <[email protected]> wrote: > On 02/09/2011 12:43 PM, Jeffrey Hutzelman wrote: >> >> --On Tuesday, February 08, 2011 05:53:02 PM -0600 Andrew Deason >> <[email protected]> wrote: >> >>> On Tue, 8 Feb 2011 15:23:41 +0000 >>> Simon Wilkinson <[email protected]> wrote: >>> >>>> 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; >>> >>> Assuming we don't want to use RFC 5665, that looks good to me. But what >>> to do about transport layer, port numbers, and service numbers? >>> >>> Any of these could be separate fields, or a 'field' inside the >>> address-specific blob, or not in the rx_addr structure at all. >>> Additionally, the transport layer could be merged into the address type. >>> For example, you could the struct above with address types for IPv4-UDP, >>> IPv4-TCP, IPv6-UDP, etc. Or, we could have it as a separate field: >>> >>> struct { >>> int addrtype; >>> int transport; >>> opaque addr<>; >>> } rx_addr; >>> >>> Or it could be a field inside the address-specific blob: >>> >>> struct { >>> int addrtype; >>> opaque addr<>; >>> } rx_addr; >>> >>> where 'addr' is XDR-encoded: >>> >>> struct { >>> int transport; >>> opaque real_addr<>; >>> } rx_ipv4_addr; >>> >>> Or we put it in a different structure/field in whatever RPCs use the >>> rx_addr struct: >>> >>> struct ubik_addr { >>> int transport; >>> rx_addr addr; >>> }; >>> >>> struct UbikInterfaceInfo { >>> afsUUID uuid; >>> struct ubik_addr[UBIK_MAX_INTERFACE_ADDR]; >>> }; >>> >>> For the transport layer, it seems easiest to just make IPv4-UDP and >>> IPv4-TCP et al address types. But try the above examples with port and >>> service numbers. Ports make sense to me inside the address-specific >>> blob, because a 'port' may not exist in whatever transport we're talking >>> about (or may have a different range/format), so should be tied to the >>> transport somehow. And a service ID could live in the rx_addr struct >>> itself, since we need one for any Rx RPC invocation. >> >> But, and here's the key point... >> I thought we were talking about network addresses. >> When did we decide to talk exclusively about Rx endpoints? >> >> >> I have seen lots of code that uses 'struct sockaddr' to represent network >> addresses, because it's conveniently available and has well-defined >> semantics for describing multiple different types of networks (in fact, it >> is a discriminated union). But this structure is really intended to >> represent transport endpoints (sockets), and additional data like port >> numbers is just wasted space for applications that aren't using it that way. >> >> I'm willing to be convinced otherwise, but I really think we want a >> representation of network addresses, not transport endpoints and not Rx >> endpoints. > > I support having port numbers so that hosting multiple cells on the same > host may be possible. How would port numbers be handled, if not alongside > the address?
as another element in an RPC payload? -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
