cURL / Mailing Lists / curl-library / Single Mail

curl-library

Thoughts on Implementing Persistant Connection Support

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 15 Feb 2001 18:45:12 +0100 (MET)

Disclaimer: these ideas are not yet fully considered or even likely to be how
this will end up like. Feel free to object, fill in, complain or suggest
otherwise. I'm just posting these ideas at an early stage for you to have a
chance to participate. Some of this comes from earlier posts, from me and
others.
   ---------- snip ----------------
GOAL

  To introduce a way for libcurl to do multiple file transfers using the same
  connection.

HOW

  curl_easy_perform() would
  - not disconnect from the server when one file has been transfered, it
    leaves the connection "open" for further use
  - re-use an earlier opened connection if one exist to the server we are
    about to transfer a document to/from, the re-usage would deal with the
    fact that the connection might have timed out or similar
  - open more connections and keeep the old one(s) open if the new document
    needs a new connection
  - have a maximum amount of simultaneously opened connections and close the
    oldest when that amount is reached

  1. An option to determine how many connections can be opened simultaneously.
     If zero, connections will be closed after each transfer (as today).

     CURLOPT_MAXCONNECTIONS - default is ... like 5?

     Note that the current interface *requires* the user to init/ perform/
     cleanup for every transfer, so there's no way old programs can be made to
     automatically transform to use persistant connections just by upgrading
     the library. But by using sensible defaults, the only change needed would
     be to move the init() and cleanup() calls to outside the loop and do them
     only once.

  2. An option to determine the strategy used to close persistant connections.
     Strategies can be to close
       o the oldest (from its creation date)
       o the least recently used
       o the one with least traffic
       o round-robin, random, etc.

     CURLOPT_CLOSINGPOLICY - default is CURLCLOSEPOLICY_OLDEST
        CURLCLOSEPOLICY_OLDEST,
        CURLCLOSEPOLICY_LEAST_RECENTLY_USED
        CURLCLOSEPOLICY_LEAST_TRAFFIC,
        CURLCLOSEPOLICY_RANDOM

USAGE

         This could turn out to be working pseudo code:

 curl_easy_init()

 [ a number of ... ] curl_easy_setopt()

 do {

   curl_easy_setopt( URL )

   curl_easy_perform();

 } while( another URL to transfer );

 curl_easy_cleanup()

DESIGN ISSUES

  Jotted down thoughts and ideas on implementation details

  * How to find an already existing connection to use?
   - identical host name (we don't want to do any host lookups)
   - identical port number
   - identical protocol

    Protocol dependent match condtions:
   - (FTP) identical user+passwd, as it is set for the connection in a way
     that differs from HTTP.

    Note: a connection through a HTTP proxy is likely to have all of these
    things in common for almost any remote document, and thus will be much
    more likely to actually use the same connection multiple times.

  * Linked list/reallocated array for keeping connections?

  * Make sure that the Location: following engine uses the multiple connection
    policy just as all connections.

  * We should safely rely on the fact that the function sequence will *always*
    only be one function invoked at a single time using the same curl handle.
    This will be documented, any simultaneous use of the same handle will give
    unknown results.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/
_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-02-15