[AFS3-std] Re: Encoding IPvN addresses

[Derrick Brashear]

On Wed, Feb 9, 2011 at 7:31 PM, Jason Edgecombe <jason@rampaginggeek.com> w=
rote:
> 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 {
>>>> =A0 =A0int addrtype;
>>>> =A0 =A0opaque 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 {
>>> =A0int addrtype;
>>> =A0int transport;
>>> =A0opaque addr<>;
>>> } rx_addr;
>>>
>>> Or it could be a field inside the address-specific blob:
>>>
>>> struct {
>>> =A0int addrtype;
>>> =A0opaque addr<>;
>>> } rx_addr;
>>>
>>> where 'addr' is XDR-encoded:
>>>
>>> struct {
>>> =A0int transport;
>>> =A0opaque 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 {
>>> =A0int transport;
>>> =A0rx_addr addr;
>>> };
>>>
>>> struct UbikInterfaceInfo {
>>> =A0afsUUID uuid;
>>> =A0struct 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 talkin=
g
>>> 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 networ=
k
>> 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). =A0But 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?



--=20
Derrick