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

Re: [reSIProcate] [Patch] Sketch of patch for adding c-ares 1.5.x support


I agree that merging stuff into c-ares would be difficult, both from a "finding cycles to do it" and a "convincing the c-ares guys to take our changes" perspective. But, if we can get this tweak to the build system working/tested, it might give us a middle ground that'll make it easier. Plus, c-ares is an active project, with good distribution. I think it would be a good idea long term to move over to using c-ares.

Best regards,
Byron Campen

Frankly, my inclination in the short term would be to rename our symbols from "ares_" to "rares_" or something simple and mechanical like that. I suspect a full merge of the functionality we need for resip into c-ares would be a non-trivial task.

/a

Byron Campen wrote:
Wow. So, it is my understanding that we've added a few unusual features to our copy of ares, that I'm not sure would be ready to merge back into c-ares. I haven't really touched our copy of ares.

   Derek, what are your thoughts on this?

Best regards,
Byron Campen

Hi. I'm new to resiprocate, and from what I've seen so far, it's one
of the best SIP stacks I've worked with.  Nice work!

I've run into one minor snag, though.  Our infrastructure here uses
c-ares 1.5.x to do its asynchronous DNS lookups.  That library,
maintained at <http://c-ares.haxx.se/>, has come a good distance from
the original ares library that is used in resiprocate.
Coincidentally, I've contributed a few patches to that project as
well.

This wouldn't really be a problem, except the symbols used in c-ares
and ares are the same: in both they all start with ares_, and in fact
they generally are pretty much the same.  So, this meant that I was
maximally out of luck; if resiprocate or I had used any other DNS
resolvers, we'd be fine to cooperate, but things are just too similar
to work :)

Since c-ares has at least some IPv6 support and aims to work on Win32
as well as POSIX, I figured I'd solve this just by using c-ares
instead of the contrib/ares that comes with resiprocate, thus this
sketch of a patch in progress. I'm hoping the folks on this list can
guide me towards a final patch that is good enough to include in
resiprocate itself.

What I've done so far:

- Started with the 1.4 release (instead of svn) since I'm new to the
 project and wanted to keep things simple.  Hopefully, there is
 little volatility in this area, though.

- Tried to hide almost all the differences between the library in a
 new header, rutil/dns/AresCompat.hxx that is included only in .cxx
 files.  In particular, the patch aims to not require including code
 to define USE_ARES or USE_CARES in order to _use_ the library or
 its headers, although a built library will be wired permanently to
 one or the other.

- Adapted the initialization and callback code to work with the
 slightly new (improved?) c-ares API

- Added rules to configure and the Makefiles to allow an external
 c-ares installation to be used instead contrib/ares with minimal
 pain outside of the rutil/dns/ directory.

- Got things roughly working with the stack/ test tools.

- Left some TODOs for things that are currently hard or impossible to
 do in c-ares, or that I didn't understand (see the patch)

- Probably made a mess of it :)

Clearly, the resiprocate version of ares hasn't stood still, so its
version is also "a better ares", and so there are few things that
resiprocate does that c-ares doesn't have support for right this
minute. The c-ares maintainers are good folks, though, so I'm sure if
there are any really important things that need adding, they'd
consider it.  Even though I'm brand new to resiprocate, I'd be happy
to help apply any patches to c-ares that would help make it more
usable by the mainstream resiprocate version.

As I said, I'd love to be able to get this draft patch to the point
where it could be accepted into resiprocate.  Thanks in advance for
any feedback!

--
----------------------------------------------------------
Brad Spencer - spencer@xxxxxxxxxxxxx - www.starscale.com
<cares-support.diff>_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel