Solutions to UDP packet loss and disorder

Recently, I was working on a project. Before that, I had a verification program.
It was found that the client sent 1000 1024 bytes of packets consecutively, and the server experienced packet loss.
The reason is that the server has not completely processed the data, and the client has sent and disabled the data.

I used sleep (10) to solve this problem temporarily, but this is not a fundamental solution. If the data volume is large and the network condition is not good, it may still be lost.

Try blocking mode...
Select... it seems that I have encountered this problem at the beginning... but I don't have this problem after I change to blocking mode...

 

Adopt the Back-to-package mechanism. Each package must receive the Back-to-package and then send another

 

UDPPacket Loss is normal because it is insecure.

I don't think the reason for packet loss is "the server has not completely processed the data, the client has already sent the data and disabled it", but the socket receiving cache on the server is full (UDPThere is no traffic control, so the sending speed is faster than the receiving speed, which is easy to happen), then the system will discard the packets received later. You can use setsockopt () to increase the receiving cache (so_rcvbuf) to see if the problem can be solved.

The server uses multi-thread pthread for Packet Handling

UDPThere is no connection. message-oriented data transmission protocol. Compared with TCP, there are two fatal disadvantages: data packet loss and data packet loss.Unordered.
To achieve reliable file transmission, data packet loss and out-of-order must be specially processed at the upper layer, and the re-transmission and timeout mechanisms must be in place.
Common reliable transmission algorithms include the analog TCP protocol and the re-Send request (ARQ) Protocol. They can also be divided into the continuous ARQ protocol, the re-transmission ARQ protocol, and the sliding window protocol.

 

If it is only a small-scale program, you can also implement Packet Loss Processing by yourself. Basically, the principle is to block the file and add a unique ID value to the header of each data packet, when the received packet header ID is not the expected ID, it is determined that packet loss occurs. The packet loss ID is sent back to the server. When the server receives a packet loss response, it resends the lost packet.

 

It is relatively simple to simulate the TCP protocol. The three handshakes are very helpful for Packet Loss Processing.

UDPIt is not safe. Without any control, not only will the packet be lost, but the order of packets received and sent may be different. This must be controlled in your own program.
After receiving the package, you must return a response. If the sender does not receive the response within a certain period of time, resend the response.

UDPPacket Loss exists. The current solution now considers both sides to increase handshakes.
In this wayUDPThe TCP implementation method is added to the Protocol.
Pthread processing is used in the program. The packet loss rate is large and small, which is unstable and reliable.

 

I think there may be two reasons: one is that the client sends too fast, the network is not good, or the server receives too fast, packet loss will occur.
The second reason is that the server still needs some processing after receiving the packet, but the packet sent by the client is not received during this time, resulting in packet loss. 

Solution,

First, the client can reduce the sending speed, wait for the packet to return, or add some latency.
Second, the server opens a separate thread to receiveUDPData is stored in a buffer, and other threads process the received data to minimize packet loss caused by data processing latency.

 

There are two ways to solve the problem:
Method 1: redesign the Protocol to increase the receiving confirmation timeout and resend. (Recommended)
Method 2: separate communication and processing at the receiver, and add an application buffer; if necessary, add the system buffer for receiving socket. (This method cannot solve the problem fundamentally, but can only improve)

Network Packet Loss is normal again.
UseUDPTo accept packet loss. Otherwise, use TCP.
If you must useUDPAnd packet loss is unacceptable, so you have to confirm and re-transmit it by yourself. To put it bluntly, TCP is implemented by yourself (of course, partial and limited simple implementations ).

UDPYes, but there is no connection. The user is implementingUDPDuring programming, you must develop upper-layer protocols, including stream control, simple timeout and retransmission mechanisms. If you do not want to obtain real-time data, TCP may be more suitable for you!

Huangcanbao was published on Tuesday, September 22,200 9 7:33:22 report

I received a telephone interview today. Fortunately, my solution is the same as that of your friend. 1: defines the protocol for sending data to the user, and the serial number size data. 2: Both parties must verify the transfer process and check whether the correct data is received. It is managed based on the size of the transmitted bytes.

From http://blog.csdn.net/yylklshmyt20090217/archive/2009/06/17/4275937.aspx

We recommend that you perform a packet subcontract and group packet operation for large packets. to reduce the packet loss rate (packet loss and re-transmission are also a small amount of consumption), set the size of a single packet to within 1500 bytes, and set the maximum bandwidth of 2048 packets per second based on 24 Mbit/s, this pressure is quite small.

Packet Loss is normal. The higher the packet loss rate, the higher the possibility of packet loss. It is not necessarily related to the speed of the network card. You need to design the response and resend mechanism on your own. As for how many data packets are most suitable, you must test them in the actual running environment. During the program running, you can calculate the packet loss rate and dynamically adjust the packet size to adapt to the running environment.

In addition, it is the memory pool, which is the simplest. If you rereceive the new char [1024] every time, the thread receiving speed will come now.
Remember, the receiving thread should not do anything. I am afraid to only query a map. During the tens of thousands of packets per second, tens of thousands of map queries are performed per second,

In addition, packet loss may be sent by the sender, which has been lost. You need to consider sending and processing. Sending and processing are not well written.
The process has no chance to buffer the network card, so it is possible to lose it.
Intermediate router Link (this cannot be controlled. You can only see how this link performs)