After some hard work, I will summarize it.ListenParametersBacklog.
PS: server environment:Ubuntu12.04. Client does not matter: IMac OS X 10.7.
Let's take a look at $ man listen, which contains a passage:
If the backlog argument is greater than the value in/Proc/sys/NET/CORE/somaxconn, Then it
Is silently truncated to that value; the default value in this file is 128. In kernels
Before 2.4.25, this limit was a hard coded value, somaxconn, with the value128.
$Sudo VI/proc/sys/NET/CORE/somaxconnYou can check the somaxconn value of Linux. My value is 128. It looks good to change it to 256...
Upload another image in UNP volume 1 (Note: The following figure shows the status of the connection queue that has not been completed.Syn_recvMay be wrong ):
Okay. Now, let's summarize the situation of my server calling listen:
(Note: Do not test on the same machine. I suspect that the same machine has not experienced three handshakes. I run both the client and server at ubuntu12.04.ProgramNo matter how many backlogs are set, the "link queue completed" keeps rising and does not stop"Swing around 10.)
When the value of backlog is <somaxconn, the number of connected queues that have been completed is the maximum value of backlog. The number of unfinished connection queues is about 10.
When the value of backlog is greater than or equal to somaxconn, the maximum number of connected queues is somaxconn. The number of unfinished link queues is the same as the number of link queues.
Conclusion: On ubuntu12.04, the value of backlog is the value of the connected queue. This value is limited by somaxconn.
Finally, a script is provided to check the value of the two queues on the server (4333 in the script is the port value of my server program ):
#! /Bin/shecho "Number of sockets in the established connection queue" while ["1" = "1"] donetstat-Nat | grep established | grep 4333 | WC-lsleep 2 done
#! /Bin/shecho "Number of sockets in the connection queue not established" while ["1" = "1"] donetstat-Nat | grep syn_recv | grep 4333 | WC-lsleep 2 done
By the way, the listen function is not blocking. It only tells the kernel to enable a port listener. the kernel is actually "listening", not our server program.
Listen converts the first parameter socket to a listener socket.