Remember last year in the Department of Practice in the sliding window of the problem, suppressed for a long time to solve ....

Original address: Http://blog.csdn.net/yusiguyuan/article/details/21439633#1536434-tsina-1-74921-66a1f5d8f89e9ad52626f6f40fdeadaa

TCP/IP Details--an example of the relationship between a Send/receive buffer and a sliding window protocol.

An example of the relationship between the send buffer, the accept buffer, and the sliding window protocol is understood.

In the above few articles briefly introduced the above several concepts in the TCP network programming relations, also corresponds to several basic socket system calls several behaviors, here again to cite an example, because for each TCP socket, there is a send buffer and receive buffer corresponding to it, So here only to do single-direction communication, do not interact, in the recv end does not send, on the send side does not recv. Carefully figure out the meaning.

First, Recv end

In the listening socket ready to accept, after the end of the accept do not do anything, directly sleep for a long time, that is, at the recv end does not do the operation to accept data, after the end of sleep recv data.

Second, send end

By looking at the default supported maximum send buffer size for this system kernel, CAT/PROC/SYS/NET/IPV4/TCP_WMEM, the last parameter is the maximum size of the send buffer. The configuration file that accepts the maximum buffer is in tcp_rmen.

Sets the socket to block, the buffer sent at a time is greater than the maximum send buffer can hold the amount of data, one send end, after the send returned and then promised to send the length of the data

Test results:

Phase One:

Reception performance: When the data is initially sent, the receiver is in a slow-boot state, the sliding window size is larger, but because the receiving side does not handle the data in the receiving buffer, its sliding window is getting smaller (because the receiving end responds to the win size in the sender to indicate how much data the receiving end can accept. The next time the sender sends the size of the data can not exceed the size of win in the response, the last send side response to the receiver of the ACK displayed in the win size of 0, indicating that the receiving side can no longer accept data.

Send side performance: The sender has been unable to return, if the receiver has been responding to win 0, the sending end will not return, the deadlock continues until the end of sleep on the receiving end.

Reason analysis: First of all, we need to understand a few facts, blocking I/O will wait until this operation is complete; the sender receives a response from the receiving end before the data in the send buffer can be emptied.

At the receiving end of the recv, the receiving buffer will always have data, accept the buffer full, resulting in a sliding window of 0, resulting in the sender can not send data. But why does the send operation have to be undone? The send operation simply copies the data from the application buffer to the send buffer, but the data in the send buffer does not fully get the ACK response from the receiving end, so the data in the send buffer cannot be discarded, causing the send buffer to be filled so that the data in the application layer cannot be copied into the kernel send buffer. will always block here until you can continue to copy the application layer's data to the send buffer, and when to trigger this operation? Wait until the sending side responds to win greater than 0 o'clock to have such an operation.

Phase two;

Accepted: After sleep is finished, the call to the RECV system begins. At this point the receiving end of the sliding window starts again greater than 0. Then this wakes the sending side to continue sending the data.

Send side: The sender receives a response from the receiving side win greater than 0, this time the sender can also copy the data in the application layer buffer into the kernel's send buffer.

Cause analysis: Because the receiver call recv to copy the kernel accepts the buffer data to the application layer, so that the sliding window is more than 0, so that the sending side continues to send data, because the sender can send data, the kernel stack will send the data in the buffer to the receiving end, so that the sending buffer space, Then the send operation can copy the data from the application layer to the send buffer! Such operations are persisted until the send operation returns, which means that the data for the application layer is copied all the way to the send buffer, but does not mean that the data is sent to the peer. The flag sent to the peer succeeds is to accept the ACK response to the peer, at which point the sender can discard the data from the send buffer. The reason for not discarding is that you are always ready to re-send lost/faulted data!

PS:TCP Communication in order to ensure the reliability of the data sent each need to get the other side of the ACK to confirm the other party received (only to ensure that the other TCP receive buffer received data, but does not guarantee that the other application to fetch data), if each time you send to stop waiting for each other's ACK message, Obviously a huge waste of resources and inefficient, then there is the appearance of sliding window.
The sender's sliding window maintains the currently sent frame sequence number, has emitted the frame of the timer, the receiver's current window size (by the receiver ACK notification, roughly equal to the receive buffer size-unhandled message packets), the receiver sliding window to save the received frame information, the expected frame number of the next frame, etc. As for how the sliding window works, don't say it here.
A socket has two sliding windows (a sendbuf, a recvbuf), the size of the two windows is set by the SetSockOpt function, now the problem is here, through the capture package display, set the window size does not take effect, The final troubleshooting found that setsockopt function is added later, written to the listen function, so that each time the socket is not inherited to get the main socket set window size, no language ah ...
Workaround: setsockopt function ahead of the listen function, so that the server program to start listening before Recvbuf already have, accept the link to get is RECVBUF, start the program run, capture the Package display window is already the size specified.

TCP's sliding window size is actually the number of bytes of the socket's receive buffer size

Second, for the server side of the socket must be set before listen buffer size, because, accept the newly generated socket will inherit the buffer size of the listener socket. For the client socket, be sure to set the buffer size before connet, because the connet requires a three-time handshake process that notifies the other person of its own window size. There is no point in setting the buffer after connet.

Third, because the buffer size in the TCP header only 16 bits to represent, so its maximum value is 65536, but for some cases need to use a larger sliding window, it is necessary to use extended sliding window, such as fiber optic communication network, or satellite long connection network, need the window as large as possible. This will use the expanded 32-bit sliding window size.

Remember last year in the Department of Practice in the sliding window of the problem, suppressed for a long time to solve ....