CN116137631A

CN116137631A - Lightweight Internet of things communication protocol based on publish-subscribe

Info

Publication number: CN116137631A
Application number: CN202111359018.7A
Authority: CN
Inventors: 胡龙; 周金明; 谢霄鹏
Original assignee: Nanjing Xingzheyi Intelligent Transportation Technology Co ltd
Current assignee: Nanjing Xingzheyi Intelligent Transportation Technology Co ltd
Priority date: 2021-11-17
Filing date: 2021-11-17
Publication date: 2023-05-19

Abstract

The invention discloses a lightweight Internet of things communication protocol based on Publish-Subscribe, which is constructed on a TCP/IP protocol, and in the communication process, the protocol has three identities, namely a publisher, a proxy Broker and a subscriber. Wherein the publisher and subscriber of the message are clients and the Broker is a server. The message communication process comprises the following steps: the clients A and B establish connection with a Broker, the Broker returns a confirmation message to indicate that the connection establishment is successful, the client A issues a message M1 of the theme 1, the client B subscribes to the theme 1, the Broker sends the M1 to the client B, and the client B receives the message M1; the effects of high transmission efficiency and high speed are realized.

Description

Lightweight Internet of things communication protocol based on publish-subscribe

Technical Field

The invention relates to the field of Internet of things and communication research, in particular to a lightweight Internet of things communication protocol based on publish-subscribe.

Background

The internet of things is an important component of a new generation of information technology, and aims to connect sensors, controllers, robots, objects and the like together in a new mode by utilizing communication technologies such as local networks or the Internet to form networks of people, objects and objects, so that informatization, remote management control and intelligence are realized. With the vigorous development of the internet of things technology, the application range of the internet of things is larger and larger, and various internet of things terminal devices are required to be accessed into related systems of the internet of things. With the development of smart home, people can remotely operate the intelligent air conditioner by using a mobile phone, and even control the switch of an intelligent bulb, the switch of an intelligent television and the like by voice, so that the communication between the devices of the Internet of things is particularly critical.

In the process of realizing the invention, the inventor finds that a certain problem still exists in a plurality of internet of things equipment at present: 1. the transmission data volume is large: many internet of things equipment communication protocols adopt XMPP, MPP is based on heavy XML, and the message volume is large and interaction is complicated. 2. Poor compatibility with terminal equipment with low hardware performance: most of the existing internet of things communication protocols are not friendly to low-end embedded equipment, and are high in storage space occupation and large in integration difficulty. 3. Transmission is unstable and delay is high on a low bandwidth, poorly conditioned network.

Disclosure of Invention

In order to overcome the defects of the prior art, the invention provides a lightweight Internet of things communication protocol for publishing/subscribing information based on a client-server, which is constructed on a TCP/IP protocol, and in the communication process, the protocol has three identities, namely a publisher, a proxy Broker and a subscriber. Wherein the publisher and subscriber of the message are clients and the Broker is a server. The message communication process comprises the following steps: the clients A and B establish connection with a Broker, the Broker returns a confirmation message to indicate that the connection establishment is successful, the client A issues a message M1 of the theme 1, the client B subscribes to the theme 1, the Broker sends the M1 to the client B, and the client B receives the message M1; the effects of high transmission efficiency and high speed are realized. The technical proposal is as follows:

the invention provides a lightweight Internet of things communication protocol based on publish-subscribe, which comprises the following specific steps:

the message model of the communication protocol is as follows: the subscriber sends a subscription type message to the proxy server, the publisher sends a published message type message to the proxy server, and the proxy server pushes the published message to the subscriber.

The message structure of the protocol is as follows: the protocol frame consists of a fixed header, a variable header and a message body.

The fixed message header structure is as follows: the first 4 bits of the first byte of the fixed message header are used for specifying the protocol message type, and the last 4 bits are used for specifying the protocol message identification bit; starting from the second byte is the remaining length.

The number range of the protocol message types is 1 to 14, and the number of the protocol message types represents 14 message types:

