TCP socket stick package

Zookeeper

In the past two days, I have seen some questions about socket stick packages and Socket buffer settings in csdn. I found that I am not very clear about these issues, so I will check the information and record it:

 

One or two simple concepts of persistent connections and short connections:
1. persistent connection

The client establishes a communication connection with the server. After the connection is established, the connection is continuously enabled, and then the packets are sent and received.

2. transient connection

The client and server communicate with each other every time a message is sent and received. After the transaction is completed, the connection is closed immediately. This method is usually used for one-to-multiple-point operations.
Communication, such as connecting multiple clients to a server.

 

2. When do I need to consider sticking packets?

1: If TCP is used to send data each time, a connection is established with the other party. After both parties send a piece of data, the connection is closed, in this way, there will be no packet Sticking Problem (because there is only one packet structure, similar to the HTTP protocol ). To close a connection, both parties must send a close connection (refer to TCP close protocol ). For example, if a needs to send a string to B, A establishes a connection with B, and then sends the default Protocol characters of both parties, such as "hello Give me something abour yourself ", after receiving the packet, B receives the data in the buffer zone and closes the connection. Therefore, the packet sticking problem does not need to be considered because it is known to be a piece of character.
2: If the sent data has no structure, such as file transmission, the sender only sends the data, and the receiver only receives the storage and does not need to consider sticking packets.
3: if both parties establish a connection, send different structured data within a certain period of time after the connection. For example, there are several structures after the connection:
(1) "hello Give me something abour yourself"
2) "Don't give me something abour yourself"
In this case, if the sender sends the two packets consecutively, the receiver may receive the packet "hello Give me something abour yourselfdon't give me something abour yourself", and the receiver will be stupid, what is it? I don't know, because the Protocol does not stipulate such a strange string, it is necessary for both parties to organize a better package structure for packet subcontracting, therefore, a packet such as the data length may be added to the header to ensure receipt.
 

Cause of Three-stick packets: UDP does not stick packets during stream transmission because it has message boundaries (refer to Windows Network Programming)
1. The sender needs to wait until the buffer zone is full before sending it out, resulting in sticking packets.
2. the receiver does not receive packets in the buffer zone in time, resulting in receiving multiple packets.

Solution:
To avoid sticking packets, you can take the following measures. First, you can use programming settings to avoid the packet sticking problem caused by the sender. TCP provides an operation command to force data to be transmitted immediately. After the TCP software receives the operation command, this section of data is immediately sent out, without waiting for the sending buffer to be full; second, for the sticky packet caused by the receiver, you can optimize the program design, streamline the workload of the receiving process, and increase the priority of the receiving process so that it can receive data in a timely manner, so as to avoid the phenomenon of sticking packets. The third is controlled by the recipient, A packet of data is manually controlled and received multiple times based on the structure field, and then merged to avoid sticking to the packet.

The three measures mentioned above all have their shortcomings. Although the first programming setting method can avoid the packet sticking caused by the sender, It disables the optimization algorithm, reduces the network sending efficiency, and affects the application performance. This method is generally not recommended. The second method can only reduce the possibility of sticking packets, but it cannot completely avoid sticking packets. When the sending frequency is high, or the network burst may cause a packet to arrive at the receiver quickly for a certain period of time, the receiver may still be too late to receive the package, resulting in sticking to the package. Although the third method avoids sticking packets, the application is less efficient and is not suitable for real-time applications.

Related Articles:

A packet has no fixed length, and the Ethernet is limited to 1500 bytes. Is the MTU of the Ethernet. If the packet exceeds this value, TCP sets an offset for IP datagram for multipart transmission, currently, an 8 K (NTFs series) buffer can be set on the application layer. 8 K of data is split from the underlying layer, and the application only sends data once. The buffer experience in Windows is 4 K. The socket itself is divided into two types: stream (TCP) and datagram (UDP). Your problem varies with the two methods.

Sample. It is even related to whether you use blocking or non-blocking socket for programming.

1. The communication length is determined by yourself. The system does not force you to send a large package. The actual length should be determined based on your needs and network conditions. For TCP, the length can be larger, but you must know that the default size of the buffer for sending and receiving in the socket is about 8 K. You can use setsockopt to change the length. But for UDP, it should not be too large, generally between 1024 and 10 K. Note that, no matter how large a package is, the IP layer and the link layer will send your package in parts. Generally, the LAN is about 1500, And the Wan is only several dozen bytes. The fragmented package will arrive at the receiver through different routes. For UDP, if one of the parts is lost, the IP layer of the receiver will discard the entire packet, which leads to packet loss. Obviously, if a UDP packet is too large to be sent, the link layer will have a high chance of losing parts after it is split. If you have UDP packet, it will be easy to lose, but it is too small and will affect the efficiency. It is best to configure this value to adjust to the optimal state according to different environments.

The send () function returns the actual sending length. When the network keeps, it will never return an (failed to send) error. A maximum of 0 is returned. For TCP, you can write a circular message in bytes. When the send function returns socket_error, it indicates an error. But for UDP, do not write loop transmission, otherwise it will bring great trouble to your reception. Therefore, UDP needs to use setsockopt to change the buffer size inside the socket to accommodate your sending packets. Specifically, as a stream, the packet sending process does not reach the entire package, but is continuously sent, so the receiver must group packets. UDP, as a message or datagram, must arrive at the receiver in the whole package.

2. Generally, packet sending has packet boundary. The first thing you need to do is to let the receiver know the length of the packet, so there is a packet header. For TCP, the receiver first receives the packet header information and then receives the packet data. You can collect the entire package at a time. You can verify whether the result is collected. This completes the group package process. UDP, you can only receive the entire package. If the Received Buffer you provide is too small, TCP returns the actual length of the received buffer, and the rest can be received. The difference between UDP is that the remaining data is discarded and the wsaemsgsize error is returned. Note TCP: If the buffer buffers you provide are large, you may receive multiple sending packets, and you must separate them. When the buffer is too small, you cannot close the data in the socket at a time, therefore, the socket receives the event (onreceive) and may not be triggered again. pay close attention to this when receiving the event. These features reflect the difference between a stream and a data packet.

References:
Http://www.cnblogs.com/alon/archive/2009/04/16/1437600.html

TCP socket stick package