On 2012-03-01 17:57 , David Conrad wrote: > Hi, > > On Mar 1, 2012, at 7:22 AM, Joe Greco wrote: >> On Mar 1, 2012, at 7:01 AM, Michael Thomas wrote: >>> The effect of what you're recommending is to move all of this >>> into the kernel, and in the process greatly expand its scope. >>> Also: even if you did this, you'd be saddled with the same >>> problem because nothing existing would use an AF_NAME. > > I always thought the right way to deal with IPv6 would have been to > use a 32-bit number from the class E space as a 'network handle' > where the actual address (be it IPv4 or IPv6) was handled by the > kernel.
This is the case when you pass in a sockaddr. Note, not a sockaddr_in or a sockaddr_in6, but just a sockaddr. There is a nice 14 year old article about this: http://www.kame.net/newsletter/19980604/ > I suspect this would have allowed the majority of > network-utilizing applications to magically just work, regardless of > whether the name supplied by gethosbyname/getnameinfo/etc. was mapped > to an address with A or AAAA. Probably would make stuff faster too > since you'd only have to deal with an unsigned int instead of (worst > case) 16 bytes that have to be copied back and forth. There is quite a bit more state than that. And actually those addresses are only 'copied' once: during accept() or connect(), there is no "speed-loss" per send/recv as the only thing being moved from user space to kernel space is the file descriptor and the actual data. [..] > Instead, we have forced application developers to use a really odd > mixture of old and new, e.g. 'struct sockaddr_in6' and GNI/GAI. > Seems this is the worst of both worlds -- no backwards compatibility > yet an adherence to a really broken model that requires applications > to know useless details like the length of an address ("what do you > mean a sizeof(struct sockaddr) isn't big enough to hold an IPv6 > address?") and even its bit patterns. Ever heard of sockaddr_storage? It was made to solve that little issue. See also, that article above. [..] > Exactly. Even before IPv6, it was icky. Now, it's just crazy. We > had an opportunity to fix this with IPv6 since IPv6 required > non-trivial kernel hackage. Unfortunately, we didn't take advantage > of that opportunity. What you are talking about is an API wrapper. Depending on platform these have existed for years already. Quite a few do not expose addresses at all to the calling code. One of the many reasons why putting the IPv6 enabled winsock dll in place 14 years ago made various winsock applications understand IPv6. Greets, Jeroen
