> I'm currently working on writing down ideas and thoughts around adding
> HTTP Pipelining support to libcurl. Below is my first take at some notes.
> I'm posting this mail to you guys to let you know my intentions and also
> with the hope that perhaps someone has some good ideas or experiences with
> pipelining that they feel like sharing with the rest of us!
cool :)

> To ponder about:
>
> - Explicitly ask for pipelining handle X and handle Y ? It isn't always
> that
> easy for an app to do this association. The lib should probably still
> resolve
> the second one properly to make sure that they actually _can_ be
> considered
> for pipelining. Also, asking for explicit pipelining on handle X may be
> tricky when handle X get a closed connection.
maybe a good way would be to tell the multi interface to "not use more than
N connections" toward a single site, adding more easy handles would let the
multi interface pipe-line them (when authorized by the server)

> - Have an option like "attempt pipelining" and then it _may_ use that if
> an
> existing connection is already present against our target HTTP server?
> May
> cause funny effects if the first transfer is a slow big file and the
> second
> is a very small one... Also probably requires some kind of notification
> support so that the app can get to know that the handle is put "in line"
> for
> pipelining.
yes always the notion of priority (fit small tasks before big tasks, don't
hog resources with big tasks :)
here you may have some kind of "emergency" connection on which you put only
'small' downloads... but if you do not know the size in advance you cannot
make this decision... maybe the story of the big file is just a problem
which cannot be solved because there are no data to base a decision on.

[...]
OK, nothing to say

HIH
Armel
Received on 2006-06-23