1: connection, initiate a connection,

2: the connection acknowledgement,

3: PUBLISH, PUBLISH message,

4: the physical channel, qoS1 message acknowledgement,

5: the physical, qoS2 message receipt,

6: the physical, qoS2 message release,

7: the PUBCOMP, qoS2 message complete,

8: SUBSCRIBE, SUBSCRIBE request,

9: a SUBACK, a subscription confirmation,

10: UNSUBSCRIBE,

11: unsubscribe, unsubscribe acknowledgement 0,

12: PINGREQ, heartbeat request,

13: PINGRESP, heartbeat response,

14: DISCONNECT is disconnected.

The protocol message identification bit consists of three identification bits: DUP flag, qoS level, RETAIN,

wherein the DUP flag: a value of 1 indicates that the current message is not the first message, i.e., the message is repeatedly sent.

QoS level: the service quality level of the message is identified, and the QoS level has three values of 0,1 and 2, which represent the service quality levels of three message: qoS level is 0, which means: the message can only reach the server once or not at all; qoS level of 1 indicates: at least once, ensuring that the message arrives, but the message may be repeatedly sent; qoS level of 2 indicates: only once, ensuring that the message arrives once.

RETAIN: a value of 1 indicates that the transmitted message is to be persisted on a reader.

The residual length is the sum of the length of the variable message header and the length of the message body. The residual length uses variable length coding, a minimum of one byte and a maximum of 4 bytes, each byte can code 128 numerical values and +1 continuation bits, the highest bit is the continuation bit to indicate whether more bytes exist, and the 7 th bit indicates 128 numerical values;

the variable header includes four fields: protocol Name, protocol version Protocol NVersion, connection Flags Connect Flags, keep Alive.

The connection flag is used to specify a connection behavior between the client and the server. The connection Flag is represented by one byte, and bit 0, bit 5, bit 6, and bit 7 are reserved bits, bit 1 is Clean Session, bit 2 is Will Flag, bit 3 is Will QoS, and bit 4 is Will return.

The Clean Session: and the session state processing mode, namely 0, reserving the session, wherein after the current connection is disconnected, the client and the server must store session information. 1 indicates that the session is cleared, no offline messages are reserved, and a reconnection will establish a new session.

The Will Falg: the legacy flag, 1, indicates that if a connection request is accepted, a legacy message must be stored by the server and associated with the network connection, and when the network connection is broken, the server must issue the legacy message unless the server deletes the legacy message when receiving the DISCONNECT message.

The Will QoS: the quality of service class identification of the legacy message must also be set to 0 if the legacy identification is set to 0, and the will QoS value may be equal to 0,1,2 if the legacy identification is set to 2.

The Will return: the remains the identification bit, if remains the identification to set to 0, remains the identification to set to 0 too, if remains the identification to set to 1 when: if the remains are 0, the server must issue the remains as non-reserved messages, and if the remains are 1, the server must issue the remains as reserved messages.

The Keep-Alive connection is a maximum time interval in seconds, and is represented by two bytes, and is mainly used for keeping the long connection established by the client month server.

Preferably, the numerical range corresponding to the number of bytes of the remaining length is specifically: when the remaining length is one byte, the minimum value is 0 and the maximum value is 127, the minimum value is 128 and the maximum value is 16383 when the remaining length is two bytes, the minimum value is 16384 and the maximum value is 2097151 when the remaining length is three bytes, and the minimum value is 2097152 and the maximum value is 268435455 when the remaining length is four bytes, namely the maximum value can represent 256M.

Preferably, the protocol name of the variable message header is a character string of UTF-8 code of the communication protocol name used by the server, the protocol name is specifically formulated by the server, and if the server detects that the protocol name in the message requested by the client is inconsistent with the formulation of the server, the server needs to disconnect from the client.

Preferably, the protocol version of the variable message header is a version number of a server communication protocol, and if the protocol version of the client is different from the server, the server needs to disconnect the client.

