c-ares development and related discussions ()

Fredrik Jansson | 27 Jun 2012 10:55

socket callbacks

Hi all,

I am interested in using the ares lib but would need an additional socket callback, one that is called right after socket creation before the socket is configured and connected.

Suggestion 1, I add a ares_set_socket_created_callback that takes the same parameters as ares_set_socket_callback.

Suggestion 2, I rename ares_set_socket_callback to ares_set_socket_connected_callback, I believe that would be more informative name when there are two socket callbacks.

Thoughts/opinions on this?

If anyone else is interested in this I'd be happy to supply patches.

Best regards,

Fredrik Jansson

headers

Daniel Stenberg | 27 Jun 2012 15:35

Re: socket callbacks

On Wed, 27 Jun 2012, Fredrik Jansson wrote:

> I am interested in using the ares lib but would need an additional socket 
> callback, one that is called right after socket creation before the socket 
> is configured and connected.

I assume you want that so that you can set some options before connect() is 
done?

> Suggestion 1, I add a ares_set_socket_created_callback that takes the same 
> parameters as ares_set_socket_callback.
>
> Suggestion 2, I rename ares_set_socket_callback to 
> ares_set_socket_connected_callback, I believe that would be more informative 
> name when there are two socket callbacks.
>
> Thoughts/opinions on this?

Number 2 is out of the question since that would break the ABI, so I say 
option 1. The difference between these two callbacks (and possibly why) should 
be clearly spelled out in the docs so that users won't get confused.

--

-- 

  / daniel.haxx.se

headers

Fredrik Jansson | 27 Jun 2012 16:07

RE: socket callbacks

I assume you want that so that you can set some options before connect() is
done?

That is correct, I need to register the socket to make sure the connect will come through.

I will go ahead and implement suggestion 1 then.

Thanks for you input!

Best regards,
Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Daniel Stenberg [daniel@...]
Sent: Wednesday, June 27, 2012 15:35
To: c-ares hacking
Subject: Re: socket callbacks

On Wed, 27 Jun 2012, Fredrik Jansson wrote:

> I am interested in using the ares lib but would need an additional socket
> callback, one that is called right after socket creation before the socket
> is configured and connected.

I assume you want that so that you can set some options before connect() is
done?

> Suggestion 1, I add a ares_set_socket_created_callback that takes the same
> parameters as ares_set_socket_callback.
>
> Suggestion 2, I rename ares_set_socket_callback to
> ares_set_socket_connected_callback, I believe that would be more informative
> name when there are two socket callbacks.
>
> Thoughts/opinions on this?

Number 2 is out of the question since that would break the ABI, so I say
option 1. The difference between these two callbacks (and possibly why) should
be clearly spelled out in the docs so that users won't get confused.

--

  / daniel.haxx.se

headers

Lijo Antony | 27 Jun 2012 16:14

Re: socket callbacks

On 06/27/2012 05:35 PM, Daniel Stenberg wrote:
>
> I assume you want that so that you can set some options before connect()
> is done?

>> Suggestion 1, I add a ares_set_socket_created_callback that takes the
>> same parameters as ares_set_socket_callback.
>>
>> Suggestion 2, I rename ares_set_socket_callback to
>> ares_set_socket_connected_callback, I believe that would be more
>> informative name when there are two socket callbacks.
>>
>> Thoughts/opinions on this?
>
> Number 2 is out of the question since that would break the ABI, so I say
> option 1. The difference between these two callbacks (and possibly why)
> should be clearly spelled out in the docs so that users won't get confused.
>

I think a name which makes the purpose explicit would be better.
Something like ares_set_socket_options_callback or 
ares_set_sockopt_callback etc.

Distinction with existing "ares_set_socket_callback" would be more clear 
as well. Also it would leave room for a future 
"ares_set_opensocket_callback". (it's there in my to do list. Couldn't 
work on it yet!). Similarity with curl callbacks(opensocket, sockopt) 
would be an added advantage.

-lijo

headers

Fredrik Jansson | 27 Jun 2012 18:01

