mirror of https://github.com/moparisthebest/curl
56 lines
2.5 KiB
Plaintext
56 lines
2.5 KiB
Plaintext
|
Doing HTTP Pipelining with libcurl
|
||
|
|
==================================
|
||
|
|
|
||
|
|
Background
|
||
|
|
|
||
|
|
Since pipelining implies that one or more requests are sent to a server before
|
||
|
|
the previous response(s) have been received, it cannot be implemented easily
|
||
|
|
into libcurl's easy interface due to its synchronous nature. We therefore only
|
||
|
|
aim on adding it for multi interface use.
|
||
|
|
|
||
|
|
Considerations
|
||
|
|
|
||
|
|
When using the multi interface, you create one easy handle for each transfer.
|
||
|
|
Bascially any number of handles can be created, added and used with the multi
|
||
|
|
interface - simultaneously. It is an interface designed to allow many
|
||
|
|
simultaneous transfers while still using a single thread.
|
||
|
|
|
||
|
|
Pipelining however, will force us to allow apps to somehow "connect" two (or
|
||
|
|
more) easy handles that are added to a multi handle. The first one sends a
|
||
|
|
request and receives a response, just as normal, while the second (and
|
||
|
|
subsequent) ones need to be attached to the first handle so that it can send
|
||
|
|
its request on the same connection and then sit and wait until its response
|
||
|
|
comes.
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
- 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.
|
||
|
|
|
||
|
|
- We need options to control max pipeline length, and probably how to behave
|
||
|
|
if we reach that limit.
|
||
|
|
|
||
|
|
- 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.
|
||
|
|
|
||
|
|
- Currently (before pipelining) we do not have any code or concept that lets
|
||
|
|
multiple handles share the same physical connection. We need a lock concept
|
||
|
|
and carefully make sure that each handle knows exactly what they can do and
|
||
|
|
when, on the shared connection.
|
||
|
|
|
||
|
|
- We need to keep a linked list of each handle that is part of a single pipe
|
||
|
|
so that if it breaks, we know which handles that need to resend their
|
||
|
|
requests.
|