Preferably, the service end maintains the strategy of connection: the server judges whether to disconnect the inactive client through Keep Alive. If Keep Alive is non-zero and the server does not receive the control message from the client within one and five times of the Keep Alive time, it must disconnect the network connection from the client and consider the network connection to be disconnected.

Preferably, the policy that the client keeps connected: the client is responsible for ensuring that the time interval for control message transmission does not exceed the value for maintaining the connection. If no other control messages can be sent, the client must send a PINGREQ message. Regardless of the value of the connection maintained, the client can send a PINGREQ message at any time and use the PINGRESP message to determine the network and server activity status. After the client sends the PINGREQ message, if the PINGRESP message is not received within a reasonable time, the network connection to the server should be closed.

Preferably, the specific steps of the process of establishing connection and maintaining connection between the client and the server in the internet of things communication protocol are as follows:

(1) The client establishes TCP long connection with the server, and the client sends a CONNECT type message to the server to start establishing connection.

(2) And the server returns the CONNACK type message to the client after receiving the CONNECT message of the client, and confirms the establishment of the connection. And the client side receives the CONNACK message of the server side and then indicates that the connection between the client side and the server side is successfully established.

(3) The client side sends PINGREQ type message information to the server side at regular time, and waits for the PINGRESP type message information responded by the server side.

(4) If the client side does not receive the PINGRESP message responded by the server side after overtime, the step (5) is carried out, and if the PINGRESP message responded by the server side is received, the step (7) is carried out.

(5) The client sends a DISCONNECT type message to the server.

(6) The client actively disconnects the long TCP connection with the server.

(7) And (3) detecting whether the message of the client is received or not by the server at intervals of 0.5 times of Keep Alive time, if the message of the client is not received by the server within 1.5 times of Keep Alive time, entering the step (8), and if the message of the client is received, continuing the step (7).

(8) The server actively disconnects the TCP connection with the client.

Preferably, the message publishing process of the internet of things communication protocol specifically comprises the following steps:

(1) The publisher establishes connection with the server through the flow of establishing connection between the client and the server.

(2) The publisher generates a PUBLISH type message: the message type is set as PUBLISH, qoS level in the message is set, and Topic name of message release is set in Payload.

(3) Judging the QoS level value in the message, if the QoS level value is equal to 0, entering the step (4), otherwise, entering the step (7).

(4) And (3) the publisher sends the PUBLISH type message generated in the step (2) to the server.

(5) And the server sends the message to a subscriber subscribing the message body according to the Topic name in the message.

(6) The publisher locally deletes the currently published PUBLISH message. The message publishing flow for the message quality of service level with QoS level of 0 ends.

(7) The publisher persists the current PUBLISH message locally and then sends the message to the server.

(8) After receiving the PUBLISH message, the server persists the message to the local of the server, and then sends the message to a subscriber subscribing to the message body according to the Topic name in the message. If the QoS level of the message is 1, the procedure goes to step (9), and if the QoS level is 2, the procedure goes to step (11).

(9) The server deletes the PUBLISH message locally from the server and returns a PUBACK type message to the publisher.

(10) After the publisher receives the PUBACK type message returned by the server, the publisher deletes the PUBLISH message stored in the local persistence. The message publishing flow for the message quality of service level with QoS level 1 ends.

(11) The server returns a PUBREC type message to the publisher.

(12) After receiving the PUBREC type message returned by the server, the publisher sends a PUBREL type message to the server.

(13) After receiving the PUBREL message returned by the publisher, the server locally deletes the PUBLISH message from the server and returns a PUBCOMP type message to the publisher.

(14) After receiving the PUBCOMP type message returned by the server, the publisher deletes the PUBLISH message stored locally by the publisher; the message publishing flow for the message quality of service level with QoS level 2 ends.

Preferably, the message subscription flow in the networking communication protocol specifically includes:

(1) The subscriber establishes connection with the server through the connection establishment flow of the client and the server.

