TCP is a stream protocol. A stream is a string of data without boundaries. You can think of the water in a river, it is a piece, there is no dividing line. TCP layer does not understand the specific meaning of the upper business data, it can package according to the actual situation of TCP buffer, so that in our business, a complete package may be TCP split into multiple packages to send, it is also possible to multiple small bag packaging into a large packets to send, this is called TCP package and unpacking.
Case study:
When the buffer of the sending end is too small, the ABC packet is unpacked into AB and C, and the split C and DEF packet are sent to the receiving end.
Unpacking scenario:
(1) The data to be sent is larger than the remaining size of the buffer;
(2) If the data to be sent is larger than MSS, TCP will split it before transmission;
Sticky package scenario:
(1) To send less than the buffer remaining size;
(2) The application layer of the receiving end has no time to read the data of the buffer;
How does Netty use Frameecoder to solve the problem?
In Netty’s codec module, the common transport protocol is supported, and in FrameDecoder, a common solution for sticky and unpack is provided. The application layer protocol parsing class can inherit it without worrying about sticky and unpack.
HttpMessageDecoder fixed, length FixedLengthFrameDecoder, LineBaseFrameDecoder, etc. While FrameDecoder inherited from SimpleChannelUpstreamHandler, isn’t it a bit familiar with? Yes, this is in the interpretation of netty3.9 data processing process (a) of the processing executor, did not see the students can click into see.
Cut through the fog:
We have sorted out the context clearly. Unpacking and sticking packages is a part of the data processing process mentioned above. Then why is FrameDecoder so magical that it can deal with sticking packages universally? When the goods are out of stock, the packers pack the goods at the workbench until they are out of stock and then send them to the picker for further packing. It can be understood as a packing workbench, waiting for the packaging, but pay attention to the goods are still on the platform, can be packed to continue to pack.
Let’s have a look at FrameDecoder.
AppendToCumulation inserts the received data into the Cumulation which is the workbench in the packaging scenario, otherwise callDecode is called to loop through the application packets. And call updateCumulation to correct the cumulation data.
When cumulation is readable, old read Pointers are recorded for comparison and the actual protocol implementer is called to parse out the application layer packets.
1. If the data packet is empty and the read pointer does not move, it indicates that the data packet at the application layer is incomplete and the waiting data is jumped.
2, if the packet is empty but the read pointer moves, discard some data may be reading, continue to call parsing;
3. If a packet exists and the read pointer does not move, an exception is thrown.
4. If the packet is not empty and the read pointer moves, parsing will obviously continue.
Like readers can pay attention to the small stack on the road, timely access to the latest technical articles, focus on source code analysis, technical business thinking.
