Re: [reSIProcate] resip, ares, and IPv6

[David Stuart <dstuart@xxxxxxxxxxxxxxx>]

OK Everyone thanks for the tips.

I'll have to evaluate the options and see whether going ahead with
c-ares or trying to fix resip-ares is the best option for me..


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

-- 
David Stuart, CounterPath
Email: dstuart (at) counterpath (dot) com
Phone: (613) 254-8886 x2234  Web: http://www.counterpath.com/
Address: 310 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5