On Wed, Apr 23, 2003 at 10:43:28PM +0200, Niels Möller scribbled:
Marek Habersack grendel@caudium.net writes:
The attached diff is not finished. I've just rediffed and adjusted whatever I could, but I have no more time today for keep working on it. The get_inet_addr function in system.c needs more work to get the families right (basically a few switch statements in there).
I've only had a first look at the code, and my first question is: Is there a good reason why the open_socket function need to take a family argument? To me, it seems a lot cleaner to just give it an address,
The original thought was to let the calling code decide and the reason is that you can use special IPv6 prefixes to encapsulate the IPv4 address in the IPv6 address (I'm not talking about an IPv6-on-IPv4 tunnel, but a format like 2002::XXX.YYY.ZZZ.VVVV, IIRC) and I thought optional code to do that might be added at a later date to open_socket. What's more, some code might want to force a specific family for some reason - remember that AF_INET, AF_UNIX and AF_INET6 are not the only families available (STCP comes to mind, it has its own family, I think).
and have the code examine the address to figure out which address family it is. (For numerical addresses, that's trivial, for dns names
I thought about it, but I usually stick to the rule that too much automation is bad - in the case of fairly low-level code like the open call, I think this (optional) flexibility is quite justified.
it's harder to get it right given that dns in general can return several addresses, and of different families, so one would need an "address list" API).
Yep, that's another issue that would have to be dealt with. Actually, IPv6 is differentiated to IPv4 in DNS by using a different type of the address record - AAAA instead of A, respectively. But then, if a DNS resolver returns addresses from all families, you are unable to guess which one the caller really wants - specifying the family is very helpful here.
regards,
marek