git-svn-id: svn://10.65.10.50/branches/R_10_00@23289 c028cbd2-c16b-5b4b-a496-9718f37d4682
		
			
				
	
	
		
			54 lines
		
	
	
		
			2.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			54 lines
		
	
	
		
			2.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| Implementation of the curl_multi_socket API
 | |
| 
 | |
|   The main ideas of the new API are simply:
 | |
| 
 | |
|    1 - The application can use whatever event system it likes as it gets info
 | |
|        from libcurl about what file descriptors libcurl waits for what action
 | |
|        on. (The previous API returns fd_sets which is very select()-centric).
 | |
| 
 | |
|    2 - When the application discovers action on a single socket, it calls
 | |
|        libcurl and informs that there was action on this particular socket and
 | |
|        libcurl can then act on that socket/transfer only and not care about
 | |
|        any other transfers. (The previous API always had to scan through all
 | |
|        the existing transfers.)
 | |
| 
 | |
|   The idea is that curl_multi_socket_action() calls a given callback with
 | |
|   information about what socket to wait for what action on, and the callback
 | |
|   only gets called if the status of that socket has changed.
 | |
| 
 | |
|   We also added a timer callback that makes libcurl call the application when
 | |
|   the timeout value changes, and you set that with curl_multi_setopt() and the
 | |
|   CURLMOPT_TIMERFUNCTION option. To get this to work, Internally, there's an
 | |
|   added a struct to each easy handle in which we store an "expire time" (if
 | |
|   any). The structs are then "splay sorted" so that we can add and remove
 | |
|   times from the linked list and yet somewhat swiftly figure out both how long
 | |
|   time there is until the next nearest timer expires and which timer (handle)
 | |
|   we should take care of now. Of course, the upside of all this is that we get
 | |
|   a curl_multi_timeout() that should also work with old-style applications
 | |
|   that use curl_multi_perform().
 | |
| 
 | |
|   We created an internal "socket to easy handles" hash table that given
 | |
|   a socket (file descriptor) return the easy handle that waits for action on
 | |
|   that socket.  This hash is made using the already existing hash code
 | |
|   (previously only used for the DNS cache).
 | |
| 
 | |
|   To make libcurl able to report plain sockets in the socket callback, we had
 | |
|   to re-organize the internals of the curl_multi_fdset() etc so that the
 | |
|   conversion from sockets to fd_sets for that function is only done in the
 | |
|   last step before the data is returned. I also had to extend c-ares to get a
 | |
|   function that can return plain sockets, as that library too returned only
 | |
|   fd_sets and that is no longer good enough. The changes done to c-ares are
 | |
|   available in c-ares 1.3.1 and later.
 | |
| 
 | |
|   We have done a test runs with up to 9000 connections (with a single active
 | |
|   one). The curl_multi_socket_action() invoke then takes less than 10
 | |
|   microseconds in average (using the read-only-1-byte-at-a-time hack).  We are
 | |
|   now below the 60 microseconds "per socket action" goal (the extra 50 is the
 | |
|   time libevent needs).
 | |
| 
 | |
| Documentation
 | |
| 
 | |
|     http://curl.haxx.se/libcurl/c/curl_multi_socket_action.html
 | |
|     http://curl.haxx.se/libcurl/c/curl_multi_timeout.html
 | |
|     http://curl.haxx.se/libcurl/c/curl_multi_setopt.html
 |