diff options
Diffstat (limited to 'lib/README.pipelining')
| -rw-r--r-- | lib/README.pipelining | 55 |
1 files changed, 55 insertions, 0 deletions
diff --git a/lib/README.pipelining b/lib/README.pipelining new file mode 100644 index 000000000..73424aa6b --- /dev/null +++ b/lib/README.pipelining @@ -0,0 +1,55 @@ +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. |