reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] resip, ares, and IPv6

On 5/12/11 10:07 AM, David Stuart wrote:

There's some code there that goes like this (and I
hope this isn't one of our local patches, but if it is, oh well):
I think it is. I did a grep over the public resip tree, and find no references to "default_localhost_server" outside of ares_init.c and ares_private.h. 


And of course, c-ares has no concept of "default_localhost_server"
(whatever that is).
The really odd thing is that it appears to be a write-only variable. None of the ares code ever attempts to read it. I've copied Scott Godin on this message, since he's the one who added the variable to the ares code; perhaps he can explain what's going on here. :)
In any case, the resip ares code basically has logic that says "if there are no configured nameservers, then configure a single nameserver, and set it to INADDR_LOOPBACK." If it does that, it also sets default_localhost_server to 1.
I don't know what c-ares would do in this case. If it has the same kind of behavior (no servers == use loopback), then your approach of checking for 127/8 (note: 127/8, not 127.0.0.1) or ::1 is probably correct. On the other hand, if it doesn't have the "no servers == use loopback" logic, then you'd want to check for "mChannel->nservers == 0" instead. You'll probably have to read the c-ares code (or play around with it) to see which approach is correct. 

/a


#ifdef WIN32
    // For windows OSs it is uncommon to run a local DNS server.
Therefore if there
    // are no defined DNS servers in windows networking and ARES just
returned the
    // loopback address (ie. default localhost server / named)
    // then put resip DNS resolution into hostfile lookup only mode
    if(mChannel->nservers == 1&&
       mChannel->servers[0].default_localhost_server)
    {
       // enable hostfile only lookup mode
       mHostFileLookupOnlyMode = true;
    }
    else
    {
       // disable hostfile only lookup mode
       mHostFileLookupOnlyMode = false;
    }
#endif


So, any advice as to how to clear this hurdle would be appreciated.
Should I look at the addr and try to compare it to 127.0.0.1 or ::1 ?

Is this even the right place to ask about c-ares?

David


On 11-05-11 12:08 PM, Adam Roach wrote:

On 5/11/11 10:39 AM, David Stuart wrote:

OK, sounds reasonable.

Does anyone recall why resip forked ares to begin with? What am I losing
by switching over to c-ares?

The big reason for the fork is that ares had gone dead, and the original
maintaners did not respond to emails. Resip had to "fork" the dead code
just to fix bugs and add features. It's the same reason c-ares ended up
forking ares, although they've clearly had different enhancements added
since the fork.

Here is Brad's list of features that resip-ares had but c-ares did not.
This refers to c-ares 1.5.3, and I know that Brad was working with the
c-ares team to get some features added, so this might not be completely
accurate any longer:

On 11/22/08, Brad Spencer wrote:

I have identified a set of "obvious" features that resiprocate depends
on simply by looking at the API differences between contrib/ares and
c-ares.  I have not searched for embedded behavioural changes that may
have been made to contrib/ares without API changes.  However,
especially if c-ares vs contrib/ares were to remain a choice at
configuration time, I think this is okay, at least as a starting point
because c-ares "works".

The attached patch will allow resiprocate to be configured against the
trunk version of c-ares (1.5.3 + patches).  Of course, it still allows
resiprocate to be configured to use contrib/ares as well.  With this
patch against resiprocate-1.4.1, the following features are missing
only when using c-ares:

   1. TryServersOfNextNetworkUponRcode3

     I've read the mailing list history on item 7, and I'm still
     digesting that.  It seems to be only supported on Windows in the
     current contrib/ares source, though.

   2. AfterSocketCreationFuncPtr

     I haven't been able to find much information about the purpose of
     the AfterSocketCreationFuncPtr feature, except I found some note
     about it being related to QoS.

     Is there a reason only UDP sockets from ares are identified via
     this function?  If I can supply the reasons this is important for
     QoS, and we can figure out what to do about TCP, there's probably a
     good argument to be made for adding an analogue of this to c-ares.

   3. DNS servers with IPv6 addresses themselves

     contrib/ares can have IPv4 and IPv6 addresses of DNS_servers_
     configured (via the additionalNameservers argument and via built-in
     config parsing), while c-ares can only contact IPv4 addressed DNS
     servers at the moment.  Note that this has nothing to do with AAAA
     record lookups, which work fine when using c-ares.

     This seems like a good candidate for a new c-ares feature, and I
     will ask about it on the c-ares list and report back.


After some quick poking around, I think #2 has been added to c-ares (as
of 1.6) and integrated into resip's c-ares support; and I think #3 is
fixed in c-ares (as of 1.7.1) but is not yet integrated.

Derek MacDonald also pointed out that resip-ares had added some features
to multi-lan failover support when hosts have multiple configured
interfaces. I think that's what #1 in the list above means, but I can't
recall.

Byron Campbell noted, back in 2008, that c-ares is substantially faster
than the resip version (it can do about twice as many DNS transactions
per second).

/a