Thanks for that patch. I will test it.

However, I also wonder why the ares doesn't timeout properly. I put some
debugging code and found it never timed out. I am looking into ares, but I
haven't got any clue yet. I am not an expert in tcp/ip programming. :(

> On Mon, 29 Mar 2004, Roy Shan wrote:
>
>> After adding debugging code as you advised, I did observe that handles
>> got
>> stuck in the state of CURLM_STATE_WAITRESOLVE.
>
> Ok, having that verified it is pretty obvious that we don't handle name
> lookup
> timeouts properly in there. I was naively assuming that ares took care of
> those automatically.
>
>> I guess there's a bug in the Curl_is_resolved() or host_callback(),
>> although
>> I can't figure it out now.
>
> Can you try to apply the following patch to see if it makes these lookups
> timeout properly? I'm not sure 180 seconds is a very good timeout value to
> use
> but it seems useful in a first shot just to see if this cures your
> problem.
>
> --- hostip.c 29 Mar 2004 21:29:24 -0000 1.131
> +++ hostip.c 30 Mar 2004 08:12:00 -0000
> @@ -482,9 +482,20 @@
> int count;
> struct SessionHandle *data = conn->data;
> int nfds;
> + long diff;
>
> FD_ZERO(&read_fds);
> FD_ZERO(&write_fds);
> +
> + diff = Curl_tvdiff(Curl_tvnow(),
> + data->progress.t_startsingle)/1000;
> +
> + if(diff > 180) {
> + /* Waited >180 seconds, this is a name resolve timeout! */
> + failf(data, "Name resolve timeout after %ld seconds", diff);
> + return CURLE_OPERATION_TIMEDOUT;
> + }
> +
> nfds = ares_fds(data->state.areschannel, &read_fds, &write_fds);
>
> count = select(nfds, &read_fds, &write_fds, NULL,
>
>
> --
> Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
> Dedicated custom curl help for hire: http://haxx.se/curl.html
>
Received on 2004-03-30