Jeroen, On Mar 1, 2012, at 9:25 AM, Jeroen Massar wrote: >> 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.
Sorry? On which system? As far as I'm aware, there are no libraries that make use of class E addresses to act as a layer of indirection similar to file handles. Would love to know such exists. > There is a nice 14 year old article about this: > http://www.kame.net/newsletter/19980604/ Quoting from that article: "This way the network address and address family is will not live together, and leads to bunch of if/switch statement and mistakes in programming. " which is exactly the point. It has been 14 years and people are _STILL_ discussing this. > And actually those addresses > are only 'copied' once: during accept() or connect(), Assuming the application doesn't need to copy the address, ever. > Ever heard of sockaddr_storage? Oddly, yes. It still astonishes me that sizeof(struct sockaddr) < sizeof(struct sockaddr_storage). > It was made to solve that little issue. See also, that article above. Thus requiring people to go in and muck with code thereby increasing the cost of migration with obvious effect. > 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. And yet, look at the code Mark Andrews just referenced as his recommend way of dealing with initiating connections. How many applications actually do anything like that? More to the point, how many books/article/etc. exist that reference these APIs you're talking about vs. how many reference the traditional way one goes about dealing with networks? Rhetorical questions, no need to answer. Got tired of tilting at this windmill some time ago and I know nothing will change. I'm just amazed that people defend the abominable kludge that are the existing common sockets/resolver APIs. Regards, -drc
