The No. 518 Day of work

from the day I graduated, I was going to go to the network programming direction, because the Internet has no limit, unfortunately not enough technology, can only find an embedded software engineer to do. Just work, I went to the "TCP/IP detailed" series to see, but a page can not understand, what the hell is this TMD? After doing VxWorks, LINUX+QT, has been stuck in the interface and business logic, and occasionally play the server, but has always been stuck in the call socket and related interfaces, but this is my exposure to the limits of network programming.

But ever since I changed my job as a server developer, I finally got to meet up with the TCP/IP details again, as I was working my step-by-step effort.

I think, this is fate, as long as the heart thinking about that thing, and work for it, then and its fate will surely come.

Well, let's go back to that bug.

     means that the listen (int fd, int backlog) is called after the server enters the working state. To listen to the client connection, which is not very noticeable, but is closely related to the TCP protocol. I turned to the 195th page of the TCP/IP detailed Volume One: protocol, where the backlog is the maximum number of listening queues, with a maximum of 5 written in the book. I'm curious, is that enough? If it is a large concurrency, listen to the queue only 5 locations, to wait for each accept to take away before the empty a position, large concurrency is too late? Of course, the book did not say that the big concurrency situation down, so I searched the code inside is how to write, found that the parameter is somaxconn,winsock2.h inside the definition of this value is 0x7fffffff, so big! How much can actually be used? It has to be tested tomorrow.

In addition, in the process of finding information, I also found a new thing, that is, the completion of the listen queue and the unfinished queue. TCP3 handshake, after the second handshake succeeds, the connection is placed in the unfinished queue, and 3 times the handshake succeeds, it will be placed in the completion queue. If there is data in the completion queue, the accept will be triggered to read the connection, thus establishing the socket for data transmission. And the data also says that the backlog is the sum of the completion queue and the unfinished queue, but does not indicate the percentage of each. I guess that means that there is no proportion, that is, who uses a lot more, like a linked list.

So the problem is, if the queue length really has somaxconn so much, that the main path conjecture is wrong, not because the queue is full of the connection is not, is another reason. But I think there's a limit to the queue, and it shouldn't be that long. So I'm going to write a test code tomorrow, the idea is this, the server side only listen, the client keeps looping connect, until full, see how many can connect. Do not know is not feasible, if not, find another way to test.

Being able to study these little things is actually fun.

The No. 518 Day of work