(2) The subscriber generates a SUBSCRIBE type message, and sets the Payload content as a topic list to be subscribed and a QoS level value corresponding to each topic.

(3) The subscriber sends the SUBSCRIBE message to the server.

(4) And after receiving the SUBSCRIBE type message of the subscriber, the server returns a SUBACK type message to the subscriber.

(5) The server polls the PUBLISH message sent by the publisher, if the PUBLISH message meets that the topic corresponding to the published message is in the topic category subscribed by the SUBSCRIBE message and the QoS level value in the published message is greater than or equal to the QoS level value in the SUBSCRIBE message, the step (6) is entered, and if not, the flow is ended.

(6) And (5) the server sends the PUBLISH message meeting the condition in the step (5) to the subscriber.

(7) If the subscriber needs to cancel the subscribed subject message, the subscriber sends an UNSUBSCRIBE type message to the server.

(8) After receiving the UNSUBSCRIBE type message sent by the subscriber, the server returns an UNSUBSCRIBE type message to the subscriber, and simultaneously the server stops pushing the PUBLISH message corresponding to the unsubscribed topic to the subscriber.

Compared with the prior art, one of the technical schemes has the following beneficial effects: protocol messages in the communication protocol are simplified, the message structure is composed of a fixed header (one byte) +a variable header+a Payload (message body), the minimum message size is 2 bytes, and the consumption of bandwidth is greatly saved. The effects of high transmission efficiency and high speed are realized. Using the publish/subscribe messaging model, one-to-many messaging is provided to decouple applications. Message transmission masked from the payload content. The method is suitable for communication among the Internet of things equipment in various scenes, and three registered message release QoS (quality of service) are provided. And providing a notification mechanism, wherein the server side notifies both transmission sides when the interrupt occurs.

Drawings

Fig. 1 is a message model of a lightweight internet of things communication protocol based on publish-subscribe according to an embodiment of the present disclosure.

Fig. 2 is a message structure of a lightweight internet of things communication protocol based on publish-subscribe according to an embodiment of the present disclosure.

Fig. 3 is a fixed header structure of a lightweight internet of things communication protocol based on publish-subscribe according to an embodiment of the present disclosure.

FIG. 4 is a range of values corresponding to the number of bytes of the remaining length.

Fig. 5 is a variable header structure of a lightweight internet of things communication protocol based on publish-subscribe according to an embodiment of the present disclosure.

Fig. 6 is a message structure of connection Flags Connect Flags provided in an embodiment of the present disclosure.

Fig. 7 is a flowchart of establishing connection and maintaining connection between a client and a server according to an embodiment of the present disclosure.

Fig. 8 is a schematic diagram of a message publishing process according to an embodiment of the present disclosure.

Fig. 9 is a flowchart of message subscription provided by an embodiment of the present disclosure.

Detailed Description

In order to clarify the technical scheme and working principle of the present invention, the following describes the embodiments of the present disclosure in further detail with reference to the accompanying drawings. Any combination of the above-mentioned optional solutions may be adopted to form an optional embodiment of the present disclosure, which is not described herein in detail.

The terms "1, 2, 3 and the like in the description and the claims of this application and in the above-described figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those described herein.

The embodiment of the disclosure provides a lightweight internet of things communication protocol based on publish-subscribe, which is specifically as follows:

FIG. 1 is a message model of a lightweight Internet of things communication protocol based on publish-subscribe, and in combination with the figure, the message model of the communication protocol is: the subscriber sends a subscription type message to the proxy server, the publisher sends a published message type message to the proxy server, and the proxy server pushes the published message to the subscriber.

Fig. 2 is a message structure of a lightweight internet of things communication protocol based on publish-subscribe, and in combination with the figure, the message structure of the protocol is: protocol frames consist of a Fixed Header (Fixed Header), a Variable Header (Variable Header) and a message body (Payload).