RE: socket callbacks

Hi,

thanks for the input!

"ares_set_sockopt_callback" seems like a good name.

I no one objects, let's decide on that name.

What did you have in mind for the opensocket cb? Anything I can fix while I am at the sockopt cb?

Br,
Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Lijo Antony [lta@...]
Sent: Wednesday, June 27, 2012 16:14
To: c-ares@...
Subject: Re: socket callbacks

On 06/27/2012 05:35 PM, Daniel Stenberg wrote:
>
> I assume you want that so that you can set some options before connect()
> is done?

>> Suggestion 1, I add a ares_set_socket_created_callback that takes the
>> same parameters as ares_set_socket_callback.
>>
>> Suggestion 2, I rename ares_set_socket_callback to
>> ares_set_socket_connected_callback, I believe that would be more
>> informative name when there are two socket callbacks.
>>
>> Thoughts/opinions on this?
>
> Number 2 is out of the question since that would break the ABI, so I say
> option 1. The difference between these two callbacks (and possibly why)
> should be clearly spelled out in the docs so that users won't get confused.
>

I think a name which makes the purpose explicit would be better.
Something like ares_set_socket_options_callback or
ares_set_sockopt_callback etc.

Distinction with existing "ares_set_socket_callback" would be more clear
as well. Also it would leave room for a future
"ares_set_opensocket_callback". (it's there in my to do list. Couldn't
work on it yet!). Similarity with curl callbacks(opensocket, sockopt)
would be an added advantage.

-lijo

headers

Daniel Stenberg | 27 Jun 2012 23:12

RE: socket callbacks

On Wed, 27 Jun 2012, Fredrik Jansson wrote:

> "ares_set_sockopt_callback" seems like a good name.
>
> I no one objects, let's decide on that name.
>
> What did you have in mind for the opensocket cb? Anything I can fix while I 
> am at the sockopt cb?

It might be an idea to _just_ make it an opensocket one. In your case you 
could easily have the callback do socket() and then the sockopts you need...

But regarding an opensocket callback, what exactly would that be used for? The 
reason I'm asking is that if you want to be able to pass in a socket that is 
already for exampled tunneled over some other medium you may want to tell 
c-ares to _not_ do the connect() afterwards or similar.

I figure an opensocket callback would need a corresponding closesocket version 
as well.

--

-- 

  / daniel.haxx.se

headers

Lijo Antony | 28 Jun 2012 08:23

Re: socket callbacks

On 06/28/2012 01:12 AM, Daniel Stenberg wrote:
> On Wed, 27 Jun 2012, Fredrik Jansson wrote:

>> What did you have in mind for the opensocket cb? Anything I can fix
>> while I am at the sockopt cb?
>
> It might be an idea to _just_ make it an opensocket one. In your case
> you could easily have the callback do socket() and then the sockopts you
> need...
>
> But regarding an opensocket callback, what exactly would that be used
> for? The reason I'm asking is that if you want to be able to pass in a
> socket that is already for exampled tunneled over some other medium you
> may want to tell c-ares to _not_ do the connect() afterwards or similar.
>
> I figure an opensocket callback would need a corresponding closesocket
> version as well.
>

I use curl in a cross platform c++ application(linux, windows & mac). In 
linux and mac, I use c-ares as name resolver. I also use boost::asio 
instead of libevent for socket monitoring.

A platform limitation of asio on windows, requires me to have all the 
sockets used by curl be opened by asio. For this reason I use curl 
opensocket/closesocket/sockopt callbacks. But c-ares doesn't have this 
option. This is not an issue since c-ares will not come into picture on 
windows, but has the side effect of having some platform specific code 
and this is my current state.

As Daniel mentioned opensocket would involve quite some work. And I am 
afraid this might be a very specific use case and may not be useful to 
others. Since the incentive is low, compared to the work involved, I 
couldn't work on this. I guess for Fredrik also this would be too much 
unnecessary work, since he only wants to configure the socket.

