Meanings of backlog parameters in the listen function of TCP/IP protocol

Article Source: http://www.cppblog.com/thisisbin/archive/2010/02/07/107444.html

To understand the backlog argument, we must realize that for a given listening socket, the kernel maintains two queues:

To understand the meaning of the backlog parameter, we must understand that for a listening socket, the kernel maintains two queues:

1. an incomplete connecting queue, which contains an entry for each SYN that has arrived from a client for which the server is awaiting completion of the TCP three-way handshake. these sockets are in the SYN-RCD state.

1. A queue with unfinished connections. This queue maintains the SYN segmentation information of the client and waits for the connection to complete the three-way handshake. The socket status is syn_rcvd.

 

2. A completed connection queue, which contains an entry for each client with whom the TCP three-way handshake has completed. These sockets are in the established state.

2. A completed connection queue that contains connections that have completed three-way handshakes. The socket status is established.

 

The backlog argument to the listen function has historically specified the maximum value for the sum of both queues.

In history, the backlog parameter is defined as the sum of the preceding two queues.

Berkeley-derived implementations Add a fudge factor to the backlog: It is multiplied by 1.5

In the Berkeley implementation, the backlog value is the sum of the preceding two queues and multiplied by 1.5.

When a SYN arrives from a client, TCP creats a new entry on the incomplete queue and then responds with the second segment of the three-way handshake: the server's SYN with an ACK of the client's Syn (section 2.6 ). this entry will remain on the incomplete queue until the third segment of the three-way handshake arrives (the client's ack of the server's Syn), or until the entry times out. (Berkeley-derived implementations have a timeout of 75 seconds for these incomplete entries .)

When the first SYN of the client arrives, TCP adds a new record to the unfinished queue and then replies to the second shard in the three-way handshake of the client (syn on the server side and ack on the client side ), this record will exist in the unfinished queue until the last shard in the three-way handshake arrives, or until the timeout (the Berkeley time is defined as 75 seconds)

If the queues are full when a client SYN arrives, TCP ignores the arriving Syn (pp. 930-931 of tcpv2); it does not send an rst. this is because the condition is considered temporary, and the client TCP will retransmit its SYN, Hopefully finding room on the queue in the near future. if the server TCP immediately responded with an rst, the client's connect wowould return an error, forcing the application to handle this condition instead of lew.tcp's normal retransmission take over. also, the cilent cocould not differentiate between an RST in response to a SYN meaning "there is no server at this port" versus "there is a server at this port but it's queues are full."

If the queue is full when the client SYN arrives, TCP will ignore the SYN that will arrive later, but will not send the RST information to the client, because at this time, the client is allowed to re-transmit the SYN shard. If an error message is returned, the client cannot tell whether there is no corresponding application on the corresponding port of the server, or whether the queue on the corresponding port of the server is full.