Non-blocking sockets, connect(), and socket states

From: Bernard Blackham
Date: Sat Apr 30 2005 - 12:27:32 EST

[previously sent to the allegedly dead netdev@xxxxxxxxxxx]


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at