On Thu, Apr 6, 2017 at 9:04 PM, Daniel Stenberg <dan...@haxx.se> wrote: > On Thu, 6 Apr 2017, Rainer Canavan wrote: > >> it looks like curl_multi_timeout() doesn't always respect >> CURLOPT_LOW_SPEED_TIME. > > I'm not entirely sure why that is so, but I'd like to mention that the > CURLOPT_LOW_SPEED_TIME handling and its timeouts were just now changed, in > commit 29147ade0456a which landed just hours ago.
I can't find that commit anywhere, is that 2d5711dc11 in the github repository? > When CURLOPT_LOW_SPEED_TIME is set, libcurl should now use no longer than > 1000ms timeouts. I've just merged 2d5711dc11 into 7.53.1, and I don't really see an improvement. curl_multi_timeout() still returns the same erratic values, but docs/examples/multi-app.c protects itself by limiting the select timeout to 1s, so I suppose I'll have to do the same. The other thing is that I would have expected CURLOPT_LOW_SPEED_TIME to be the actual interval over which the speed is measured, i.e. if a server does not send any data for 2 * CURLOPT_LOW_SPEED_TIME seconds, the transfer should always fail. The actual implementation uses progress.current_speed, which is averaged over longer periods with the result that bursty transfers are kept going. That's perfectly fine, and probably more useful in reality than how I thought it would work, but I would say the documentation could be clearer. Rainer ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html