Subject: Re: [RFC] Support querying IPv6 servers

Re: [RFC] Support querying IPv6 servers

From: Yang Tse <yangsita_at_gmail.com>
Date: Mon, 24 Nov 2008 16:02:29 +0100

Hi Gregor,

2008/11/24, Gregor Jasny wrote:

> The reSIProcate developers substituted the in_addr field by an union
> contruct to hold the in6_addr. As this would break API compatibility, I
> have added a second nservers and servers field and suffixed it with a '6'.

For c-ares, instead of having two lists of name servers, I think that
keeping a single one and being able to differentiate between an Ipv6
address name server and an Ipv4 one should keep things working more
smoothly and aid in code maintainability.

This could be done building upon the following change:

Index: ares/ares_private.h
===================================================================
RCS file: /cvsroot/curl/curl/ares/ares_private.h,v
retrieving revision 1.39
diff -u -r1.39 ares_private.h
--- ares/ares_private.h 20 Nov 2008 07:50:48 -0000 1.39
+++ ares/ares_private.h 24 Nov 2008 14:35:16 -0000
@@ -132,7 +132,9 @@
};

struct server_state {
- struct in_addr addr;
+ int af; /* server address family */
+ union ares_addr; /* server address */
+
   ares_socket_t udp_socket;
   ares_socket_t tcp_socket;

> [...]
> Things that needs to be done:
> * Guard the AF_INET6 specific part by the preprocessor. What
> (config-)defines would be optimal for this task? A combination of
> HAVE_AF_INET6, HAVE_STRUCT_SOCKADDR_STORAGE, HAVE_STRUCT_SOCKADDR_IN6?

c-ares already provides the needed preprocessor magic to make it build
even on systems that lack an IPv6 stack or IPV6 capable system
headers, so probably you want to skip that work.

> But before I continue I'd like to get some feedback on this issue.

There's mine ;-)

-- 
-=[Yang]=-
Received on 2008-11-24