On Sat, 10 Sep 2005, Alexander Lazic wrote:

>>> The app must know which are his own sockets an which are the libcurl
>>> sockets, imho.
>>
>> Oh yes it really should, since among other things it should tell libcurl
>> when action has been dected on libcurl's sockets and not otherwise.
>
> Hm do you mean that libcurl also call the (*curl_socket_callback) for they
> sockets?

libcurl only knows and cars about its own sockets. It calls the callback for
every single socket it uses. Thus, the application will get to know about all
sockets libcurl uses and what to wait for on each socket.

This is similar to how it works today, but today you ask for information about
libcurl's sockets with the curl_multi_fdset() function. In the *socket()
approach libcurl would instead call the callback when the socket situation
changes.

>> But then, why would the application care or even want to know about the
>> connect/handshake status of each connection? It makes no difference to it.
>
> Hm if the callback get CURL_POLL_(IN|OUT|INOUT) then the app can
> read()/write() to the socket, right?

No. If the callback gets called with CURL_POLL_IN, it means that your
application should wait for incoming data on that socket on libcurl's behalf
and when there is data available you call curl_multi_socket() accordingly.

CURL_POLL_OUT is then the same but for a socket that waits to become writable,
and CURL_POLL_INOUT for a socket that wants to both read and write.

But your app doesn't know how to read or write to those sockets as they are
controlled by libcurl.

> I think i can't help you for this, because i'am not sure that i have
> understand the hole idea behind the curl_multi_socket() :-(

I do my best in trying to explain how it is planned to work.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html