But If such a need arise, and people are interested, with 
ares_set_sockopt_callback in place, we should be able to add missing 
callbacks(open/close) and follow the same curl design without too much 
difficulties.

-lijo

headers

Fredrik Jansson | 28 Jun 2012 09:53

RE: socket callbacks

Hi!

That kind of open/close-socket functions would work great for me.

I cannot see that there is that much work with this approach:

1. Check if we have opensocket cb otherwise call socket.

The opensocket_cb would have the sams arguments as the "socket" call plus an additional user data ptr.

2. Replace the sclose macro with a function that checks if we have a closesocket cb.

Or am I over simplifying things?

Lijo, would that provide what you (will) need?

Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Lijo Antony [lta@...]
Sent: Thursday, June 28, 2012 08:23
To: c-ares@...
Subject: Re: socket callbacks

On 06/28/2012 01:12 AM, Daniel Stenberg wrote:
> On Wed, 27 Jun 2012, Fredrik Jansson wrote:

>> What did you have in mind for the opensocket cb? Anything I can fix
>> while I am at the sockopt cb?
>
> It might be an idea to _just_ make it an opensocket one. In your case
> you could easily have the callback do socket() and then the sockopts you
> need...
>
> But regarding an opensocket callback, what exactly would that be used
> for? The reason I'm asking is that if you want to be able to pass in a
> socket that is already for exampled tunneled over some other medium you
> may want to tell c-ares to _not_ do the connect() afterwards or similar.
>
> I figure an opensocket callback would need a corresponding closesocket
> version as well.
>

I use curl in a cross platform c++ application(linux, windows & mac). In
linux and mac, I use c-ares as name resolver. I also use boost::asio
instead of libevent for socket monitoring.

A platform limitation of asio on windows, requires me to have all the
sockets used by curl be opened by asio. For this reason I use curl
opensocket/closesocket/sockopt callbacks. But c-ares doesn't have this
option. This is not an issue since c-ares will not come into picture on
windows, but has the side effect of having some platform specific code
and this is my current state.

As Daniel mentioned opensocket would involve quite some work. And I am
afraid this might be a very specific use case and may not be useful to
others. Since the incentive is low, compared to the work involved, I
couldn't work on this. I guess for Fredrik also this would be too much
unnecessary work, since he only wants to configure the socket.

But If such a need arise, and people are interested, with
ares_set_sockopt_callback in place, we should be able to add missing
callbacks(open/close) and follow the same curl design without too much
difficulties.

-lijo

headers

Lijo Antony | 28 Jun 2012 13:24

Re: socket callbacks

On 06/28/2012 11:53 AM, Fredrik Jansson wrote:
> Hi!
>
> That kind of open/close-socket functions would work great for me.
>
> I cannot see that there is that much work with this approach:
>
> 1. Check if we have opensocket cb otherwise call socket.
>
> The opensocket_cb would have the sams arguments as the "socket" call plus an additional user data ptr.
>
> 2. Replace the sclose macro with a function that checks if we have a closesocket cb.
>
> Or am I over simplifying things?
>

This is correct.
But for a generic use case, a few more aspects may have to be 
considered. For example, as Daniel mentioned, if user want to return a 
socket which is already connected, there should be a way to inform 
c-ares, not to do connect again. Callbacks may also require parameters, 
by which c-ares can inform additional details for the socket(ip, port, 
protocol etc). I guess Daniel and others would be able to give better 
suggestions on this.

> Lijo, would that provide what you (will) need?

My use case would require the c-ares interface be similar to (and 
complex) that of libcurl. Specifically, I would require the socket 
details in opencallback and a way to avoid connect by c-ares, possibly 
using sockopt callback.

I think the best way would be to go ahead with the way you want it. 
Additional features can be added later. You may want to take a look at 
libcurl interface, as it would help you to have an extensible api.

-lijo

headers

Fredrik Jansson | 29 Jun 2012 09:14

RE: socket callbacks

Ok, sounds good. I will go ahead and implement the ares_set_socket_sockopt_cb functionality. 

