How to solve the TCP packet sticking and unpacking problem when using Netty communication? The answer is so simple

[[311931]]

This article will explain the following steps, I hope you will benefit from it:

1. What is TCP packet sticking and unpacking? 2. Reproduction of the packet sticking problem in Netty 3. Solution to the packet sticking problem in Netty

OK, now that you have this basic idea in mind, you can start today's article. All articles in this series will provide complete code and actually run it on the computer to ensure that it is correct.

1. What is TCP unpacking and sticking?

When we use the TCP protocol to transmit data, if the data block is large, we will consider splitting it. A large data packet is cut into small data packets and sent. At this time, we will encounter the problem of unpacking and sticking packets.

For example, here the client sends two data packets D1 and D2 to the server. During transmission, the following problems may occur:

I believe you can basically understand it from the picture above. However, we still need to explain it a little bit here:

Case 1: D1 and D2 are sent normally, one full packet each time.

Case 2: D1 is a relatively large packet, while D2 is relatively small. A portion of D1 is sent the first time, and the rest of D1 and the entire D2 packet are sent the second time. This is called unpacking.

Case 2: Both D1 and D2 packets are relatively small, and two whole packets are sent at a time, which is called sticky packets.

Case 4: D1 is a relatively small packet, while D2 is relatively large. The entire D1 packet and part of D2 are sent the first time, and the rest of D2 is sent the second time. This is called unpacking.

Case 5: Both D1 and D2 packets are relatively large, so they are developed separately.

Why does this problem occur? To explain it clearly, we must consider the relevant knowledge of computer networks. When TCP receives data, it has a sliding window to control the size of the received data. You can think of this sliding window as the size of a buffer. When the buffer is full, the data will be sent. The size of the data packet is not fixed, sometimes larger than the buffer, sometimes smaller. At this time, the above phenomenon will occur.

Below we use code to reproduce this phenomenon.

2. Problem Reproduction

1. Prerequisites

We developed it based on Springboot, so as in the previous section, first create a Springboot web project and add the following dependencies:

If you don't use Maven, download the relevant jar package and import it directly into the IDE.

2. Server code development

Step 1: Create a server class

This server class, mentioned in the previous article, is a template class that can be used directly.

In the above code, we also mainly focus on the implementation of ServerUAVHandler.

Step 2: Handler implementation

In this class, use the channelRead method to read the information sent by the client.

(1) First, a counter is defined to count how many messages the client has sent.

(2) Inside channelRead, msg is first converted to ByteBuf.

(3) Convert the data of buf into bytes

(4) Convert the byte data of buf into String type and then output it.

(5) Use the writeAndFlush method of ctx to send an A to the other party every time data is received from a client. Don't forget the newline character.

In the above code, the most important thing is that the server should reply to each message from the client. That is to say, the number of messages from the client and the server should be the same.

3. Client code development

Step 1: Create a client class

The logic of the same code has been mentioned in the previous article, and we are still most concerned about the event processing class Handler.

Step 2: Handler implementation

This client's Handler seems a bit complicated, with two methods in total, channelActive and channelRead.

(1) In channelActive, a for loop is used to send 100 "I love you" messages to the server. A newline character is added at the end of each message.

(2) ChannelRead receives the message returned by the server.

Logically speaking, if the client sends 100 pieces of data to the server, the server will also return 100 pieces of data. Let's verify this.

The output here is the information of the server. From the above output, you can find that the "I love you" messages on the client are all stuck together. There were originally 100 messages, but now there are only 17 messages. This is the phenomenon of sticking packets.

How to solve it? Let’s take a look below.

3. Solution to the sticky package problem

The solution is very simple, that is, each time a data packet is sent, an identifier is added, and when reading, a complete data packet is represented only when this identifier is read. In the above, we added line.separator, which is the line break character "\n".

1. Changes to the server class on the server side.

2. Server Handler class changes

3. Client changes

4. Client Handler Changes

The changes to the client and server are the same, but I still posted it here. Now let's run it again.

Isn't it amazing? Let's analyze what we have modified.

It seems that we only added two classes to the server and client classes, one is LineBasedFrameDecoder and the other is StringDecoder, and the others are directly deleted. What are the functions of these two classes?

(1) The function of LineBasedFrameDecoder is to read data until it contains a line break character "\n" or "\r\n". If it does, it means it is time to end the data. Therefore, the data packet of this line is obtained.

(2) StringDecoder is used to decode the line of data packets read by LineBasedFrameDecoder. It converts the object into a string.

OK, it seems that the two of them work together, and the work is really not tiring. Now we can finally solve the problem of sticky packets, but a new problem also arises, that is, what if our identifier is not a line break character "\n" or "\r\n"? Fortunately, Netty also provides us with several other decoders, called DelimiterBasedFrameDecoder and FixedLengthFrameDecoder. The former can automatically complete the message ending with a delimiter, and the latter can automatically complete the decoding of fixed-length messages. Both can solve the problem of sticky packets and unpacking.