On Fre 09.09.2005 10:31, Daniel Stenberg wrote:
>On Fri, 9 Sep 2005, Alexander Lazic wrote:
>
>>But the app feed the curl_multi_socket() thefore curl_multi_socket()
>>should only have the sockets from the app.
>
>I don't understand what you mean. curl_multi_socket() will tell your
>app what sockets it uses and then your app waits for actions on the
>sockets. libcurl's and your own. Using the method of your choice.

Sorry for my bad english.

My main point was libcurl have sockets and poll()/select on these, the
app have sockets an $POLL on these, therefor when i use
curl_multi_socket() the poll()/select() of the libcurl i can't
influence, i hope i have say it clearer.

The app must know which are his own sockets an which are the libcurl
sockets, imho.

>It should make it possible to use any high-performance lib or method.
>
>It should make libcurl a huge step closer to dealing with the c10k problem.

Full ACK ;-)

>Of course, nothing of this is carved in stone yet so we can still tune
>how these functions should behave.

;-)

>>I think this is the major problem because some functions make their own
>>socket()/connect() calls.
>
>The application's sockets, connects etc are not a concern of libcurl. The
>application deals with its own sockets.

Yes but when i call the *easy* or *multi* functions they make some
handshakes, such as ssl or ftp or whatever, how can i see if the
protocol handshakes was ok or nok?

I think we need some more states then:

0 CURL_POLL_NONE (0) - register, not interested in readiness
1 CURL_POLL_IN - register, interested in read readiness
2 CURL_POLL_OUT - register, interested in write readiness
3 CURL_POLL_INOUT - register, interested in both
4 CURL_POLL_REMOVE - deregister
e. g.:
5 CURL_CONNECT_OK - the protocol handshake was ok
6 CURL_CONNECT_NOK - the protocol handshake was nok
.
.

>Hopefully, it should make libcurl a lot better performing when you use
>it for huge amount of simultanoues transfers.

I think also ;-)

>This fix, together with added HTTP pipeling support, ought to make
>libcurl outperform most of the competition.

What is higher in your priority list, if you have one ;-)?

>With a full time job and a real-life family, the day just don't have
>enough hours.

Oh yes ;-))

>I expect this API to get added eventually, but I can't tell
>when. Hopefully there will show up a company that finds out it wants
>this added that pays someone to make the changes.

This would be the nicest way ;-)

>I'll appreciate help of course.

Well i will try to step in an make a little flowchat so that we talk
about the same ;-)

greetings

al ;-)
Received on 2005-09-09