Loss inspection methods
- Number to each UDP packet, the received packet is the receiver and sender comparison. For packets on the UDP protocol layer, e.g. RTP packet, the RTP packet can be read out from the packet sequence number is determined.
- Ethereal. Sending end and receiving end, respectively capture. Under linux you can use tcpdump, wireshark use under windows.
- Under linux, you can use the watch netstat -su see packet loss statistics. Mainly to see RcvbufErrors and SndbufErrors. If the number two statistical items are constantly increased, indicating that the card has a loss.
The sender loss
Send the package is too large
64K packets sent over the General Assembly led to the UDP protocol sendto returns an error.
Packet transmission than the MTU, UDP packet loss easily at the receiving end, the receiving end can view the statistics of the card. May consider cutting package MTU assigned to it before sending.
Contracting too fast
Contracting too fast, you may have two questions: 1. receiving the receiving end too late to cause the receiving end packet loss. 2. Send the card processing end, however. This time sendto does not return an error, but with netstat view will find SndbufErrors continue to rise, there may be too small to cause the output queue card. Consider using the ifconfig command txqueuelen set larger.
UDP packet traffic too
When the amount of data that will lead to the same port to send the card too much loss, this time you can see with netstat will find SndbufErrors rise. sendto returns -1. This increase can be considered when / proc / sys / net / core values / wmem_max of.
This is especially true when transmitting simultaneously cause a plurality of audio and video data to the client. I have encountered such a situation. When a port to send video streams to 8 client, NIC flow about 400M / s, sendto returns -1, errno 11. program also calls setsockopt set in the transmit buffer is 60M, but still dropping. Later, the system parameters / proc / sys / net / core / wmem_max set to 60M only solve the problem.
Receiving-end packet loss
Receive buffer is too small
Packet receive buffer size is smaller than the sending client or the receiving client recvfrom too slow, cause the receiver to discard the data buffer is full. The former problem, consider increasing the receive buffer. The latter problem can be considered separate service reception operation and processing operations of different processing threads.
Author: Altman little monster Kuangou
link: https: //www.jianshu.com/p/7f4700a5e970
Source: Jane books
are copyrighted by the author. Commercial reprint please contact the author authorized, non-commercial reprint please indicate the source.