Design basis of custom communication protocol

The original text is reprinted from: http://www.360doc.com/content/14/0915/11/1073512_409611008.shtml

  For communication between many devices, it is often necessary to design a set of communication protocols by yourself. Of course, the communication protocols here are generally protocols based on protocols such as TCPIP protocol, that is, a set of protocols is defined on the basis of existing protocols. For example: there is a set of equipment for detecting rainfall (usually a simple embedded device) that needs to report the collected data to a central server (usually a computer with particularly good performance). A set of communication protocols is needed. To ensure that the data sent on the embedded device can be correctly understood and processed by the central server. Another example: In a bridge inspection project, a lot of bridge data, stress, cable force, temperature, etc. will be detected. These inspection devices are generally embedded devices composed of simple sensors, which need to be collected in various ways The data is reported to the central server, and the central server further judges the various states of the bridge after analysis and processing. These all involve custom communication protocols.

But how are these custom communication protocols designed? What are the design aspects?

The design of the protocol is to ensure that both parties can communicate normally. Because the upper device and the lower device are generally different devices, the processing capabilities are very different. These are issues that must be considered when designing the protocol.

  A complete protocol usually contains many commands. Each command specifies which parts of a complete command (that is, a complete data frame), generally including the following parts:

1. The composition of the data frame

The general forms are byte stream (also called binary protocol in some places) and character stream. The byte stream generally specifies the meaning of each byte, and the character stream generally specifies the meaning of the characters because they are all visible characters.

2. Data frame head and tail

The head and tail of the data frame are actually designed to parse the data, mainly to obtain a complete frame. Due to the uncertainty of the network, there is no guarantee that a complete data frame will be sent to the other party at one time. Generally choose to use rarely appearing bytes or characters as the head and tail of the data frame.

For example, I have parsed a set of protocols of MODE 04 PROTOCOL, which start with 0x03 and 0x14. Since MODE 04 PROTOCOL is a byte stream protocol, it is stipulated that the first two bytes of the command are 0x03 and 0x14. For the protocol of passing character stream, the command starts with ## . The data frame end is sometimes present, sometimes not. For example, MODE 04 PROTOCOL does not have a protocol end, because it has two bytes to indicate the length of this data frame, so there is no need to specify the data frame end. On the contrary, if the length of a command cannot be judged, it will specify how the data frame ends. If the length of the data frame is the same, there is no need to specify it, but it is rare in practice that the length of the data frame is fixed.

3. The verification part of the data frame

For byte stream protocols, the verification part of the verification data frame is generally specified. For example, MODE 04 PROTOCOL specifies that the last two bytes of the data frame are the crc verification part.

For character streams, validation fields can also be added, but since each part is a visible character, it can be omitted.

4. Escape characters

Due to the uncertainty of the content of the data frame, the characters that appear rarely may also appear in the data frame. For example: MODE 04 PROTOCOL protocol. When 0x03 and 0x14 appear in the data frame, which is the beginning part of the data frame, they must be transferred. Righteousness, otherwise it will parse the error. Cause a data frame to become two incomplete and incomprehensible data frames.

5. Command words and others

The command word is to indicate the data frame, the command that needs to be completed, for example: read the time command data frame, a part of the data frame is the read time, and the set time command data frame has a part that indicates that the data frame is used for setting In terms of time, of course there will be command content such as how much to adjust the time to.


6. Heartbeat package

As a very special data frame, the heartbeat packet is actually similar to the human heartbeat. At regular intervals, a very special data frame heartbeat packet is sent. The function is to show that the device is still working.

例如QQ的在上状态应该就是通过类似心跳包的设计来完成的。但在无线领域还有其他作用,避免已经建立的链接断开。尤其数据是通过GPRS发送时,如果长时间不发送数据,网络运营商就会回收链接,下次发送数据时,就必须重新建立链接,这对于需要永远在线的设备或者是需要随时唤醒的设备来说,显然是不行的。

对比:

字节流协议难度显然比字符流大很多,解析过程也更复杂,如果没有协议文档,几乎不能解析,因为收到的就是一串毫无意思的数字,一个字节处理错误就完全可能导致整条数据解析错误,此外字节流还需要规定大端模式和小端模式等。当然好处就是,传输同样的信息,数据量明显少很多。

字符流就简单很多,解析的过程可能就是一个正则表达式。


Guess you like

Origin blog.csdn.net/u012993936/article/details/45309123