So, that code and review touched on pipelining and recovery from
timeouts. That's a good jumping off point for a discussion I
wanted to have on another problem, so...

Libcurl has a number of timeout-like settings. Interesting ones
for the moment are:
  * TIMEOUT
  * CONNECTTIMEOUT
  * LOW_SPEED_LIMIT/LOW_SPEED_TIME

The first two are experiential timeouts. When they expire, it
often means a user expectation hasn't been met and an app should
do something to provide feedback on what's going on or not.

The last two (CONNECTTIMEOUT does double duty) are technical
timeouts. The app isn't getting server activity it expects and
it might try to do something about that: close and restart
connections, probe for problems, adjust load, inform a user.

Under pipelining, this changes. Depending upon how you're
managing requests, TIMEOUT can be pretty useless. It needs to
accommodate request traffic from previously-pipelined responses
which could be from unrelated code. CONNECTTIMEOUT is either
meaningless (trivially 0 when a pipeline is available) or
same-as-always.

LOW_SPEED_LIMIT is still useful. Or would be except that
pipelining has split the request and response phases of a
request. The gap between these two can be fairly long on a
healthy connection and that gap will be included in calculations.

Proposal: break application of LOW_SPEED_LIMIT into two
phases: request and response. Disable and reset working
counters/times between the phases. Document appropriately.

m

--
Monty Brandenberg, Software Engineer                               MCB, Inc.
mcbinc_at_panix.com                                             P.O. Box 425292
mcbinc_at_pobox.com                                   Cambridge, MA  02142-0006
617.864.6907
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html