Fig. 3 is a fixed packet header structure of a lightweight internet of things communication protocol based on publish-subscribe, and in combination with the figure, the fixed packet header structure is as follows: the first 4 bits of the first byte of the fixed header are used for specifying the protocol Message Type (Message Type), and the last 4 bits are used for specifying the protocol Message identification bit; starting from the second byte is the Remaining Length (Remaining Length).

1: the CONNECT initiates a connection which,

2: the connection acknowledgement of the CONNACK,

3: the PUBLISH message is issued by the PUBLISH,

4: the PUBACK QoS1 message acknowledgement,

5: the PUBREC QoS2 message receipt (guaranteed delivery first step),

6: the PUBREL QoS2 message is released (guaranteed delivery second step),

7: the PUBCOMP QoS2 message is complete (guarantee delivery third step),

8: the SUBSCRIBE request is sent to the subscriber,

9: the confirmation of the subscription to the backup,

10: UNSUBSCRIBE is unsubscribed from the subscription,

11: unsubscribe acknowledgement 0,

12: a ping req heartbeat request is sent to the client,

13: the PINGRESP heartbeat response is provided with,

14: DISCONNECT.

QoS level: the service quality level of the message is identified, and the QoS level has three values of 0,1 and 2, which represent the service quality levels of three message:

0: the message can only reach the server once or not at all; the delivery of messages relies on the underlying TCP/IP network.

1: at least once, ensuring that the message arrives, but the message may be repeatedly sent; the message reception of the server is confirmed by the PUBACK message, and if the communication link or the transmitting device is abnormal or the confirmation message is not received within a designated time, the transmitting end retransmits the message with the DUP bit set in the message header.

2: only once, ensuring that the message arrives once. Ensuring that subscribers receive and only receive messages once.

The residual length is the sum of the length of the variable message header and the length of the message body. The remaining length uses length coding, a minimum of one byte, a maximum of 4 bytes, each byte can encode 128 values +1 continuation bits, the most significant bit being the continuation bit indicating whether there are more bytes, and bit 7 indicating 128 values. Fig. 4 is a range of values corresponding to the number of bytes of the remaining length, and, in combination with this figure, the minimum value is 127 when the remaining length is one byte, the minimum value is 128 when the remaining length is two bytes, the maximum value is 16383, the minimum value is 16384 when the remaining length is three bytes, the maximum value is 2097151, and the minimum value is 2097152 when the remaining length is four bytes, the maximum value is 268435455, i.e., the maximum value can represent 256M.

Fig. 5 is a structure of a variable header of a lightweight internet of things communication protocol based on publish-subscribe, and in combination with the figure, the variable header includes four fields: protocol Name, protocol version Protocol NVersion, connection Flags Connect Flags, keep Alive.

Preferably, the protocol name is a character string of UTF-8 codes of a communication protocol name used by the server, the protocol name is specifically formulated by the server, and if the server detects that the protocol name in the message requested by the client is inconsistent with the formulation of the server, the server needs to disconnect from the client.

Preferably, the protocol version is a version number of a communication protocol of the server, and if the protocol version of the client is different from that of the server, the server needs to disconnect the client.

Fig. 6 is a message structure of a connection flag Connect Flags, which is used to specify connection behavior between a client and a server in connection with the figure. The connection flag is represented by one byte, and

bits

0, 5, 6, and 7 are reserved bits, preferably, reserved bits are extension fields. Bit 1 is Clean Session, bit 2 is Will Flag, bit 3 is Will QoS, and bit 4 is Will return.

The Will Falg: the legacy token, 1, indicates that if a connection request is accepted, a legacy message must be stored by the server and associated with the network connection, and when the network connection is broken, the server must issue the legacy message unless the server deletes the legacy message when receiving the DISCONNECT message.

The Will return: the remains the identification bit, if remains the identification to set to 0, remains the identification to set to 0 too, if remains the identification to set to 1, if remains the order to keep to 0, the server must issue remains the information as non-reservation information, if remains the order to keep to 1, the server must issue remains the information as the reservation information.

