The first question to be discussed is probably the problem of sticking packets. This is a problem of TCP personality, which does not exist during UDP communication. First, let's take a look at what is a sticky package:
The client establishes a persistent connection with the server (Open-Write/Read -...... -Write/Read-Close ). That is, after the connection is established, read/write operations are performed multiple times before closing. In addition, it is not a file transfer, but a Data Structure Transfer (the results will not be affected when a file transfer stick package or no stick package occurs, it is all byte streams written to the local file in order ). Here is an example:
Two data structures: {give me something} {don't give me anything} indicates that the stick packet is accepted by {give me something don't give me anything}, which makes the server dumb, I have never seen such a strange data structure, and I don't know how to handle it. |
The above example is forwarded to the Internet
Let's take a look at the reason for the occurrence of the stick packet, which is actually why TCP occurs, but UDP does not: TCP is a connection-oriented stream-less transmission mode. After the transmission channel is established, the data stream is streamed like water. There is no data boundary concept, and the package is as big as possible. Therefore, multiple packages are finally pasted into a large package. Of course, this is the cause of TCP, and there is a buffer mechanism problem. By default, the sending end needs to wait until the sending is full, therefore, the use of push to brush the buffer can also reduce the phenomenon of sticking packets. In addition, the buffer processing is not timely, and a packet is not processed immediately.
The solution is as follows:
- You can use programming settings to avoid packet sticking caused by the sender. TCP provides an operation command push to force data to be transmitted immediately. After the TCP software receives the operation command, immediately send the data segment, without waiting for the sending buffer to be full. This method disables optimization algorithms, reduces network transmission efficiency, and affects application performance. In addition, it cannot be guaranteed that no package is attached at 100%.
- 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 to avoid sticking packets. This idea has high requirements on the program algorithm structure of the receiver, and the reliability is not high, because concurrency and other phenomena in network communication exist in large numbers, it is hard to really accept the buffer even if processing is done without sticking packets.
- Controlled by the receiver, a packet of data is manually controlled by the structure field and received multiple times, and then merged to avoid sticking to the packet. The problem with this idea is even greater, and the application efficiency is reduced too much. In addition, I really don't think this really doesn't happen to stick the package. Although the package gets smaller, the existence of concurrency does not ensure that the receiver has enough clearance to process the package.
- Predefined data structure, single thread. The header flag is added before the byte stream. The header contains the data length of the packet, which can be read by byte during reading. This effectively controls the problem of sticking packets. The problem of residual packets can be avoided without chain reaction. The appearance of a bad package does not affect the normal reading of the next package. For example, {# Length ## DataStram }. The advantage of this solution is that it can ensure 100% accuracy of communication. The disadvantage is that it affects program performance, because reading packets by byte will definitely affect program efficiency.
- Improvement: pre-defined data structure, single thread. But not by byte. View the header flag, read the package length, and view the package length in the buffer zone. If the two are equal, read the package directly. If the number of readable bytes in the buffer is greater than the length of the package described by the flag, the data is read according to the length of the package described by the flag. If the number of graduated bytes in the buffer is less than the length of the package described by the flag, the thread goes to sleep and waits for the next packet to arrive.
- Predefined data structure, multi-thread. Both the server and client work in multiple threads. The client has three main threads: The sending thread, the reading thread, and the parsing thread. The server has four main threads: Listening to the main thread, receiving, reading, and parsing. According to the fifth idea, after obtaining the data packet, the parsing thread directly throws it to the parsing thread for data parsing and callback of the final result. Here, the fifth approach is a multi-thread, which can greatly improve the program performance.
Predefined data structure:
