[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    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean