Listen&backlog of TCP

1. Listen function:

#include <sys/socket.h>int Listen (intint  ), ret-Successful return 0 failure return-1 

Listen is called only by the server, and it does two things:

(1) When a socket is created, it is assumed to be an active socket, that is, it is a client socket that will invoke connect to initiate a connection. The Listen function converts an unbound socket into a passive socket, indicating that the kernel should accept connection requests to the socket, and calling listen to convert the socket from closed state to listen state;

(2) The backlog specifies the maximum number of connections that the kernel should queue for the corresponding sockets;

2. Meaning of the backlog:

The kernel maintains two queues for a given listener socket, and the sum of two queue items does not exceed the backlog:

(1) The connection queue is not completed, each SYN sub-section corresponds to one of the items, has been issued by a client and reached the server, and the server is waiting to complete the corresponding TCP three handshake process, these sockets in the SYN_RCVD state;

(2) The connection queue has been completed, each of the customers who have completed three handshake process corresponds to one of them, these sockets are in the established State;

Note: For example, accept is to take a connection from the completed queue header to service, so accept is the process after the three-time handshake;

3. Three-time handshake and two queues:

(1) When Syn arrives, TCP creates a new item in the unfinished queue and then responds to the second subsection of the three handshake, which remains in the unfinished queue until the third section of the three handshake arrives or times out;

(2) When a SYN arrives, the queue is full, TCP ignores the sub-section, the client resend the SYN, expecting to find free space in these queues soon, and sending the RST is wrong because the client cannot differentiate whether the RST is no service or the queue is full;

(3) If the three-time handshake is completed normally, the item never completes the queue and moves to the end of the completed queue;

(4) When the process calls accept, the header item in the connection queue has been completed to be returned to the process, or if the queue is empty, the process will be put to sleep until TCP puts an entry in the queues to wake it up;

Listen&backlog of TCP