Hello,

a few month ago I posted about problems with connects under the Atari
FreeMiNT OS.
(
http://thread.gmane.org/gmane.comp.web.curl.library/28807/focus=28819 )

I investigated this problem a bit further. I have not finished
investigations, but I believe I got some news, and I wan't to tell them
before doing further steps, because maybe someone here finds it
interesting and can say something new about it.

1. The TCP connection is established in non-blocking mode.
2. Curl_socket_ready returns success.
3. Curl enters some recv functions which says: "nono, the socket is
not connected" - so Curl_socket_ready failed to verify that the
connection is established.
   I'm not saying that it's an "bug" within Curl_socket_ready, but it
returns success...
4. I assume that curl verifies the connection by checking if sending
data to the socket would block.
   If that's true, that means cURL assumes that also recv can be
entered, altough it just checked if sending would block.
   Here is an part of waitconnect() from select.c:
    /* now select() until we get connect or timeout */
    rc = Curl_socket_ready(CURL_SOCKET_BAD, sockfd,
(int)(timeout_msec>1000?
                                                          
1000:timeout_msec));

To me it seem like Curl_socket_ready is just checking if data can be
send.

I assume that the FreeMiNT kernel says: "Ok to send data", but when
you try to recv data, it fails, because connection setup isn't
finished. Which is perfectly fine with non-blocking sockets. I'm not
quite sure, but I wouldn't describe this behavior as an bug.

What do you say about that? Wouldn't you say that it is an assumption
by curl? Why does it enter the recv function, yes - send wouldn't
block, but does this mean it's OK to call recv? :)

Greets,
m

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-10-08