Hi Timo,
On 03-01-2012 07:41, Timo Teräs wrote:
>>> On 01/02/2012 11:01 PM, Henrik Størner wrote:
>>>> I then thought that after 10 seconds, my callback would be invoked with
>>>> a status of ARES_ETIMEOUT, but that does not happen.
>> Running it does appear to indicate that something happens as part of the
>> timeout setting, since the timeout returned from ares_timeout() changes
>> ever so slightly around the time that the timeout *should* happen:
>> $ ./a.out
[snip]
>> timeout during select
>> select timeout=1.000000, maxfd=4
>> timeout during select
>> select timeout=0.991000, maxfd=4
>> timeout during select
>> select timeout=1.000000, maxfd=4
>> timeout during select
>>
>> See how on the 10th round of the loop, the timeout is 0.991 seconds
>> instead of a round 1.0 ? So something is happening with this 10 second
>> timeout, but unfortunately it doesn't trigger the timeout callback.
>
> I believe you are too hasty. The timeout is the time out until first
> resend of query happens.
>
> ARES_OPT_TIMEOUT is documented as:
> The number of seconds each name server is given to respond
> to a query on the first try. (After the first try, the
> timeout algorithm becomes more complicated, but scales
> linearly with the value of timeout.)
Hmm, ok then ... it seems you are right, so my misunderstanding came
from what the timeout is supposed to do - it's a timeout per query, not
for the entire request. And it increases for each time the query is resent.
Running this again, setting the timeout to 10 causes the timeout event
to trigger after 117 seconds with the default number of tries, and after
29 seconds if I reduce "tries" to 2.
Thanks for your help, now I understand what is going on. I'll use a
smaller timeout value so it is a bit more agressive with retrying the
request.
Regards,
Henrik
Received on 2012-01-03