Attached is a patch file for that simple change, if it is ok I will add the documentation.

Thanks,
Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Lijo Antony [lta@...]
Sent: Thursday, June 28, 2012 13:24
To: c-ares@...
Subject: Re: socket callbacks

On 06/28/2012 11:53 AM, Fredrik Jansson wrote:
> Hi!
>
> That kind of open/close-socket functions would work great for me.
>
> I cannot see that there is that much work with this approach:
>
> 1. Check if we have opensocket cb otherwise call socket.
>
> The opensocket_cb would have the sams arguments as the "socket" call plus an additional user data ptr.
>
> 2. Replace the sclose macro with a function that checks if we have a closesocket cb.
>
> Or am I over simplifying things?
>

This is correct.
But for a generic use case, a few more aspects may have to be
considered. For example, as Daniel mentioned, if user want to return a
socket which is already connected, there should be a way to inform
c-ares, not to do connect again. Callbacks may also require parameters,
by which c-ares can inform additional details for the socket(ip, port,
protocol etc). I guess Daniel and others would be able to give better
suggestions on this.

> Lijo, would that provide what you (will) need?

My use case would require the c-ares interface be similar to (and
complex) that of libcurl. Specifically, I would require the socket
details in opencallback and a way to avoid connect by c-ares, possibly
using sockopt callback.

I think the best way would be to go ahead with the way you want it.
Additional features can be added later. You may want to take a look at
libcurl interface, as it would help you to have an extensible api.

-lijo

Attachment (socket_callback.patch): application/octet-stream, 4633 bytes

headers

Daniel Stenberg | 30 Jun 2012 23:38

RE: socket callbacks

On Fri, 29 Jun 2012, Fredrik Jansson wrote:

> Attached is a patch file for that simple change, if it is ok I will add the 
> documentation.

You used TABs when the existing code uses spaces and you left trailing white 
spaces in there. A corrected version looks like attached here.

I think it looks fine to me. If you provide a man page for this new 
functionality I'm ready to merge!

--

-- 

  / daniel.haxx.se

Attachment (0001-Added-ares_set_socket_sockopt_callback.patch): text/x-diff, 5091 bytes

headers

Fredrik Jansson | 2 Jul 2012 09:11

RE: socket callbacks

Sorry about the TABS and white spaces!

A man page is in crafting, will send you one during the day.

Best regards,
Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Daniel Stenberg [daniel@...]
Sent: Saturday, June 30, 2012 23:38
To: c-ares hacking
Subject: RE: socket callbacks

On Fri, 29 Jun 2012, Fredrik Jansson wrote:

> Attached is a patch file for that simple change, if it is ok I will add the
> documentation.

You used TABs when the existing code uses spaces and you left trailing white
spaces in there. A corrected version looks like attached here.

I think it looks fine to me. If you provide a man page for this new
functionality I'm ready to merge!

--

  / daniel.haxx.se

headers

Fredrik Jansson | 2 Jul 2012 10:01

RE: socket callbacks

Daniel,

attached is a patch for the added man page.

Regards,
Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Fredrik Jansson [fredrik.jansson@...]
Sent: Monday, July 02, 2012 09:11
To: c-ares hacking
Subject: RE: socket callbacks

Sorry about the TABS and white spaces!

A man page is in crafting, will send you one during the day.

Best regards,
Fredrik
________________________________________
From: c-ares-bounces@...
[c-ares-bounces@...] on behalf of Daniel Stenberg [daniel@...]
Sent: Saturday, June 30, 2012 23:38
To: c-ares hacking
Subject: RE: socket callbacks

On Fri, 29 Jun 2012, Fredrik Jansson wrote:

> Attached is a patch file for that simple change, if it is ok I will add the
> documentation.

You used TABs when the existing code uses spaces and you left trailing white
spaces in there. A corrected version looks like attached here.

I think it looks fine to me. If you provide a man page for this new
functionality I'm ready to merge!

--

  / daniel.haxx.se

Attachment (ares_added_man.patch): application/octet-stream, 2976 bytes