[lkml]   [2005]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectNon-blocking sockets, connect(), and socket states
    [previously sent to the allegedly dead]


    Through playing with tcpcp[1], I've found out about a quirk in the
    kernel's handling of non-blocking connection-based sockets. The
    sk_socket->state value can take on one of SS_FREE, SS_UNCONNECTED,
    *blocking*, connection-oriented socket (eg, TCP), after connect()
    returns, sk_socket->state will be SS_CONNECTED.

    However, if the socket is placed into non-blocking mode before the
    connect() call, connect() returns immediately with EINPROGRESS, and
    the sk_socket->state is set to SS_CONNECTING. When the socket
    finally does connect, the application is notified via poll(), but
    the state remains as SS_CONNECTING (which causes issues for tcpcp,
    though doesn't appear to have any other externally visible

    Werner, the author of tcpcp, suggests that the application should
    call connect() on the socket a second time, after the successful
    connection, to force the sk_socket->state value to SS_CONNECTED.

    Should it be the kernel's responsibility to set SS_CONNECTED when
    the connection is established? Or should I go file bugs and submit
    patches on all the applications that use non-blocking sockets and
    don't call connect() a second time?

    Thanks in advance,



    Bernard Blackham <bernard at blackham dot com dot au>
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-30 19:29    [W:0.019 / U:18.160 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site