[AFS3-std] Re: Encoding IPvN addresses

[Jason Edgecombe]

On 02/09/2011 12:43 PM, Jeffrey Hutzelman wrote:
> --On Tuesday, February 08, 2011 05:53:02 PM -0600 Andrew Deason 
> <adeason@sinenomine.net> wrote:
>
>> On Tue, 8 Feb 2011 15:23:41 +0000
>> Simon Wilkinson <simon@sxw.org.uk> 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