Golang implementation of Simple TCP server 04--Sticky packet processing for servers

This is a creation in Article, where the information may have evolved or changed.

Sticky pack handling for servers

what is a sticky bag

A completed message may be sent by a TCP split into multiple packets, or it is possible to encapsulate multiple small packets into a large packet, which is the problem of TCP unpacking and packet encapsulation

causes of TCP sticky packets and unpacking

1. Application writes data with a larger byte size than the socket send buffer

2. An MSS-sized TCP segment. MSS is the abbreviation of the maximum message segment length. MSS is the maximum length of a data field in a TCP message segment. The data field plus the TCP header is equal to the entire TCP message segment. So MSS is not the maximum length of the TCP segment, but rather: Mss=tcp message segment length-tcp header length

3. Ethernet payload is larger than the MTU for IP sharding. MTU refers to the maximum packet size that can be passed on a layer of a communication protocol. If the IP layer has a packet to be transmitted, and the length of the data than the link layer MTU, then the IP layer will be fragmented, the packet is divided into dry slices, so that each piece does not exceed the MTU. Note that IP shards can occur on the original send-side host or on an intermediate router.

solution strategies for TCP sticky packets and unpacking

1. The message is fixed long. For example, 100 bytes.
2. Add a carriage return at the end of the package or special characters such as whitespace, typically such as the FTP protocol
3. Divides the message into the message header and the end of the message.
4. Other complex protocols, such as the RTMP protocol.

Reference (http://blog.csdn.net/initphp/article/details/41948919)

our way of handling

There are a variety of ways to solve sticky-bag problems, and here's how we do it:

• The sender writes the length of the message each time a message is sent to a int32 as a packet header and sent out, we call it encode
• The receiving party reads the message length information of a int32 length, and then reads the corresponding long byte data according to the length, which is called decode

In the home folder in the lab environment, create a new folder named codec underneath it to create a new file Codec.go, write our encode and Decode methods, and give encode and decode the corresponding code:

Codec.go

Package Codecimport ("Bufio" "bytes" "Encoding/binary") Func Encode (Message string) ([]byte, error) {//Read message var length int32 = Int32 (Len (message)) var pkg *bytes. Buffer = new (bytes. Buffer)//write message header err: = Binary. Write (pkg, binary. Littleendian, length) if err! = Nil {return nil, err}//write message entity err = binary. Write (pkg, binary. Littleendian, []byte (message)) if err! = Nil {return nil, err} return pkg. Bytes (), Nil}func Decode (reader *bufio. Reader) (string, error) {//Read the length of the message lengthbyte, _: = Reader. Peek (4) Lengthbuff: = bytes. Newbuffer (Lengthbyte) var length int32 err: = Binary. Read (Lengthbuff, Binary. Littleendian, &length) if err! = Nil {return "", Err} if Int32 (Reader. Buffered ()) < length+4 {return "", err}//Read message real content pack: = Make ([]byte, int (4+length)) _, err = R Eader. Read (Pack) if err! = Nil {return "", err} return String (pack[4:]), nil}

Here does not post the server and the client's call code, the students try their own ~