Ha! That's awesome, exactly what I was looking for. Thanks a lot Daniel!
David
2017-01-26 14:32 GMT+01:00 <daniel_at_poradnik-webmastera.com>:
> You can also register callbacks using ares_options::sock_state_cb and
> ares_set_socket_callback(), which simplifies things a lot. I used them when
> I was integrating c-ares with our epoll-based code.
>
> Daniel
>
>
> W dniu 2017-01-25 18:48, David Guillen Fandos napisał(a):
>
>> Ha!
>>
>> Sorry for that, I just realized that it returns a bitmap of sockets.
>> Why doesn't it return something like uint32_t?
>>
>> Allright then, so there's really no way to workaround my problem
>> except, perhaps, to initialize c-ares at the begining of the process.
>> But c-ares doesn't guarantee that all fds are gonna get created at
>> start right? If some server doesn't respond it might try TCP and open
>> a new socket, am I right?
>>
>> Thanks for your help!
>> David
>>
>> On 25/01/17 15:17, Daniel Stenberg wrote:
>>
>>> On Wed, 25 Jan 2017, David Guillen Fandos wrote:
>>>
>>> Yeah agreed, but how do you retrieve the fds to use poll? With getsock
>>>> you get up to 16 sockets which is insufficient for my needs (and also,
>>>> BTW, sounds like an arbitrary and ridiculous number to hardcode in
>>>> such a function)
>>>>
>>>
>>> Arbitrary? Not really, it happens to be the number that fits in an
>>> unsigned 32bit variable as each socket needs two bits in the API. I just
>>> considered it a dececently convenient API at the time (and happens to be
>>> similar to a function interface we use internally in libcurl).
>>>
>>> Ridiculous? Maybe, but I added that API a long time ago and I have yet
>>> to end up in a case where the 16 limit has been reached and impacted us
>>> (or anyone else). I added this API to allow libcurl to use c-ares
>>> event-based and we've since used it with many thousand simultaneous
>>> requests and DNS looks with success - over the period of many years.
>>>
>>> Can it be improved? I'm sure.
>>>
>>>
Received on 2017-01-26