The Keep-Alive connection is a maximum time interval in seconds, which is expressed by two bytes, and is mainly used for keeping the long connection of the TCP established by the client month server, and the maximum value of Keep Alive is 65535, namely 18 hours, 12 minutes and 15 seconds.

Preferably, the policy that the client keeps connected: the client is responsible for ensuring that the time interval for control message transmission does not exceed the value for maintaining the connection. If no other control messages can be sent, the client must send a PINGREQ message. Regardless of the value of the connection maintained, the client can send a PINGREQ message at any time and use the PINGRESP message to determine the network and server activity status. After the client sends the PINGREQ message, it should close the network connection to the server if the PINGRESP message is not received within a reasonable time.

Preferably, the process of establishing connection and maintaining connection between the client and the server in the internet of things communication protocol specifically includes: fig. 7 is a flowchart of a connection establishment and connection maintenance between a client and a server, and in combination with the flowchart, the method specifically includes the following steps:

(3) The client sends the PINGREQ type message to the server periodically (every 60 seconds, and is configurable), and waits for the server to respond to the PINGRESP type message.

(4) If the client side overtime and does not receive the PINGRESP message of the server side response (the overtime time is configurable for 5 seconds), the step (5) is entered, and if the client side overtime and does not receive the PINGRESP message of the server side response, the step (7) is entered.

(5) The client sends a DISCONNECT type message to the server.

(6) The client actively disconnects the long TCP connection with the server.

(8) The server actively disconnects the TCP connection with the client.

Preferably, the message publishing process of the internet of things communication protocol is specifically shown in fig. 8, which is a schematic message publishing process, and in combination with the message publishing process, the message publishing process specifically includes the following steps:

(11) The server returns a PUBREC type message to the publisher.

Preferably, the flow of message subscription in the networking communication protocol is specifically a flow chart of message subscription in fig. 9, and in combination with the flow chart, the method specifically includes the following steps:

(3) The subscriber sends the SUBSCRIBE message to the server.

While the invention has been described above by way of example with reference to the accompanying drawings, it is to be understood that the invention is not limited to the particular embodiments described, but is capable of numerous insubstantial modifications of the inventive concepts and technical solutions; or the above conception and technical scheme of the invention are directly applied to other occasions without improvement and equivalent replacement, and all are within the protection scope of the invention.

Claims

1. A lightweight Internet of things communication protocol based on publish-subscribe is characterized in that the protocol specifically comprises the following steps:

the message model of the communication protocol is as follows: the subscriber sends a subscription type message to the proxy server, the publisher sends a published message type message to the proxy server, and the proxy server pushes the published message to the subscriber;

the message structure of the protocol is as follows: the protocol frame consists of a fixed message header, a variable message header and a message body;

the fixed message header structure is as follows: the first 4 bits of the first byte of the fixed message header are used for specifying the protocol message type, and the last 4 bits are used for specifying the protocol message identification bit; starting from the second byte is the remaining length;

1: connection, initiate a connection,

2: the connection acknowledgement,

3: PUBLISH, PUBLISH message,

4: the physical channel, qoS1 message acknowledgement,

5: the physical, qoS2 message receipt,

6: the physical, qoS2 message release,

7: the PUBCOMP, qoS2 message complete,

8: SUBSCRIBE, SUBSCRIBE request,

9: a SUBACK, a subscription confirmation,

10: UNSUBSCRIBE,

11: unsubscribe, unsubscribe acknowledgement 0,

12: PINGREQ, heartbeat request,

13: PINGRESP, heartbeat response,

14: DISCONNECT, DISCONNECT;

wherein the DUP flag: 1 is a message indicating that the current message is not sent for the first time, namely, is repeatedly sent;

QoS level: the service quality level of the message is identified, and the QoS level has three values of 0,1 and 2, which represent the service quality levels of three message: qoS level is 0, which means: the message can only reach the server once or not at all; qoS level of 1 indicates: at least once, ensuring that the message arrives, but the message may be repeatedly sent; qoS level of 2 indicates: only once, ensuring that the message arrives once;

