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

Re: [reSIProcate] [Patch] Add support for AfterSocketCreationFuncPtr when using c-ares


On Sat, Dec 13, 2008 at 02:30:17PM -0400, Brad Spencer wrote:
> Now that c-ares 1.6.0 supports socket creation callback functions, I
> have added support for the AfterSocketCreationFuncPtr resiprocate
> callback when using c-ares.
> 
> In detail:
> 
>  - Implemented AfterSocketCreationFuncPtr when using c-ares (requires
>    1.6.0)

Can we check for the 1.6.0 during configure?

>  - Added TODOs for supporting IPv6 DNS server addresses with c-ares
>    (coming soon)

The c-ares patch will take some extra days. I still don't find the time to
look at the segfault issue.

> I tested with resiprocate-1.4.1 using c-ares-1.6.0 with and without an
> AfterSocketCreationFuncPtr callback set using testDns.  The attached
> patch applies against svn main.

I had the nearly same patch im my patch queue. Should have sent it
earlier.

> Index: rutil/dns/AresDns.cxx
> ===================================================================
> --- rutil/dns/AresDns.cxx     (revision 8364)
> +++ rutil/dns/AresDns.cxx     (working copy)
> @@ -21,6 +21,25 @@
>  
>  #define RESIPROCATE_SUBSYSTEM resip::Subsystem::DNS
>  
> +namespace
> +{
> +   // When we're using c-ares, this is used to tie its socket creation
> +   // callback to ours.  The data must be set to the
> +   // AfterSocketCreationFuncPtr that we're chaining to (and can't be NULL).
> +   int caresSocketCreationCallback(const ares_socket_t socket_fd,
> +                                   const int type,
> +                                   void * const data)
> +   {
> +      // We don't have the file and line from c-ares, but ours will do to
> +      // identify that this is a c-ares DNS socket, which is probably enough.
> +      reinterpret_cast<AfterSocketCreationFuncPtr>(data)(socket_fd, type,
> +                                                         __FILE__, __LINE__);
> +
> +      // We can't fail, so say everything is okay
> +      return ARES_SUCCESS;
> +   }
> +}

I'd suggest surrounding this with #if defined(USE_CARES)