Re: [reSIProcate] resip, ares, and IPv6

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

That flag is used in AresDns.cxx - the piece of code in Dave's email contains the "read" access to this variable.  The comments on the code fragment Dave pasted in explains the use.  I added the flag to be able to detect scenarios where the ares user may have provided 127.0.0.1 as the DNS servers, instead of ares just using loopback because no DNS servers were provided.

Scott

On Thu, May 12, 2011 at 11:32 AM, Adam Roach <adam@xxxxxxxxxxx> wrote:

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