Socket/tcp stick package, multi-package and less package, packet disconnection

Why does TCP stick packets?

A few days ago, the TCP communication of Mina was debugged. The first Protocol packet was resolved normally, and the second packet was incomplete. Why is it like this? We still have this problem when we use a communication framework like Mina? Let's analyze the problem first.
When talking about communication, we are faced with the choice of both communication protocols and data protocols. For the communication protocol, we can select TCP/UDP:

• TCP (Transport Control Protocol) is connection-oriented, stream-oriented, and provides high-reliability services. Both the sending and receiving ends (the client and the server) have a pair of sockets. Therefore, the sending end sends multiple packets sent to the receiving end more effectively to the other end, the Nagle algorithm is used to merge data with a small interval and a small amount of data into a large data block and then package the data. In this way, it is difficult for the receiver to distinguish, and a scientific package splitting mechanism must be provided.That is, stream-oriented communication has no message protection boundaries.

• User Data Protocol (UDP) is connectionless and message-oriented, providing efficient services. The merge optimization algorithm of blocks is not used. Because UDP supports one-to-many mode, the skbuff (socket buffer) of the receiving end uses a chained structure to record each incoming UDP packet, the message header (message source address, port, and other information) is available in each UDP packet. In this way, it is easy for the receiver to differentiate and process the message.That is, message-oriented communication has message protection boundaries.

Because TCP has no message protection boundary, message boundary issues need to be processed at the message receiver. That is why we used UDP before. However, when TCP is used, there are fewer packets.

The principle of the stick packet analysis is described above, but some people may encounter multiple packets/fewer packets when using TCP communication, but some may not. Then let's analyze the situation of less and more packages.

• Normally, each message is sent in a timely manner, and the receiving is not busy. The message is processed in time. Like UDP.
  
• Send a sticky package. Data with a small interval and a small amount of data is merged into a large data block and then packed. this situation is the same as when the client is busy and the receiving cache area has a backlog. The user processes multiple data packets from the receiving cache at a time.
  
• The user buffer is larger than the total size of data packets in the receiving cache. In this case, you need to consider processing multiple data packets at a time, but each data packet is complete.
  
• The user cache area is an integer multiple of the data packet size. In this case, you need to consider processing multiple data packets at a time, but each data packet is complete.
  
• The user cache is not an integer multiple of the data packet size. In this case, you need to consider processing multiple data packets at a time, and also consider the incomplete data packets.
  

Our situation is the last, where data packets are incomplete. So much too long. To sum up, there will be two cases of sticking to the package.

1. The sender needs to wait until the buffer is full to send out, resulting in sticking packets.
2. The receiver does not receive packets in the buffer zone in time, resulting in receiving multiple packets.

How can we deal with selling a customs first? Not all sticky packages need to be processed. Let's first list it, so as not to handle the sticking packet during the encoding process because we know the sticking packet.

1. Continuous Data Streams do not need to be processed. For example, an online video is a continuous stream without subcontracting.
2. When a connection is established every time a message is sent.
3. The sender uses the push operation command that forces the immediate transmission of data over TCP.
4. UDP, as described earlier. Here, we emphasize that UDP does not need to be processed, so we should not forget it.

If you use socket programming, I will not talk much about it. refer to the following materials:
• Grizzly: Sample of chapter 2 of http://grizzly.java.net/nonav/docs/docbkx2.0/html/coreframework-samples.html User Guide: parse received messages.
• Xsocket: http://xsocket.sourceforge.net/core/tutorial/V2/TutorialCore.htm section 18th.
• Netty: http://netty.io/docs/3.2.6.Final/api/org/jboss/netty/handler/codec/frame/FrameDecoder.html framedecoder API documentation. Netty abstracts a "message decoder" class to process these.
• Mina 2: http://mina.apache.org/chapter-11-codec-filter.html
• Mina 2: If the en text is not good, see http://freemart.iteye.com/blog/842554. It has a small defect when determining whether the package is complete. It does not use the prefixeddataavailable of iobuffer. However, it is better to write comments.

The Code on the official website is also displayed here.

Public class imageresponsedecoder extends cumulativeprotocoldecoder {

/**
* Explanation of return values:
* 1. False: continue to receive the next batch of data. There are two scenarios, for example, when the buffer data is just a complete message or a message is not enough. If one message is not enough, the next batch of data and remaining messages will be merged.
* 2. True: when there is more than one message in the buffer zone, the remaining messages will be pushed to dodecode.
*/

Protected Boolean dodecode (iosession session, iobuffer in, protocoldecoderoutput out) throws
Exception {
// When sending data, the first four bytes record the message length. This method reads four bytes and compares them with the stream length. Before return, reset the stream.
If (in. prefixeddataavailable (4 )){
Int length = in. getint ();
Byte [] bytes =
Newbyte [length];
In. Get (bytes );
Bytearrayinputstream BAIS = new bytearrayinputstream (bytes );
Bufferedimage image = ImageIO. Read (BAIS );
Out. Write (image );
Return true; // if the package is attached after the content is read, the system automatically processes the package.
} Else {
Returnfalse; // continue receiving data to be complete
}
}
}

• Next, let's summarize the processing process: when data is sent, the packet starts to write the message length n. When the received cache data m, the processing process is as follows:
• 1) if n <m, it indicates that the data stream contains multiple packets of data. n Bytes are intercepted from its header and saved to the temporary buffer. The rest of the data continues to be processed cyclically until the end of the process. Or n> m
• 2) if n = m, it indicates that the data stream content is exactly a complete structured data and can be directly stored in the temporary buffer.
• 3) if n> m, it indicates that the content of the data stream is not enough to form a complete structure data, and it must be retained for merging with the next package of data before processing.

Reference http://blog.csdn.net/binghuazh/article/details/4222516
Http://www.cnblogs.com/alon/archive/2009/04/16/1437600.html
Http://hi.baidu.com/chongerfeia/blog/item/b1e572f631dd7e28bd310965.htmlhttp://freemart.iteye.com/blog/836654http://blianchen.blog.163.com/blog/static/1310562992010101891522100/http://mina.apache.org/chapter-11-codec-filter.html