--On Thursday, February 10, 2011 02:47:16 PM -0600 Andrew Deason
<[email protected]> wrote:
On Thu, 10 Feb 2011 15:43:05 -0500
Jeffrey Hutzelman <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