RETAIN: 1 indicates that the transmitted message is to be persisted on a reader;

the residual length is the sum of the length of the variable message header and the length of the message body; the residual length uses variable length coding, a minimum of one byte and a maximum of 4 bytes, each byte can code 128 numerical values and +1 continuation bits, the highest bit is the continuation bit to indicate whether more bytes exist, and the 7 th bit indicates 128 numerical values;

the variable header includes four fields: protocol Name, protocol version Protocol NVersion, connection flag Connect Flags, keep connected Keep Alive;

the connection mark is used for specifying the connection behavior between the client and the server; the connection Flag is represented by one byte, the 0 th bit, the 5 th bit, the 6 th bit and the 7 th bit are used as reserved bits, the 1 st bit is Clean Session, the 2 nd bit is Will Flag, the 3 rd bit is Will QoS, and the 4 th bit is Will return;

the Clean Session: a session state processing mode, 0, indicates that a session is reserved, and after the current connection is disconnected, the client and the server must save session information; 1, cleaning session, not keeping offline message, reconnecting will establish new session;

the Will Falg: a legacy mark, 1, indicating that if a connection request is accepted, a legacy message must be stored by the server and associated with the network connection, and when the network connection is disconnected, the server must issue the legacy message unless the server deletes the legacy message when receiving the DISCONNECT message;

the Will QoS: the quality of service class identifier of the legacy message must also be set to 0 if the legacy identifier is set to 0, and the will QoS value may be equal to 0,1,2 if the legacy identifier is set to 2;

the Will return: the remains the identification bit, if remains the identification to set to 0, remains the identification to set to 0 too, if remains the identification to set to 1 when: if the remains of the remains are 0, the server must issue the remains information as non-reserved information, and if the remains of the remains are 1, the server must issue the remains information as reserved information;

2. The lightweight internet of things communication protocol based on publish-subscribe according to claim 1, wherein the numerical range corresponding to the number of bytes of the remaining length is specifically: when the remaining length is one byte, the minimum value is 0 and the maximum value is 127, the minimum value is 128 and the maximum value is 16383 when the remaining length is two bytes, the minimum value is 16384 and the maximum value is 2097151 when the remaining length is three bytes, and the minimum value is 2097152 and the maximum value is 268435455 when the remaining length is four bytes, namely the maximum value can represent 256M.

3. The lightweight internet of things communication protocol based on publish-subscribe according to claim 1, wherein the protocol name of the variable header is a UTF-8 encoded string of the communication protocol name used by the server, the protocol name is specifically formulated by the server, and if the server checks that the protocol name in the message requested by the client is inconsistent with the formulation of the server, the server needs to disconnect from the client.

4. A lightweight internet of things communication protocol based on publish-subscribe according to any one of claims 1-3, wherein the protocol version of the variable header is a version number of a server communication protocol, and if the protocol version of the client is different from the server, the server needs to disconnect the client.

5. The lightweight internet of things communication protocol based on publish-subscribe as set forth in claim 4, wherein the server maintains a policy of connection: the server judges whether to disconnect the inactive client through Keep Alive; if Keep Alive is non-zero and the server does not receive the control message from the client within one and five times of the Keep Alive time, it must disconnect the network connection from the client and consider the network connection to be disconnected.

6. The lightweight internet of things protocol based on publish-subscribe as set forth in claim 5, wherein the client maintains a connected policy: the client is responsible for ensuring that the time interval for sending the control message does not exceed the value for maintaining connection; if no other control message can be sent, the client must send a PINGREQ message; the client can send a PINGREQ message at any time regardless of the value of the connection, and the PINGRESP message is used for judging the activity states of the network and the server; after the client sends the PINGREQ message, if the PINGRESP message is not received within a reasonable time, the network connection to the server should be closed.

7. The lightweight internet of things communication protocol based on publish-subscribe according to any one of claims 5 or 6, wherein the process of establishing connection and maintaining connection between the client and the server in the internet of things communication protocol specifically comprises the following steps:

