cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Anyone for HTTP Pipelining?

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 28 Jun 2006 22:56:16 +0200 (CEST)

On Wed, 28 Jun 2006, Ravi Pratap wrote:

> I think it's easier to make it an option on the multi handle. Basically the
> user tells the multi handle to pipeline requests made by the easy handles,
> when possible. Curl then makes decisions internally about how and when to
> pipeline.

Yeah, I agree - it seems suitable to activate such a thing for the entire
multi handle at once. In a future we could possibly add options that allow you
to specificly exclude single easy handles from being subject to pipelining -
if we ever face a situation where it is meaningful.

> Curl can also impose an internal (or configurable?) limit on the maximum
> number of connections that can be pipelined to a server.

We can start with a fixed internal limit and make it configurable when things
start to actually work.

>> - Have an option like "attempt pipelining" and then it _may_ use that
>> if an existing connection is already present against our target HTTP
>> server?
>
> The thing is that it is pretty hard for Curl to decide what to do based on
> response length and it is probably best to leave this to the application.
> Since pipelining is per multi handle, the application can always use a
> different multi handle when it doesn't want a large request to interfere.

Yeps. I didn't mean it would base it on the response lengths or anything, I
just meant that when an application says to libcurl that it may use pipelining
for requests, the effect may be that a previous big slow transfer will delay
the latter small fast transfer quite significantly. But of course, with some
nice info text about the pipelining status, just enabling verbose will reveal
this information.

>> - When a pipeline is in use, we must take precautions so that we either
>> don't allow the used handles (i.e those who still wait for a response) to
>> be removed, or we allow removal but still deal with the outstanding
>> response somehow.
>
> I would allow removal and then have libcurl discard the response for that
> particular easy handle if that isn't hard to do.

I figure it should be fairly easy. We need to hold a linked list with nodes
for handles involved in the pipeline anyway, and we could just mark the nodes
for which the handle has been removed and then we simply "eat and discard"
that response.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2006-06-28