| 9487f7f | 2011-08-03 07:05:30 -0700 | [diff] [blame] | 1 | Implementation of the curl_multi_socket API |
| 2 | |
| 3 | The main ideas of the new API are simply: |
| 4 | |
| 5 | 1 - The application can use whatever event system it likes as it gets info |
| 6 | from libcurl about what file descriptors libcurl waits for what action |
| 7 | on. (The previous API returns fd_sets which is very select()-centric). |
| 8 | |
| 9 | 2 - When the application discovers action on a single socket, it calls |
| 10 | libcurl and informs that there was action on this particular socket and |
| 11 | libcurl can then act on that socket/transfer only and not care about |
| 12 | any other transfers. (The previous API always had to scan through all |
| 13 | the existing transfers.) |
| 14 | |
| 15 | The idea is that curl_multi_socket_action() calls a given callback with |
| 16 | information about what socket to wait for what action on, and the callback |
| 17 | only gets called if the status of that socket has changed. |
| 18 | |
| 19 | We also added a timer callback that makes libcurl call the application when |
| 20 | the timeout value changes, and you set that with curl_multi_setopt() and the |
| 21 | CURLMOPT_TIMERFUNCTION option. To get this to work, Internally, there's an |
| 22 | added a struct to each easy handle in which we store an "expire time" (if |
| 23 | any). The structs are then "splay sorted" so that we can add and remove |
| 24 | times from the linked list and yet somewhat swiftly figure out both how long |
| 25 | time there is until the next nearest timer expires and which timer (handle) |
| 26 | we should take care of now. Of course, the upside of all this is that we get |
| 27 | a curl_multi_timeout() that should also work with old-style applications |
| 28 | that use curl_multi_perform(). |
| 29 | |
| 30 | We created an internal "socket to easy handles" hash table that given |
| 31 | a socket (file descriptor) return the easy handle that waits for action on |
| 32 | that socket. This hash is made using the already existing hash code |
| 33 | (previously only used for the DNS cache). |
| 34 | |
| 35 | To make libcurl able to report plain sockets in the socket callback, we had |
| 36 | to re-organize the internals of the curl_multi_fdset() etc so that the |
| 37 | conversion from sockets to fd_sets for that function is only done in the |
| 38 | last step before the data is returned. I also had to extend c-ares to get a |
| 39 | function that can return plain sockets, as that library too returned only |
| 40 | fd_sets and that is no longer good enough. The changes done to c-ares are |
| 41 | available in c-ares 1.3.1 and later. |
| 42 | |
| 43 | We have done a test runs with up to 9000 connections (with a single active |
| 44 | one). The curl_multi_socket_action() invoke then takes less than 10 |
| 45 | microseconds in average (using the read-only-1-byte-at-a-time hack). We are |
| 46 | now below the 60 microseconds "per socket action" goal (the extra 50 is the |
| 47 | time libevent needs). |
| 48 | |
| 49 | Documentation |
| 50 | |
| 51 | http://curl.haxx.se/libcurl/c/curl_multi_socket_action.html |
| 52 | http://curl.haxx.se/libcurl/c/curl_multi_timeout.html |
| 53 | http://curl.haxx.se/libcurl/c/curl_multi_setopt.html |