Scene: the following day, during which our protagonist has an insight that might perhaps not be as stupid as it initially appears
A few weeks ago, I asked Jeff & Derek, “Why is CAddressBytes() a CByteVector()?”
The answer was, “It seemed like and was a good idea at the time.” They’re fast, they’re lightweight. The name is a bit misleading, since it holds more than just the address octets. It also knows about the port number.
For v6, from an architectural POV, it will also need to know about the ADDRESS_FAMILY (AF_INET, AF_INET6, …), the flow and the scope id (if it’s an IPv6 address). So…is there some reason it shouldn’t just be an instance of something like sockaddr_storage?
How about an addrinfo? Answer: bad idea, because it uses a sockaddr, and Microsoft explicitly recommends the use of sockaddr_storage instead. Is it my imagination, or does it look as though there were two different but simultaneous approaches to dealing with IPv6? First the Berkeley/RFC people came up with stuff like sockaddr_in6, and then the sockaddr_storage class to rule them all.
A sockaddr_storage already knows about alignment and has enough space to store any kind of “actual” (v4/v6") address we might use. It’s 128 bytes
The Short Version:
CAddressBytes may have reached the end of its useful life insofar (and only insofar) as IPv6 is concerned. I know there are higher-level entities in the current framework that aggregate the “IP address”, but perhaps we should look at moving towards a more complex mechanism for representing hosts.
My shot at the v2 IPv6 implementation (Now with CLOUDS!) would be for CAddressBytes to be a smart, possibly stateful object that resembles a container of identifiers capable of being resolved to physical hosts in some fashion. Simplest case: create a turbo sockaddr_storage named CSockAddr_Storage and make CAddressBytes a container of them. IOW, promote it to being more than just a physical address. OTOH, there may well be higher level abstractions in the current framework where this could happen with greater ease and/or more sense. I.e. ARS could be combined with a replicator, federation manager, DNS, and LDAP (including Microsoft) to take care of this.
Huh, I think I just reinvented the VMS logical name table. Steal from the best, I’d say, but someone already said it. Oh, wait, I mean, “Yes, that’s what I say.”
In the meantime, I’m going to push ahead on converting CAddressBytes to use sockaddr_storage