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?
Jason
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
