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

[Byron Campen]

	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 at starscale.com - www.starscale.com
> <cares-support.diff>_______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel