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


Reply via email to