~ubuntu-branches/ubuntu/lucid/curl/lucid-201101212007

« back to all changes in this revision

Viewing changes to lib/README.multi_socket

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Klose
  • Date: 2007-05-16 15:16:54 UTC
  • mto: (3.1.1 lenny) (1.2.1 upstream)
  • mto: This revision was merged to the branch mainline in revision 12.
  • Revision ID: james.westby@ubuntu.com-20070516151654-x9nkigtr2j0i8d0v
Tags: upstream-7.16.2
ImportĀ upstreamĀ versionĀ 7.16.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
1
Implementation of the curl_multi_socket API
2
2
 
3
 
  Most of the design decisions and debates about this new API have already
4
 
  been held on the curl-library mailing list a long time ago so I had a basic
5
 
  idea on what approach to use. The main ideas of the new API are simply:
 
3
  The main ideas of the new API are simply:
6
4
 
7
5
   1 - The application can use whatever event system it likes as it gets info
8
6
       from libcurl about what file descriptors libcurl waits for what action
38
36
  is that we get a curl_multi_timeout() that should also work with old-style
39
37
  applications that use curl_multi_perform().
40
38
 
41
 
  The easy handle argument was removed fom the curl_multi_socket() function
42
 
  because having it there would require the application to do a socket to easy
43
 
  handle conversion on its own. I find it very unlikely that applications
44
 
  would want to do that and since libcurl would need such a lookup on its own
45
 
  anyway since we didn't want to force applications to do that translation
46
 
  code (it would be optional), it seemed like an unnecessary option.
 
39
  We also added a timer callback that makes libcurl call the application when
 
40
  the timeout value changes, and you set that with curl_multi_setopt().
47
41
 
48
 
  Instead I created an internal "socket to easy handles" hash table that given
 
42
  We created an internal "socket to easy handles" hash table that given
49
43
  a socket (file descriptor) return the easy handle that waits for action on
50
44
  that socket.  This hash is made using the already existing hash code
51
45
  (previously only used for the DNS cache).
52
46
 
53
 
  To make libcurl be able to report plain sockets in the socket callback, I
54
 
  had to re-organize the internals of the curl_multi_fdset() etc so that the
 
47
  To make libcurl able to report plain sockets in the socket callback, we had
 
48
  to re-organize the internals of the curl_multi_fdset() etc so that the
55
49
  conversion from sockets to fd_sets for that function is only done in the
56
50
  last step before the data is returned. I also had to extend c-ares to get a
57
51
  function that can return plain sockets, as that library too returned only
58
52
  fd_sets and that is no longer good enough. The changes done to c-ares have
59
53
  been committed and are available in the c-ares CVS repository destined to be
60
 
  included in the upcoming c-ares 1.3.1 release.
61
 
 
62
 
  The 'shiper' tool is the test application I wrote that uses the new
63
 
  curl_multi_socket() in its current state. It seems to be working and it uses
64
 
  the API as it is documented and supposed to work. It is still using
65
 
  select(), because I needed that during development (like until I had the
66
 
  socket hash implemented etc) and because I haven't yet learned how to use
67
 
  libevent or similar.
68
 
 
69
 
  The hiper/shiper tools are very simple and initiates lots of connections and
70
 
  have them running for the test period and then kills them all.
71
 
 
72
 
  Since I wasn't done with the implementation until early January I haven't
73
 
  had time to run very many measurements and checks, but I have done a few
74
 
  runs with up to a few hundred connections (with a single active one). The
75
 
  curl_multi_socket() invoke then takes 3-6 microseconds in average (using the
76
 
  read-only-1-byte-at-a-time hack). If this number does increase a lot when we
77
 
  add connections, it certainly matches my in my opinion very ambitious goal.
78
 
  We are now below the 60 microseconds "per socket action" goal. It is
79
 
  destined to be somewhat higher the more connections we have since the hash
80
 
  table gets more populated and the splay tree will grow etc.
81
 
 
82
 
  Some tests at 7000 and 9000 connections showed that the socket hash lookup
83
 
  is somewhat of a bottle neck. Its current implementation may be a bit too
84
 
  limiting. It simply has a fixed-size array, and on each entry in the array
85
 
  it has a linked list with entries. So the hash only checks which list to
86
 
  scan through. The code I had used so for used a list with merely 7 slots (as
87
 
  that is what the DNS hash uses) but with 7000 connections that would make an
88
 
  average of 1000 nodes in each list to run through. I upped that to 97 slots
89
 
  (I believe a prime is suitable) and noticed a significant speed increase.  I
90
 
  need to reconsider the hash implementation or use a rather large default
91
 
  value like this. At 9000 connections I was still below 10us per call.
 
54
  included in the c-ares 1.3.1 release.
 
55
 
 
56
  We have done a test runs with up to 9000 connections (with a single active
 
57
  one). The curl_multi_socket() invoke then takes less than 10 microseconds in
 
58
  average (using the read-only-1-byte-at-a-time hack).  We are now below the
 
59
  60 microseconds "per socket action" goal (the extra 50 is the time libevent
 
60
  needs).
92
61
 
93
62
Status Right Now
94
63
 
95
64
  The curl_multi_socket() API is implemented according to how it is
96
 
  documented.
 
65
  documented. We deem it ready to use.
97
66
 
98
67
    http://curl.haxx.se/libcurl/c/curl_multi_socket.html
99
68
    http://curl.haxx.se/libcurl/c/curl_multi_timeout.html
101
70
 
102
71
What is Left for the curl_multi_socket API
103
72
 
104
 
  1 - More measuring with more extreme number of connections
105
 
 
106
 
  2 - More testing with actual URLs and complete from start to end transfers.
107
 
 
108
 
  I'm quite sure we don't set expire times all over in the code properly, so
109
 
  there is bound to be some timeout bugs left.
110
 
 
111
 
  What it really takes is for me to commit the code and to make an official
112
 
  release with it so that we get people "out there" to help out testing it.
 
73
  Real world usage!