Re: [reSIProcate] [Patch] Sketch of patch for adding c-ares 1.5.x support
Brad:
While we work out what the best long-term approach here is, I've created
a branch that may work around the issue you're seeing.
It's suboptimal, inasmuch as you'll have two different copies of ares
linked in, but I think that's a necessary evil for now -- our ares has
stuff in it that c-ares almost certainly does not, and I presume c-ares
has stuff you need that our ares doesn't.
What I've done is a fairly mechanical renaming of the #defines and
public symbols from the ares project that should eliminate conflicts
with c-ares.
Grab a copy from the repository:
svn co
https://svn.resiprocate.org/rep/resiprocate/branches/b-abr-ares-rename
I really mean this to be a stopgap, but I don't want this relatively
small issue to get in the way of your attempts to use the stack.
/a
Brad Spencer wrote:
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!
------------------------------------------------------------------------
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel