TCP's non-blocking connect and accept

The default state of the socket is blocked, which means that when a socket call is issued that cannot be completed immediately, its process is put to sleep, waiting for the response operation to complete, and possibly blocking socket calls can be divided into the following four classes:

(1) Input operation, including read,readv,recv,recvfrom,recvmsg;

(2) Output operation, including write,writev,send,sendto,sendmsg;

(3) Accept the external connection, that is, the accept function.

(4) Initiating an outgoing connection, that is, the Connect function of TCP;

Non-blocking Connect:

When connect is called on a non-blocking TCP socket, connect returns an einprogress error immediately, but the already initiated TCP three-way handshake continues. We then use Select to detect the established condition for this connection or for success or failure. Non-blocking Connect has three uses:

(1) We can stack the three-way handshake on the other processing, complete a connect to spend the RTT time, and the RTT fluctuation is very large, from a few milliseconds on the LAN to hundreds of milliseconds or even a few seconds of the WAN. There may be other tasks that we want to perform during this period of time;

(2) We can use this technology to establish multiple connections simultaneously; This technology is popular with web browsers;

(3) Since using Select to wait for a connection to be established, we can specify a time limit for select so that we can shorten the timeout for connect.

Non-blocking Connect details:

(1) Although the socket is non-blocking, if the server connected to the same host, then when we call connect, the connection is usually immediately established, we have to deal with this situation;

(2) The following two principles for select and nonblocking connect are derived from Berkeley implementations (and POSIX):

-(a) When the connection is successfully established, the descriptor becomes writable;

-(b) The descriptor becomes both readable and writable when an error is encountered when the connection is established;

Non-blocking Accept:

In a busy server, after the three handshake has been established, the client disconnects may occur before the call to accept, such as after the three handshake, the client sends the RST, and then the server calls accept. POSIX indicates that this situation is errno set to connaborted;

Note that in the Berkeley implementation, the error is not returned, but the connection that completes the three handshake is removed from the completed queue, and in this case, if we hear a new connection complete with SELECT, it is then removed from the completion queue, At this point, if the call blocking accept will cause blocking;

Workaround:

(1) When using Select to listen to the socket to complete the connection, always set the listener socket to non-blocking;

(2) Ignore the following error in subsequent accept calls, Ewouldblock (Berkeley implementation, Customer abort connection), econnaborted (POSIX implementation, customer abort connection), Eproto (SERV4 implementation, customer abort connection) and EINTR (if a signal is captured);

TCP's non-blocking connect and accept