Poor application-layer communication protocol design

Poor application-layer communication protocol design

Last year and this year respectively participated in two companies' projects, both of which involved communication programming, Ethernet communication, or serial communication. Communication protocols are required for communications. I personally think that protocol design is a very serious task. I need to understand business requirements and master basic protocol design knowledge. But from the two projects, the design of the Protocol can be said to be terrible. Below we will criticize the poor design.

1. Poor design: the message format is "header + Data + package end"

Different from UDP, TCP communication is stream communication and has no message boundaries. Therefore, the application layer needs to define and separate packets. In Project 1, the packet header is {two bytes, and the packet end is} two bytes, for example, {t = 123 }}. The format is:

Start boundary + Message 1 + end boundary + start boundary + Message 2 + end boundary + start boundary + Message 3 + end boundary + ....

Because TCP is a secure transport layer protocol, no verification is required at the application layer unless necessary. The message boundary only needs one identifier. The basic format is:

Message 1 + boundary + Message 2 + boundary + Message 3 + boundary +...

No matter how much network bandwidth is saved or how the message parsing code is simplified, the first design is very stupid!

Coincidentally, this design format is also used for the serial-Port-based communication application layer protocol in Project 2.

When asked why its designers were so designed, they said they had always been so designed, and they did not know the reason for the design. They also said that they had never had any problems, I really want to beat him.

2. Bad design 2: Describe the message structure with struct code instead of Text

In Project 2, there is no protocol description text at all. There is only one header file containing the struct definition for reference by the Protocol users.

Communication involves multiple machines, so communication protocols must be cross-platform. And we know that

struct A{char x;int y;};

Different compilers, platforms, and compilation options have different binary la S. Moreover, Protocol users may not understand C-language code. Even more funny, the header file does not force the single-byte alignment of the struct.

When asked about the design ideas of the Protocol designer, we said that our company has always been like this, and it has never been a problem. There is no problem because all the machines using this Protocol are of the same CPU model, the same development environment, and the same operating system.

3 bad design 3: Transfer binary floating point numbers

There is not only one binary format for floating-point numbers. different platforms store them in different ways. This is more serious than the big-end small-end integer difference. Therefore, it is extremely insecure to transmit binary floating points across platforms. In Project 2, binary floating point numbers are widely used in messages.

There are two solutions to transmit floating point numbers:

Regionalization. That is, to transmit the string describing the floating point number, we know that the string is fully cross-platform, especially in the case of a globally unified character encoding like UTF-8.

Convert to an integer. For example, 1.2 can be replaced by an integer of 12, but the Unit must be set to 0.1.

4. Poor Design 3: a large number of standby Fields

The message structure of Project 2 is similar to the following:

struct A{char name[16];int age;int spare1;short spare2;short spare3;int spare4;};

A large number of standby fields are filled with struct. A small number of standby fields can be understood, and such a large amount of backup power is really far-reaching. I really don't know if the protocol user will vomit when they see spare. If you really need so many backup fields, you can completely redefine a message structure.

5. Poor design 4: handshake and Verification

Handshaking and verification are the basic methods to ensure secure and complete communication, but their implementation is not simple. You can see the TCP implementation code and you need to consider various exceptions. In Project 2, a handshake protocol is defined between the serial device and the host. After the device is started, the device keeps sending AA to the host. After receiving AA, the host sends AA to the device. After receiving AA, the device sends 55 to the host. After receiving AA, the host sends 55 to the device. There are many problems with this simple handshake:

There is no need to shake hands. Generally, serial devices do not need to know the working status of the host. If the host wants to know the status of the device, send an inquiry message.

If the program exits after the host sends AA, the serial port device will never be able to wait for 55 from the host.

If the host is turned off midway through, it may receive AA from the serial port device during operation. AA is actually only a byte of the message, rather than a handshake signal.

As long as you think about it, there are still many similar situations to deal. In addition, the above situation does occur during actual use, resulting in the need to restart the serial device or host.

In Project 2, The UDP-based application layer protocol designed for verification. In fact, this is understandable, such as the famous tftp protocol. It's just that the designer is not careful, and various problems occur frequently. The final result is that these verification fields are not actually used at all, wasting network bandwidth. It should be noted that the designer of this Agreement is still a large company in China, of course, it is a state-owned enterprise, you know