Socket send and receive Buffers __ Network protocol Learning

For each TCP socket, there is a send buffer and receive buffer corresponding to it, here is an example of the sending buffer, accept buffer, the relationship between the sliding window protocol.

One, recv end

In the listening socket on the preparation of accept, accept after the end of what not to do, direct sleep for a long time, that is, at the recv end do not do to receive data operations, in the end of sleep and then recv data.

Two, send end

By looking at the size of the send buffer supported by this system kernel, CAT/PROC/SYS/NET/IPV4/TCP_WMEM, three parameters, respectively, the minimum, default, and maximum values. The configuration file for the receive buffer is in tcp_rmen.

Sets the socket to block, sending a buffer greater than the amount of data that can be accommodated by the sending buffers, one send end, and then the length of the data sent after the send is returned.

Test Results:

Stage One:

Recv End Performance: At the start of sending data, the receiver is in a slow-start state and the sliding window is getting larger, but because the receiver does not process the data in the receive buffer, its sliding window is getting smaller (because the receiving side responds to the win size in the sender to indicate how much data is acceptable to the receiver). The sender can not send more data than the size of the win in the response, the final sender to respond to the receiving side of the ACK shown in the win size of 0, indicating that the receiving end can not accept data.

Send End performance: The sender has been unable to return, if the receiver has been responding to win 0, the sender's send will not return, the deadlock continues to the receiver end of sleep.

Reason analysis: First need to understand a few facts, blocking I/O will wait, direct to this operation completed, the sender received the response to the receiver to empty the data in the send buffer.

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

Stage Two:

Recv end: Starts calling the RECV system call after the sleep is finished. This time the receiver's sliding window begins to be greater than 0, which wakes the sender to continue sending the data.

Send end: The sender receives a response that is greater than 0 on the receiving end, at which point the sender can copy the data from the application layer buffer to the sending buffer of the kernel.

Because the receiver calls recv to copy the data from the kernel receive buffer into the application layer, the sliding window is more than 0, so the sender is excited to continue sending the data. Since the sender can send the data, the kernel protocol stack sends the data from the send buffer to the receiver, so that there is room for the send buffer, so the send operation can copy the data from the application layer to the sending buffer. Such an operation is persisted until the send operation returns, which means that all the data in the application layer is copied into the send buffer, but does not mean that the data is sent to the end-to-end. The flag that is sent to the End-to-end success is to receive an ACK response to the end, at which point the sender can discard the data from the sending buffer. The reason for not discarding is that you are always ready to send the missing/wrong data.

PS:TCP Communication in order to ensure reliability, each sent data need to get each other's ACK to confirm that the other party received (only to ensure that the other TCP receive buffer received data, but do not guarantee the other application to take the data), then if every time to send a stop waiting for each other's ACK message, Obviously a huge waste of resources and low efficiency, then there is the appearance of sliding window.

The sender's sliding window maintains the currently sent frame sequence number, a timer has been issued to the frame, the receiver's current window size (by the receiver ACK notification, roughly equal to the receiving buffer size-the unhandled packet), the receiver sliding window holds the received frame information, the expected frame number of the next frame, etc. As for the specific workings of the sliding window, this is not to say.

A socket has two sliding windows (a sendbuf, a recvbuf), two window size is set by the SetSockOpt function, now the problem is here, by grasping the packet display, set the window size is not effective, Finally find the SetSockOpt function is added later, written to the back of the listen function, so that each accept out of the socket does not inherit the main socket set window size, no words ah ...

Solution: setsockopt function before the listen function, so before the server program to start monitoring recvbuf already have, accept after the link is recvbuf, start the program to run, grab the Packet display window is already specified size.

Conclusion:

The 1.TCP sliding window size is actually the number of bytes in the socket's receive buffer (SO_RCVBUF) size

2. For the socket on the server side, be sure to set the buffer size before listen, because accept's newly generated socket inherits the size of the buffer that listens on the socket. For a client-side socket, be sure to set the buffer size before connet because the connet requires three handshake and notifies each other of its own window size. It does not make sense to set buffers after connet.

3. Because the size of the buffer is only 16 digits in the TCP header, its maximum value is 65536, but for some cases a larger sliding window is required, using an extended sliding window, such as a fiber-optic high-speed communication network, or a satellite long connection network, which requires a window as large as possible. The extended 32-bit sliding window size is used.

This is the relationship between the sending buffer, the accept buffer, and the sliding window protocol, and I don't know if you understand. Because of the limited knowledge of excellent customers, may not be described properly, I hope we can advise.

Relationship between sending buffer and sliding window for "personal supplement" socket
Socket/send success has nothing to do with sliding windows, but there is a logical, sequential relationship
Socket/send when sending packets to a buffer, look at the value of the sliding window win when you look at the Send buffer size (SO_SNDBUF)--> tcp/send the packet in the send buffer.