cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: libcurl - No timeout

From: Roland Krikava <list-subs_at_bluedigits.com>
Date: Mon, 19 Jul 2004 18:24:28 -0400

----- Original Message -----
From: "Daniel Stenberg" <daniel-curl_at_haxx.se>
To: "libcurl development" <curl-library_at_cool.haxx.se>
Sent: Sunday, July 18, 2004 3:28 AM
Subject: Re: libcurl - No timeout

> On Sat, 17 Jul 2004, Roland Krikava wrote:
>
> >> First off, what is a "legitimate connection" and how can libcurl tell?
> >
> > If data is available for reading, I would call this legitimate.
>
> Data is not available all the time, hardly on any connections. There are
> always periods when no data is available. The lengths of those periods can
of
> course vary between milliseconds to hours, days or even weeks. The periods
of
> no-data-available doesn't make the connection ilegitimate, only slow.
>

I don't think when one is sitting in front of Mozilla or IE one would expect
it to take a week to pull up www.yahoo.com. Likewise, if one is doing an
automated http get one would not expect it take a week (of course this
varies depending on the application). One can not rely on the server to be
smart enough to figure out that its connection process is deadlocked, so
this kind of safeguard should be built in on the client side.

> > Large files that take a long time to download could outlast any
> > CURLOPT_TIMEOUT.
>
> Of course, CURLOPT_TIMEOUT is a very rough tool.

Yes it is, and I would have thought not a very useful one given the problems
it presents. After looking into your first suggestion, it seems that the
combination of CURLOPT_LOW_SPEED_LIMIT = 0 and CURLOPT_LOW_SPEED_TIME =
"timeout value" is exactly what I was looking for. My suggestion is that you
turn CURLOPT_TIMEOUT into a shortcut to this combo, or call it
CURLOPT_INACTIVE_TIMEOUT.

>
> > If, however, this timeout was used instead to timeout on inactive
> > connections, this problem would be avoided.
>
> So what is an "inactive connection" ? libcurl can't tell if the server is
> slow, the network is slow or if the server actually decided to stop
sending
> data (without disconnecting).
>
> But then, libcurl offers a method to kill connections with very little
> through-put, if you think that is a good idea. Or you can do your own
> heuristics in one of the callbcks libcurl calls.
>
> --
> Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
> Dedicated custom curl help for hire: http://haxx.se/curl.html
>
>
Received on 2004-07-20