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

Adam Roach adam at nostrum.com
Thu Nov 13 15:05:25 CST 2008


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 at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel




More information about the resiprocate-devel mailing list