Summary of TCP/UDP Common Problems

1. UDP Packet Loss

The UDP Intranet transmission that has been plagued for a few days has finally been completed. The key to solving this problem is the call of setsockopt, which sets the receiving buffer.

The problem is that the host sends UDP Packets:

The package size of the application layer is 1452byte. In this way, the packet splitting is based on the 1500-byte Ethernet MTU (of course, the Internet is not necessarily an Ethernet network, and the route MTU may be smaller ), because there are 8 byte UDP headers and 20 byte IP headers at the network and transmission layers, the Ethernet frame size is 1452 + 8 + 20 = 1480 bytes.

The host (Linux) now receives 11 channels of video data, and the volume of data sent is still large. However, after testing, the data can be sent out, so there is no problem with the sending end. On the client side, I use a thread to connect to the package and then process the package. This can always be handled. When the number of connections is large, that is, when the code stream increases, it cannot be received. In the beginning, I thought it was a problem on the host side. I tested the Writing File and found that the host side was completely able to handle 11 data transmission (UDP packet). The receiving end conducted a detailed test on each part, there is no efficiency problem and affects the handling of packets, and finally focus on the problem of receiving buffer, after verification, the windows program default UDP socket receiving and sending buffer is 8 KB, when the receiving buffer is increased, packet loss is immediately solved:

Int n = 512*1024; setsockopt (m_hrcvsock, sol_socket, so_rcvbuf, (const char *) & N, sizeof (n ));

It can be seen that 8 KB is sufficient, but the default receiving buffer (UDP) is insufficient for receiving large amounts of data. Manual settings are required. Otherwise, data errors may occur due to packet loss. The reason we didn't think of this at the beginning is that the original network uses TCP for video transmission (TCP receiving and sending buffering are not verified at the moment ), in the TCP status, we can transmit 16 real-time video data over the Intranet, so we think there is no bottleneck between UDP and TCP in sending and receiving. The TCP traffic will be controlled. The following is an excerpt:

Speaking of traffic control, we have to mention another important concept of TCP-window. The window indicates the maximum amount of data that can be received by the receiving host. The window size varies with the Host resources and the number of transmissions that the host currently receives. The host uses the window field for traffic control, that is, traffic control is a function of the TCP window. TCP uses traffic control to manage the data traffic that enters the buffer zone of the receiving host. If the data transmission speed of the sending host is faster than that of the receiving host, and the receiving host buffer is full and cannot process more data, the receiving host requests the sending host to reduce the data transmission speed until the receiving host can receive more data. On the contrary, if the receiving host can process more data, requests are sent to the host to speed up data transmission. This is the purpose of traffic control. It ensures that data is completely transmitted to the receiving host during transmission.

It can be seen that TCP is based on connections, so it will sacrifice a lot in the transmission process to ensure transmission, so even if the speed drops, it will ensure the orderly and correct receiving of the receiving end. However, UDP is non-connected and does not process the data after it is sent. In this way, data transmission is guaranteed to be efficient but not guaranteed, all inspection, order, and complete processing must be completed at the application layer (this reminds us of RTCP ).

 

2. Binding failed

Another setsockopt option is so_reuseaddr. When an address is bound for listening today, every connection is processed, and the UDP port sent from the address is listened, due to the need to bind multiple times, but at the beginning there was always an error of duplicate addresses. Later I found that port binding on the same address seemed to have a time interval limit, you cannot bind a repeat within this limit. As a result, you can bind a repeat multiple times ~

After verification, I encountered an incorrect address:

Use the bind api function to bind an address (an interface and a port) to a socket endpoint. You can use this function in server settings to restrict the interfaces that may be connected. You can also use this function in client settings to restrict the interfaces that should be used for outgoing connections. The most common usage of BIND is to associate the port number with the server and use the wildcard address (inaddr_any), which allows any interface to be used for the incoming connection. The common problem with BIND is to try to bind a port that is already in use. This trap may be caused by the TCP socket status time_wait because no active socket exists, but the binding port is still prohibited (BIND returns eaddrinuse. This status is retained for about 2 to 4 minutes after the socket is disabled. After the time_wait status exits, the socket is deleted so that the address can be rebound.

It may be annoying to wait for time_wait to end. In particular, if you are developing a socket server, you need to stop the server to make some changes and restart it. Fortunately, there are ways to avoid the time_wait status. You can apply the so_reuseaddr socket option to the socket so that the port can be reused immediately.

Similarly, after each UDP listener socket is used, I use closesocket to clear the socket used. After the socket is manually released, I can bind it again without setting setsockopt. It can be seen from this that the originally created socket is local, but its release seems to be different from the normal c variable release method. Therefore, when the function is called next time, A duplicate address error occurs, while manual clearing is safe. This error occurs on both Linux and Windows platforms, but it seems that after Windows calls setsockopt again, the socket receives an exception and occasionally cannot receive UDP packets. This is not the case in Linux.

Summary of TCP/UDP Common Problems