(1) The client establishes TCP long connection with the server, and the client sends a CONNECT type message to the server to start establishing connection;

(2) The method comprises the steps that after receiving a CONNECT message of a client, a server returns a CONNACK type message to the client, and the server confirms establishment of connection; after receiving the CONNACK message of the server, the client side indicates that the connection between the client side and the server side is successfully established;

(3) The client side sends PINGREQ type message information to the server side at regular time, and waits for the PINGRESP type message information responded by the server side;

(4) If the client side overtime does not receive the PINGRESP message responded by the server side, the step (5) is carried out, and if the PINGRESP message responded by the server side is received, the step (7) is carried out;

(5) The client sends a message of a DISCONNECT type to the server;

(6) The client actively disconnects the TCP long connection with the server;

(7) The server detects whether a message of the client is received or not every 0.5 times of Keep Alive time, if the server does not receive the message of the client within 1.5 times of Keep Alive time, the step (8) is entered, and if the message of the client is received, the step (7) is continued;

(8) The server actively disconnects the TCP connection with the client.

8. The lightweight internet of things communication protocol based on publish-subscribe according to any one of claims 5 or 6, wherein the message publishing process of the internet of things communication protocol specifically comprises:

(1) The publisher establishes connection with the server through the flow of establishing connection between the client and the server;

(2) The publisher generates a PUBLISH type message: setting the message type as PUBLISH, setting QoS level in the message, and setting the Topic name of message release in Payload;

(3) Judging the QoS level value in the message, if the QoS level value is equal to 0, entering the step (4), otherwise, entering the step (7);

(4) The publisher sends the PUBLISH type message generated in the step (2) to a server;

(5) The server sends the message to a subscriber subscribing the message body according to the Topic name in the message;

(6) The publisher locally deletes the currently published PUBLISH message; ending the message publishing flow of the message service quality level with the QoS level of 0;

(7) The publisher persists the current PUBLISH message to the local, and then sends the message to the server;

(8) After receiving the PUBLISH message, the server end persists the message to the local of the server end, and then sends the message to a subscriber subscribing the message body according to the Topic name in the message; if the QoS level of the message is 1, the step (9) is entered, and if the QoS level is 2, the step (11) is entered;

(9) The server side locally deletes the PUBLISH message from the server side and returns a PUBACK type message to the publisher;

(10) After the publisher receives the PUBACK type message returned by the server, the publisher deletes the PUBLISH message stored in a local persistent mode; ending the message publishing flow of the message service quality level with the QoS level of 1;

(11) The server returns a PUBREC type message to the publisher;

(12) After receiving the PUBREC type message returned by the server, the publisher sends a PUBREL type message to the server;

(13) After receiving the PUBREL message returned by the publisher, the server locally deletes the PUBLISH message from the server and returns a PUBCOMP type message to the publisher;

9. The lightweight internet of things communication protocol based on publish-subscribe according to any of claims 5 or 6, wherein the message subscription flow in the internet of things communication protocol is specifically:

(1) The subscriber establishes connection with the server through the process of establishing the connection between the client and the server;

(2) The subscriber generates a SUBSCRIBE type message, and sets the Payload content as a topic list to be subscribed and a QoS level value corresponding to each topic;

(3) The subscriber sends the SUBSCRIBE message to a server;

(4) After receiving the SUBSCRIBE type message of the subscriber, the server returns a SUBACK type message to the subscriber;

(5) The server polls a PUBLISH message sent by a publisher, if the PUBLISH message meets that the topic corresponding to the published message is in the topic category subscribed by the SUBSCRIBE message and the QoS level value in the published message is greater than or equal to the QoS level value in the SUBSCRIBE message, the step (6) is entered, and if not, the flow is ended;

(6) The server sends the PUBLISH message meeting the conditions in the step (5) to a subscriber;

(7) If the subscriber needs to cancel the subscribed subject message, the subscriber sends an UNSUBSCRIBE type message to the server;