[AFS3-std] Re: Encoding IPvN addresses

[Jeffrey Hutzelman]

--On Thursday, February 10, 2011 02:47:16 PM -0600 Andrew Deason 
<adeason@sinenomine.net> wrote:

> On Thu, 10 Feb 2011 15:43:05 -0500
> Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>
>> > Actually, this made me realize, if you do encode multiple addresses
>> > in one address structure, you can make this more efficient for
>> > larger numbers of a addresses. That is, instead of having one IP
>> > address per structure, if you just have multiple addresses in the
>> > e.g. IPv4 opaque, you don't need to repeat the "IPv4 address type"
>> > int every time. That would almost always save some space, since we'd
>> > almost always be dealing with lists of addresses of the same type
>> > (or two types).
>>
>> No, in fact, I expect we'll be dealing with lists of addresses of
>> mixed type, like "all of the addresses of this fileserver that's
>> registered in the VLDB".
>
> And wouldn't most cases involve more addresses than address types? e.g.
> 4 IPv4 addresses, and 4 IPv6 addresses?

So, something I'm specifically trying to avoid here is designing a 
primitive that is specifically tailored to the needs of one use in the AFS 
protocol that we can see today.  Instead, I'm trying to create a simple, 
reusable primitive that we can aggregate using the existing tools, which 
can directly replace the current uses of afs_uint32 to represent network 
addresses.

Yes, there are some places in AFS where we'll need to carry more 
information than an address, such as a transport protocol, port number, 
etc.  Yes, I suppose there are even places where we'll need to carry an Rx 
service ID, though I expect that to be rare (perhaps some debugging 
interfaces will need to carry service ID's, but mostly not).

Sure, we could build a complex type that encodes an address plus a port 
plus lets you build arrays or lists or heirarchies or what have you.  But 
why?  All of those things can be done with the existing tools.  I'd like to 
limit ourselves to creating a simple tool to solve a simple problem, which 
is the lack of extensibility in address types.



I suppose we could instead create a simpler tool for what is, in some 
sense, a simpler problem -- the inability to decode a discriminated union 
with an unknown discriminator.  The existing interface for unions allows 
you to provide a handler for unknown discriminators, but if it's truly 
unknown, that doesn't help, because you don't know the length of the 
encoding.

How about a new type of union that always sends the length of the encoded 
data?  You'd still be able to provide an unknown-discriminator handler, 
which would be told the discriminator and length and have the option of 
decoding and handling the data, failing the decode with an error, or 
accepting the default behavior (the same as if no handler is given).  The 
default then would be to read the data and provide it using the same 
in-memory representation as an opaque, which the application could do with 
as it pleases (or ignore).  With the proper in-memory representation, it 
would even be possible to _encode_ such a thing.

Given an "extensible union" type, we would then be free to use an 
extensible union of addresses, or an extensible union of arrays of 
addresses, or an extensible union of address+port, or whatever the 
situation calls for.

-- Jeff