MQTT transmission method and system
By negotiating the message header and heartbeat interval with Broker, the existing MQTT protocol has solved the problem of large memory usage and high network traffic on resource-constrained devices, and efficient and reliable communication is achieved.
Patent Information
- Application Number
- CN202411981927.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-04-25
AI Technical Summary
When the existing MQTT protocol is used on resource-constrained devices, there is a standardized header structure and large, the quality of service level, resulting in large memory usage, fixed heartbeat intervals, resulting in unnecessary network traffic, resulting in low communication efficiency.
By negotiating the message header with Broker, update it to a fixed-length message header, selecting the service quality level and negotiating the initial heartbeat interval, adjusting the heartbeat interval in real time, reducing unnecessary network traffic.
It simplifies the protocol header, reduces memory footprint and network transmission overhead, improves communication efficiency, and ensures real-time and reliability of communication.
Smart Images
Figure CN119892810A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of MQTT information transmission, and in particular to an MQTT transmission method and system. Background Art
[0002] MQTT is a lightweight, publish / subscribe-based messaging protocol that is widely used in the IoT field. However, the current MQTT protocol architecture is large and has limitations when used on resource-constrained devices.
[0003] At present, the main technical pain points of the MQTT protocol architecture applied to resource-constrained devices are: (1) the structure of the existing MQTT message header is standardized and relatively large, which occupies a large amount of memory; (2) the existing MQTT protocol provides three levels of service quality, and the higher the level of service quality, the larger the memory usage; (3) the existing MQTT protocol uses a fixed heartbeat interval, which will result in unnecessary network traffic. It can be seen that the existing MQTT protocol message transmission process is complex and the communication efficiency is low, which is not conducive to providing efficient and reliable communication services for resource-constrained IoT devices. Summary of the invention
[0004] In order to solve the above problems, the present invention proposes an MQTT transmission method and system to simplify the MQTT protocol message transmission process and improve communication efficiency.
[0005] To achieve the above-mentioned purpose, an embodiment of the present invention provides an MQTT transmission method, comprising: after establishing a connection with a Broker, negotiating a message header with the Broker and updating a message header with a fixed length; based on the fixed-length message header, selecting a service quality level with the Broker and negotiating an initial heartbeat interval with the Broker, sending a subscription message to the Broker so that the Broker feeds back a response code message based on the subscription message; receiving the response code message, completing the subscription and receiving the latest heartbeat interval that the Broker adjusts and feeds back in real time based on network conditions and device activity; receiving the latest heartbeat interval, sending a publish message to the Broker, and completing information transmission with the Broker based on the service quality level.
[0006] The embodiment of the present invention proposes an MQTT transmission method, which negotiates and adopts a fixed-length message header after establishing a connection with a Broker, thereby reducing the complexity of message parsing, and then quickly sends a subscription message and completes the subscription after selecting a service quality level and negotiating an initial heartbeat interval, thereby effectively shortening the connection establishment time. After completing the subscription, by receiving the heartbeat interval adjusted by the Broker according to the network and device conditions, unnecessary network traffic is reduced, ensuring the real-time and reliability of communication. When sending a publish message, information transmission is completed according to the selected service quality level, thereby reducing unnecessary communication and storage overheads, and further improving communication efficiency.
[0007] Furthermore, after establishing a connection with the Broker, negotiating a message header with the Broker and updating a message header with a fixed length includes: sending a connection request to the Broker, and establishing a connection with the Broker after receiving an authentication success result returned by the Broker; after establishing a connection with the Broker, negotiating a message header with the Broker and updating the message header to a message header with a length of two bytes; wherein the message header with a length of two bytes includes: a first byte consisting of the highest four bits of the message type and the lowest four bits of the control flag and a second byte consisting of the remaining length.
[0008] Through the above scheme, by simplifying the protocol header and removing unnecessary fields, the message header is updated to two bytes, retaining only the necessary message type, control flag and remaining length, which reduces the complexity of protocol parsing, reduces the overhead of network transmission, and improves communication efficiency.
[0009] Furthermore, based on the fixed-length message header, the service quality level is selected with the Broker and the initial heartbeat interval is negotiated with the Broker, and a subscription message is sent to the Broker so that the Broker feeds back a response code message based on the subscription message, including: based on the fixed-length message header, negotiating with the Broker to select and set the service quality level; actively initiating heartbeat interval negotiation, receiving the time value returned by the Broker to keep the connection active, and obtaining the initial heartbeat interval; when the service quality level and the initial heartbeat interval are both set, sending a subscription message to the Broker so that the Broker feeds back a response code message based on the subscription message.
[0010] Furthermore, when the service quality level and the initial heartbeat interval are set, a subscription message is sent to Broker so that Broker feeds back a response code message based on the subscription message, including: when the service quality level and the initial heartbeat interval are set, a subscription topic is selected according to a predefined topic list; a subscription message corresponding to the subscription topic is sent to Broker so that Broker matches the response code message from the topic tree structure.
[0011] Through the above scheme, the subscription relationship is managed using the topic tree structure, so that the client can choose to subscribe from a predefined topic list, and the Broker can search and match topics in the topic tree, thus reducing the transmission of repeated topic strings and improving communication efficiency.
[0012] Furthermore, receiving the response code message, completing the subscription and receiving the latest heartbeat interval adjusted and fed back by the Broker in real time based on the network status and device activity, includes: receiving the response code message and completing the subscription; according to the initial heartbeat interval, merging the data packet and the heartbeat packet of a preset data volume and sending them to the Broker, so that the Broker obtains the network delay according to the round-trip time of the data packet, so that the Broker calculates the packet loss rate according to the number of message responses within the preset time interval; so that the Broker obtains the network status according to the network delay and the packet loss rate; so that the Broker obtains the device activity based on the message sending frequency within the preset time interval; so that the Broker adjusts and feeds back the latest heartbeat interval in real time based on the network status and the device activity.
[0013] Through the above scheme, the message is first sent according to the initial heartbeat interval, and the network delay and packet loss rate are calculated to obtain the network status and the device activity status. The feedback heartbeat interval is adjusted according to the network status and the device activity status, which can better adapt to different network conditions, reduce unnecessary resource consumption or avoid erroneous connection closure due to long-term no response. In addition, merging the data packet and the heartbeat packet with a preset data volume can also reduce the number of times a separate heartbeat packet is sent. While ensuring the stability of the connection, it minimizes resource waste and improves communication efficiency.
[0014] Further, receiving the latest heartbeat interval, resending the publish message to Broker, and completing information transmission with Broker based on the service quality level, including: the service quality level is: level 1 service quality; receiving the latest heartbeat interval, updating the initial heartbeat interval to the latest heartbeat interval; based on the latest heartbeat interval, when sending the publish message to Broker with level 1 service quality, after receiving the confirmation message fed back by Broker through level 1 service quality, deleting the locally stored copy of the publish message, and completing information transmission. The service quality level is: level 0 service quality; receiving the latest heartbeat interval, updating the initial heartbeat interval to the latest heartbeat interval; based on the latest heartbeat interval, when sending the publish message to Broker with level 0 service quality, no message confirmation is performed with Broker, and information transmission is completed.
[0015] Through the above scheme, the service quality level is simplified to two levels: level 0 quality of service and level 1 quality of service. The simplified service quality mechanism reduces the complexity of the processing logic, reduces unnecessary communication and storage overhead, and improves communication efficiency. For level 1 quality of service, a simplified confirmation mechanism is introduced. The Broker only returns a confirmation message, reducing the number of interactions. For level 0 quality of service, only one transmission is supported, and it is not confirmed whether it has actually reached the target, which saves unnecessary confirmation and retransmission overhead and further improves communication efficiency.
[0016] Furthermore, an embodiment of the present invention proposes an MQTT transmission method which also includes: when the connection with the Broker is disconnected, the session state with the Broker is not maintained; when the session state needs to be restored, a session recovery request is sent to the Broker, so that the Broker restores the session state based on the session recovery request and restores the subscription state.
[0017] Through the above solution, after the client disconnects, the Broker does not retain its session state, which reduces the storage pressure of the Broker and improves the scalability of the system. In addition, when the client needs to restore the session state, it sends a special session recovery request. The Broker restores the client's subscription state according to the request, but does not retain the message queue to re-complete the subscription. Through a lightweight session recovery mechanism, the client is allowed to quickly restore the subscription state after disconnection, thereby improving communication efficiency.
[0018] Furthermore, an embodiment of the present invention proposes an MQTT transmission method which also includes: negotiating a wake-up window with a Broker, entering a deep sleep state, and waiting to be awakened; when receiving a wake-up message sent by the Broker in the wake-up window, terminating the deep sleep state and re-entering the running state.
[0019] Through the above solution, it is also possible to enter a deep sleep state and a low power mode, and reawaken on demand during the wake-up window, which helps to extend the battery life of the device.
[0020] An embodiment of the present invention also provides an MQTT transmission system, comprising: a client and a Broker; the Broker is used to receive messages from the client and process requests sent by the client; the client is used to negotiate message headers with the Broker after establishing a connection with the Broker, and update the message headers using a fixed length; based on the message headers with a fixed length, select a service quality level with the Broker and negotiate an initial heartbeat interval with the Broker, send a subscription message to the Broker, so that the Broker feeds back a response code message based on the subscription message; receive the response code message, complete the subscription and receive the latest heartbeat interval that the Broker adjusts and feeds back in real time based on network conditions and device activity; receive the latest heartbeat interval, send a publish message to the Broker, and complete information transmission with the Broker based on the service quality level.
[0021] The embodiment of the present invention proposes an MQTT transmission system, which establishes a connection with a Broker, negotiates and adopts a fixed-length message header, reduces the complexity of message parsing, and then quickly sends a subscription message and completes the subscription after selecting a service quality level and negotiating an initial heartbeat interval, effectively shortening the connection establishment time. After completing the subscription, by receiving the heartbeat interval adjusted by the Broker according to the network and device conditions, unnecessary network traffic is reduced, ensuring the real-time and reliability of communication. When sending a publish message, information transmission is completed according to the selected service quality level, reducing unnecessary communication and storage overhead, and further improving communication efficiency. BRIEF DESCRIPTION OF THE DRAWINGS
[0022] Figure 1 A schematic diagram of a step flow of an MQTT transmission method provided in an embodiment of the present invention;
[0023] Figure 2 A schematic diagram of a subscription topic tree structure of an MQTT transmission method provided in an embodiment of the present invention;
[0024] Figure 3 A schematic diagram of the module structure of an MQTT transmission system provided in an embodiment of the present invention;
[0025] Among them, 301, client; 302, broker. DETAILED DESCRIPTION
[0026] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0027] In this embodiment, the message names related to the MQTT protocol are as an explanation of the embodiment of the present invention. CONNECT represents a connection message, PUBLISH represents a publish message, SUBSCRIBE represents a subscription message, and SUBACK message represents a response code message, which will not be described in detail below.
[0028] Example 1
[0029] See also Figure 1 , Figure 1 A schematic diagram of a step flow of an MQTT transmission method provided by an embodiment of the present invention. Figure 1 As shown, the embodiment of the present invention proposes an MQTT transmission method, including steps 101 to 104, each step is specifically as follows:
[0030] Step 101, after establishing a connection with the Broker, negotiate the message header with the Broker and update the message header using a fixed length;
[0031] As an example of this embodiment, a connection request is sent to the Broker, and when the authentication success result returned by the Broker is received, a connection is established with the Broker; after the connection with the Broker is established, the message header is negotiated with the Broker and the message header is updated to a message header with a length of two bytes; wherein the message header with a length of two bytes includes: a first byte consisting of the highest four bits of the message type and the lowest four bits of the control flag, and a second byte consisting of the remaining length.
[0032] The existing MQTT protocol message header is standardized and not of fixed length. The existing MQTT protocol message header consists of a fixed header, a variable header, and a payload. In order to improve communication efficiency, the embodiment of the present invention proposes to simplify the message header. By simplifying the protocol header and removing unnecessary fields, the message header is updated to two bytes, and only the necessary message type, control flag, and remaining length are retained, thereby reducing the complexity of protocol parsing, reducing the overhead of network transmission, and improving communication efficiency. A specific implementation method is to send a connection request to Broker, and after receiving the authentication success result returned by Broker, establish a connection with Broker. The specific connection establishment method is consistent with the prior art and will not be repeated here. After establishing a connection with Broker, negotiate with Broker to simplify the message header to two bytes, as shown in Table 1.
[0033] Table 1 Fixed-length message header format diagram
[0034]
[0035] As can be seen from Table 1, the first byte includes: control flags and message type; wherein, the highest 4 bits represent the message type (such as PUBLISH and SUBSCRIBE, etc.), and it is feasible to use 4 bits (bits) to represent the message type in the MQTT protocol, because the total number of message types defined by the standard MQTT is 14 (from 0 to 15), which can be represented by a 4-bit binary number; the lowest 4 bits represent the control flag (the four flags of retransmission flag DUP, service quality level QoS Level, retention flag RETAIN and extension flag FLAGS each occupy 1 bit); the second byte: Remaining Length, in the embodiment of the present invention, only for lightweight scenarios (lightweight data), one byte is used to represent the length of 0 to 255 bytes; it is worth mentioning that the simplified message header format must be consistent in all clients and Brokers to ensure that all components follow the same standard;
[0036] Step 102, based on the fixed-length message header, select a service quality level with the Broker and negotiate an initial heartbeat interval with the Broker, and send a subscription message to the Broker, so that the Broker feeds back a response code message based on the subscription message;
[0037] As an example of this embodiment, based on the fixed-length message header, negotiate with the Broker to select and set the service quality level; actively initiate heartbeat interval negotiation, receive the time value returned by the Broker to keep the connection active, and obtain the initial heartbeat interval; when the service quality level and the initial heartbeat interval are set, send a subscription message to the Broker so that the Broker can feedback a response code message based on the subscription message. When the service quality level and the initial heartbeat interval are set, select a subscription topic based on the predefined topic list; send a subscription message corresponding to the subscription topic to the Broker so that the Broker can match the response code message from the topic tree structure.
[0038] In order to solve the problem of repeated string transmission and data redundancy when the client subscribes to a topic in the prior art, the subscription relationship is managed by using a topic tree structure to enable the client to select a subscription from a predefined topic list. The Broker searches and matches the topic in the topic tree, reducing repeated topic string transmission and improving communication efficiency. A specific implementation method is to negotiate with the Broker to select and set the service quality level based on the fixed-length message header. Generally, only QoS 0 (level 0 service quality) is supported by default. When necessary, a simplified QoS1 (level 1 service quality) mechanism is enabled. The client actively initiates the negotiation of the heartbeat interval. The Broker sets the heartbeat interval according to the network status and device requirements, and notifies the client. The client receives the time value returned by the Broker to keep the connection active and obtains the initial heartbeat interval. When the service quality level and the initial heartbeat interval are set, the client sends a SUBSCRIBE message to subscribe to the topic. The Broker processes the subscription request based on the topic tree and updates the internal subscription relationship. For details, see Figure 2 , Figure 2 A schematic diagram of a subscription topic tree structure of an MQTT transmission method provided in an embodiment of the present invention; Figure 2 As shown in the figure, the topic tree structure is used to organize and manage subscription relationships. Each node (A, B, and C) represents a topic level, and the leaf nodes (AA, AB, BB, and CC) represent specific topics. A set of predefined topic roots are provided to the client, and the client can choose to subscribe to these topics. The client chooses to subscribe from the predefined topic list, and the Broker matches according to the list. When the client subscribes, the Broker searches and matches the topic in the topic tree to reduce the transmission of repeated topic strings. When the Broker matches the topic subscribed by the client, it feedbacks the corresponding SUBACK message;
[0039] As another example of an embodiment of the present invention, after disconnecting from the Broker, the session state is not maintained with the Broker; when the session state needs to be restored, a session restoration request is sent to the Broker, so that the Broker restores the session state based on the session restoration request and restores the subscription state.
[0040] In order to quickly respond to the topics subscribed by the client, the storage pressure of the Broker will determine the communication efficiency. In order to reduce the storage pressure of the Broker, the session state is not maintained by default. Therefore, the client needs to re-subscribe each time. Then, a session recovery mechanism is designed to enable the client to quickly restore the subscription state and improve communication efficiency. A specific implementation method is that by default, when the client is disconnected from the Broker, the Broker does not maintain the session state, and provides a lightweight session recovery mechanism to allow the client to quickly restore the subscription state after the disconnection. That is, when the client needs to restore the session, it sends a special recovery request to the Broker. The Broker restores the client's subscription state according to the recovery session request sent by the client, but does not retain the message queue, thereby reducing the storage pressure of the Broker and improving communication efficiency.
[0041] Step 103, receiving the response code message, completing the subscription and receiving the latest heartbeat interval that Broker adjusts and feedbacks in real time based on the network status and device activity status;
[0042] As an example of this embodiment, the response code message is received to complete the subscription; according to the initial heartbeat interval, the data packet and the heartbeat packet of the preset data volume are combined and sent to the Broker, so that the Broker obtains the network delay according to the round-trip time of the data packet; the Broker calculates the packet loss rate according to the number of message responses within the preset time interval; the Broker obtains the network status according to the network delay and the packet loss rate; the Broker obtains the device activity based on the message sending frequency within the preset time interval; the Broker adjusts and feedbacks the latest heartbeat interval in real time based on the network status and the device activity.
[0043] When the client receives the SUBACK message fed back by the Broker and completes the subscription, it will start to forward messages. In the prior art, when establishing a connection, the heartbeat interval (i.e., the time to keep the connection active) is specified through the Keep Alive field in the CONNECT message. Once the heartbeat interval is set, the client and the Broker will use the heartbeat interval to perform the entire session, unless the client disconnects from the Broker and re-acquires the Keep Alive field. Alive field, therefore, the fixed heartbeat interval of the prior art will lead to unnecessary resource consumption or avoid erroneous connection closure due to long-term no response, affecting communication efficiency. In order to solve this problem, the embodiment of the present invention proposes that the acquisition of the initial heartbeat interval is consistent with the prior art, but introduces a dynamic adjustment mechanism so that the heartbeat interval can adjust the feedback heartbeat interval according to the network status and the activity of the device, which can better adapt to different network conditions, reduce unnecessary resource consumption or avoid erroneous connection closure due to long-term no response. A specific method is to combine the heartbeat packet with a small data packet of a preset data volume and send it to the Broker according to the initial heartbeat interval. The Broker adjusts the heartbeat interval according to the network status and the activity of the device. Specifically, the client and the Broker usually use 4 technologies to monitor the network status: (1) send a small data packet in combination with the heartbeat packet and measure the round-trip time (RTT) to evaluate the network delay; (2) count the number of messages that have not received the expected response within 30 minutes to calculate the packet loss rate; (3) analyze the message transmission speed and network congestion to estimate the available bandwidth; (4) According to the network DBM signal strength in the message released by the IoT device, the current network signal strength can be intuitively judged; and usually the client and Broker use the message sending frequency recorded every 30 minutes to determine whether the device is in a high or low activity state. For example, more than 1 message in 1 minute is high activity, so as to detect the device activity. By judging the network status and device activity, when the network status is good, the network delay is low, the network packet loss rate is low, the activity is high and the battery is sufficient, the heartbeat interval is increased, and the Broker sets a new heartbeat interval in the client's subscription information and sets its own heartbeat interval to be larger. When the network status is poor, the network delay is high, the network packet loss rate is high, the activity is low and the battery is insufficient, the heartbeat interval is reduced, and the Broker sets a new heartbeat interval in the client's subscription information and sets its own heartbeat interval to be smaller. It is worth mentioning that the priority of judging the network status is higher than the priority of the device activity to ensure that the connection remains healthy and problems can be handled in time.
[0044] Step 104, receiving the latest heartbeat interval, sending a publish message to the Broker, and completing information transmission with the Broker based on the service quality level.
[0045] As an example of this embodiment, the service quality level is: Level 1 service quality; receiving the latest heartbeat interval, updating the initial heartbeat interval to the latest heartbeat interval; based on the latest heartbeat interval, when sending a publish message to Broker with Level 1 service quality, after receiving a confirmation message from Broker through Level 1 service quality feedback, the locally stored copy of the publish message is deleted to complete the information transmission.
[0046] As another explanation of this embodiment, the service quality level is: level 0 service quality; receiving the latest heartbeat interval, updating the initial heartbeat interval to the latest heartbeat interval; based on the latest heartbeat interval, when sending a publish message to Broker with level 0 service quality, no message confirmation is performed with Broker, and the information transmission is completed.
[0047] The prior art divides the service quality level Qos Level into three levels, namely Qos0, Qos1 and Qos2. The multi-level optional situation makes the processing logic of the client and the Broker complicated, which is not conducive to providing efficient and reliable communication services for resource-constrained IoT devices. In order to solve this problem, the embodiment of the present invention proposes to divide the service quality level Qos Level is simplified into two levels: Level 0 Quality of Service (Qos0) and Level 1 Quality of Service (Qos1). The simplified quality of service mechanism reduces the complexity of the processing logic, reduces unnecessary communication and storage overhead, and improves communication efficiency. A specific implementation method is that Qos0 only supports one-time sending, does not confirm the message, and eliminates the confirmation and retransmission mechanism; Qos1 provides an ACK mechanism. After the client sends a PUBLISH message, the Broker returns a simplified ACK message in response. The ACK message is used to confirm that the Broker has successfully received the PUBLISH message. After receiving the ACK, the client deletes the local PUBLISH message copy. The simplified Qos1 mechanism ensures at least one message delivery and reduces the possibility of message loss. Therefore, by simplifying the QosLevel, a more lightweight quality service option is provided, which maintains sufficient reliability and reduces the complexity of the protocol.
[0048] As another example of an embodiment of the present invention, a wake-up window is negotiated with the Broker, and a deep sleep state is entered to wait for wake-up; when a wake-up message sent by the Broker in the wake-up window is received, the deep sleep state is released and the running state is re-entered.
[0049] At present, the existing technology lacks an effective low-power mode, which is not conducive to the long-term operation of battery-powered devices. In order to solve this problem, an embodiment of the present invention proposes to negotiate a wake-up window with the Broker, and the client enters deep sleep. When it needs to be awakened, the Broker sends a wake-up message to make the client re-enter the running state, and the low-power mode is set to extend the battery life of the device. A specific implementation method is that the client negotiates a wake-up window with the Broker, and the client completely turns off the wireless module and enters the low-power mode until the next scheduled wake-up time. The Broker determines whether to send a wake-up message based on the activity of the device and the network status. When the client needs to be awakened, the Broker sends a special wake-up message, so that the client is activated after receiving the wake-up message within a specific time window, thereby achieving In addition to turning the low power mode on and off, the embodiment of the present invention also proposes a lightweight encryption algorithm (such as ChaCha20-Poly1305) to protect data transmission, negotiates the key when the client establishes a connection with the Broker, and uses a pre-shared key (PSK) for identity authentication to further improve the reliability of data encryption; it is worth mentioning that in order to enable resource-constrained IoT devices to provide efficient and reliable communication services, the embodiment of the present invention also proposes a built-in data compression mechanism (such as LZ4 or Snappy) to reduce the amount of transmitted data. The client compresses the data before sending it. Generally, compression is enabled only when it is more than 100 bytes. After the compression enabling conditions are met, it is sent to the Broker and decompressed by the Broker to achieve data compression.
[0050] The embodiment of the present invention proposes an MQTT transmission method, which negotiates and adopts a fixed-length message header after establishing a connection with a Broker, thereby reducing the complexity of message parsing, and then quickly sends a subscription message and completes the subscription after selecting a service quality level and negotiating an initial heartbeat interval, thereby effectively shortening the connection establishment time. After completing the subscription, by receiving the heartbeat interval adjusted by the Broker according to the network and device conditions, unnecessary network traffic is reduced, ensuring the real-time and reliability of communication. When sending a publish message, information transmission is completed according to the selected service quality level, thereby reducing unnecessary communication and storage overheads, and further improving communication efficiency.
[0051] Example 2
[0052] See also Figure 3 , Figure 3 A schematic diagram of the module structure of an MQTT transmission system provided in an embodiment of the present invention. Figure 3As shown, an embodiment of the present invention proposes an MQTT transmission system, including: a client 301 and a Broker 302; the Broker 302 is used to receive messages from the client and process requests sent by the client; the client 301 is used to negotiate a message header with Broker 302 after establishing a connection with Broker 302, and update a message header using a fixed length; based on the fixed-length message header, select a service quality level with Broker 302 and negotiate an initial heartbeat interval with Broker 302, send a subscription message to Broker 302, so that Broker 302 feeds back a response code message based on the subscription message; receive the response code message, complete the subscription and receive the latest heartbeat interval that Broker 302 adjusts and feeds back in real time based on network conditions and device activity; receive the latest heartbeat interval, send a publish message to Broker 302, and complete information transmission with Broker 302 based on the service quality level.
[0053] The embodiment of the present invention proposes an MQTT transmission system, which establishes a connection with a Broker, negotiates and adopts a fixed-length message header, reduces the complexity of message parsing, and then quickly sends a subscription message and completes the subscription after selecting a service quality level and negotiating an initial heartbeat interval, effectively shortening the connection establishment time. After completing the subscription, by receiving the heartbeat interval adjusted by the Broker according to the network and device conditions, unnecessary network traffic is reduced, ensuring the real-time and reliability of communication. When sending a publish message, information transmission is completed according to the selected service quality level, reducing unnecessary communication and storage overhead, and further improving communication efficiency.
[0054] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.
[0055] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the described specific features, structures, materials or characteristics may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples, unless they are contradictory.
[0056] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.
Claims
1. An MQTT transmission method, executed by a client, characterized in that: include: After establishing a connection with the Broker, negotiate the message header with the Broker and update the message header to use a fixed length; Based on the fixed-length message header, select a service quality level with the Broker and negotiate an initial heartbeat interval with the Broker, and send a subscription message to the Broker, so that the Broker feeds back a response code message based on the subscription message; Receive the response code message, complete the subscription and receive the latest heartbeat interval that Broker adjusts and feedbacks in real time based on network status and device activity; Receive the latest heartbeat interval, send a publish message to Broker, and complete information transmission with Broker based on the service quality level.
2. The MQTT transmission method according to claim 1, characterized in that: After establishing a connection with the Broker, the message header is negotiated with the Broker and the message header with a fixed length is updated, including: Send a connection request to Broker. After receiving the authentication success result returned by Broker, establish a connection with Broker. After establishing a connection with the Broker, negotiate the message header with the Broker and update the message header to a two-byte message header; wherein the two-byte message header includes: a first byte consisting of the highest four-bit message type and the lowest four-bit control flag and a second byte consisting of the remaining length.
3. The MQTT transmission method according to claim 1, characterized in that: Based on the fixed-length message header, the service quality level is selected with the Broker and the initial heartbeat interval is negotiated with the Broker, and a subscription message is sent to the Broker, so that the Broker feeds back a response code message based on the subscription message, including: Based on the fixed-length message header, negotiate with the Broker to select and set a service quality level; Actively initiate heartbeat interval negotiation, receive the time value returned by Broker to keep the connection active, and obtain the initial heartbeat interval; When the service quality level and the initial heartbeat interval are set, a subscription message is sent to the Broker so that the Broker feeds back a response code message based on the subscription message.
4. The MQTT transmission method according to claim 3, characterized in that: When the service quality level and the initial heartbeat interval are set, a subscription message is sent to the Broker, so that the Broker feeds back a response code message based on the subscription message, including: After the service quality level and initial heartbeat interval are set, select the subscription topic based on the predefined topic list; Send the subscription message corresponding to the subscription topic to Broker, so that Broker can match the response code message from the topic tree structure.
5. The MQTT transmission method according to claim 1, characterized in that: Receive the response code message, complete the subscription and receive the latest heartbeat interval that Broker adjusts and feedbacks in real time based on network status and device activity, including: Receive the response code message and complete the subscription; According to the initial heartbeat interval, the data packet and the heartbeat packet of the preset data volume are combined and sent to the Broker, so that the Broker can obtain the network delay according to the round-trip time of the data packet; the Broker can calculate the packet loss rate according to the number of message responses within the preset time interval; the Broker can obtain the network status according to the network delay and the packet loss rate; the Broker can obtain the device activity based on the message sending frequency within the preset time interval; the Broker can adjust and feedback the latest heartbeat interval in real time based on the network status and the device activity.
6. The MQTT transmission method according to claim 1, characterized in that: Receive the latest heartbeat interval, resend the publish message to Broker, and complete information transmission with Broker based on the service quality level, including: the service quality level is: level 1 service quality; Receive the latest heartbeat interval and update the initial heartbeat interval to the latest heartbeat interval; Based on the latest heartbeat interval, when a publish message is sent to Broker with level 1 service quality, after receiving a confirmation message from Broker that it passes level 1 service quality feedback, the locally stored copy of the publish message is deleted to complete the information transmission.
7. An MQTT transmission method according to claim 6, characterized in that: Receive the latest heartbeat interval, resend the publish message to Broker, and complete information transmission with Broker based on the service quality level, including: the service quality level is: 0 service quality; Receive the latest heartbeat interval and update the initial heartbeat interval to the latest heartbeat interval; Based on the latest heartbeat interval, when a publish message is sent to the Broker with a service quality of level 0, the message is not confirmed with the Broker and the information transmission is completed.
8. The MQTT transmission method according to claim 1, characterized in that: Also includes: When disconnected from the Broker, the session state with the Broker is not maintained; When the session state needs to be restored, a session recovery request is sent to the Broker, so that the Broker restores the session state based on the session recovery request and restores the subscription state.
9. The MQTT transmission method according to claim 1, characterized in that: Also includes: Negotiate the wake-up window with the Broker, enter deep sleep state, and wait for wake-up; When receiving the wake-up message sent by the Broker in the wake-up window, the deep sleep state is terminated and the running state is re-entered.
10. An MQTT transmission system, characterized in that: include: Client and Broker; The Broker is used to receive messages from the client and process requests sent by the client; The client is used to negotiate the message header with the Broker after establishing a connection with the Broker, and update the message header with a fixed length; based on the fixed-length message header, select the service quality level with the Broker and negotiate the initial heartbeat interval with the Broker, send a subscription message to the Broker, so that the Broker feeds back a response code message based on the subscription message; receive the response code message, complete the subscription and receive the latest heartbeat interval that the Broker adjusts and feeds back in real time based on the network status and device activity; receive the latest heartbeat interval, send a publish message to the Broker, and complete information transmission with the Broker based on the service quality level.