MQTT client message assurance method and system under multiple brokers

Abstract

The MQTT client message assurance method and system of the present invention include: S1, obtaining an available Broker address; S2, establishing a connection between a single-point MQTT client and an available Broker; S3, an independent thread waits for the available Broker to authenticate the MQTT client, if the authentication is successful, enters S4, if the authentication fails, executes S1; S4, determines whether there are historical unverified business messages in the message temporary queue, if so, enters S5, if not, enters S6; S5, takes out historical unverified business messages and sends them to the available Broker, enters S7; S6, waits for new business messages and sends them to the available Broker, and temporarily stores the new business message id as a keyword in the message temporary queue, enters S7; S7, waits for receipt of a sending completion callback notification containing a message id, clears the business message of the message id in the message temporary queue upon receipt, and repeats S6.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method and system for guaranteeing MQTT client messages in a multi-Broker environment. Background Art

[0002] With the rapid development of the Internet of Things (IoT) and messaging services, the MQTT protocol has become the preferred choice for communication between many devices due to its lightweight, low bandwidth consumption and high efficiency.

[0003] MQTT clients typically establish a connection with a single broker. Under existing offline conditions, this generally ensures reliable message transmission. However, if a single broker fails, the continuity and reliability of message delivery can be compromised, potentially leading to data loss and service interruption. In a multi-broker environment with high availability, disaster recovery, and load balancing, the need for identity verification after switching brokers can prevent messages from being recognized by the new broker simply by resending them during the outage.

[0004] In view of the above problems, the present invention proposes an MQTT client solution, which allows the client to access different available Brokers in sequence, and ensures the complete delivery of messages under any circumstances through reliable message management and failover strategies, thereby significantly improving the reliability and performance of the system. Summary of the Invention

[0005] In view of the problems and shortcomings of the prior art, the present invention provides an MQTT client message assurance method and system in a multi-Broker environment.

[0006] The present invention solves the above technical problems through the following technical solutions:

[0007] The present invention provides a method for guaranteeing MQTT client messages under multiple brokers, which is characterized in that it includes the following steps:

[0008] S1. Obtain an available Broker address and related configuration information from the Broker address management platform;

[0009] S2. Based on the address of the available Broker and its related configuration information, a single-point MQTT client is created and a connection is established between the single-point MQTT client and the available Broker.

[0010] S3. An independent thread waits for the authentication result of the available Broker to the single-point MQTT client. If the authentication result is successful, the process proceeds to step S4. If the authentication result is failed, the process repeats step S1.

[0011] S4, the independent thread determines whether there is a historical unverified business message in the temporary storage queue of the message to be verified. If yes, it proceeds to step S5; if not, it proceeds to step S6;

[0012] S5. The independent thread retrieves the historical unverified business message and sends it to the available Broker, and then proceeds to step S7.

[0013] S6. The independent thread waits for the new business message from the MQTT client and sends it to the available Broker. The message ID of the new business message is used as a keyword and temporarily stored in the temporary storage queue for messages to be verified, and then proceeds to step S7.

[0014] S7. The independent thread waits for a send completion callback notification containing the message ID, and upon receipt, clears the business message of the message ID from the temporary storage queue of messages to be verified with the message ID, and repeats step S6.

[0015] In step S7, if the independent thread encounters a network failure while waiting for receipt, it proceeds to step S1.

[0016] Preferably, after step S7, when a set clearing cycle is reached, the independent thread clears out the business messages whose temporary storage time in the temporary storage queue of the to-be-verified messages reaches the set temporary storage time.

[0017] The present invention also provides an MQTT client message assurance system under multiple Brokers, which is characterized in that it includes an acquisition module, a creation module and an independent thread module;

[0018] The acquisition module is used to obtain an available Broker address and related configuration information from the Broker address management platform;

[0019] The creation module is used to create a single-point MQTT client based on the address of the available Broker and its related configuration information obtained and returned, and establish a connection between the single-point MQTT client and the available Broker;

[0020] The independent thread module is used to use an independent thread to wait for the authentication result of the available Broker for the single-point MQTT client, and when the authentication result is successful, determine whether there is a historical unverified business message in the temporary storage queue of the message to be verified, and when there is a historical unverified business message, take out the historical unverified business message and send it to the available Broker, and when there is no historical unverified business message, wait for the new business message of the MQTT client and send it to the available Broker, and temporarily store the message ID of the new business message as a keyword in the temporary storage queue of the message to be verified, and call the acquisition module again when the authentication result is failed.

[0021] The independent thread module is also used to use an independent thread to wait for a sending completion callback notification containing a message ID, and when received, clear the business message of the message ID from the temporary storage queue of messages to be verified with the message ID, and wait again for a new business message to be sent;

[0022] The independent thread module is further configured to utilize the independent thread to call the acquisition module if a network failure occurs during the process of waiting for reception.

[0023] Preferably, the independent thread module is further configured to utilize the independent thread to clear out the business messages whose temporary storage time in the temporary storage queue of the to-be-verified messages reaches the set temporary storage time when a set cleaning cycle is reached.

[0024] The positive progress effect of the present invention is:

[0025] This invention improves message delivery reliability, ensuring that messages are not lost or resent during multiple broker switching processes, thereby enhancing the stability of the MQTT client. It also enhances the system's fault tolerance. Independent threads handle reconnection logic, enabling clients to automatically reconnect after a connection interruption and resend unconfirmed messages, ensuring system continuity and reliability. Furthermore, it optimizes resource utilization. Through independent threads and a message temporary queue mechanism, resources are effectively managed, reducing resource waste caused by unstable connections.

[0026] The present invention can safeguard production data transmission in economic production, ensuring that key data between sensors and control systems can be reliably transmitted, thereby avoiding production accidents or losses caused by data loss or delays. In addition, production efficiency is improved, and the stable message transmission mechanism reduces production stagnation caused by system failures or message loss during reconnection, thereby improving overall production efficiency. Furthermore, by reducing downtime and maintenance costs caused by message loss or system failures, enterprises can significantly reduce operating expenses. Enterprises with highly reliable message transmission mechanisms can provide better services, improve customer satisfaction and market competitiveness. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 This is a flowchart of the MQTT client message assurance method under multiple Brokers in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings 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 making creative efforts shall fall within the scope of protection of the present invention.

[0029] like Figure 1 As shown, this embodiment provides an MQTT client message assurance method under multiple Brokers. It takes independent threads as the core, uses the sending callback and disconnection callback features of the single-point MQTT client to judge the message status and link status, and establishes a message temporary queue mechanism. When processing the switching of multiple Brokers, the reconnection logic is used to ensure that the message can be resent, thereby achieving reliability assurance of message delivery.

[0030] This method includes the following steps:

[0031] Step 101: Obtain an available Broker address and related configuration information from the Broker address management platform.

[0032] Step 102: Based on the address of the available Broker and its related configuration information obtained and returned, a single-point MQTT client is created, and a connection is established between the single-point MQTT client and the available Broker.

[0033] Step 103: The independent thread waits for the authentication result of the available Broker to the single-point MQTT client. If the authentication result is successful, the process proceeds to step 104; if the authentication result is failed, the process repeats step 101.

[0034] Step 104 , the independent thread determines whether there is any historical unverified business message in the temporary storage queue of the message to be verified. If yes, the process proceeds to step 105 ; if not, the process proceeds to step 106 .

[0035] Step 105 : The independent thread retrieves the historical unverified business message and sends it to the available Broker, and then proceeds to step 107 .

[0036] Step 106 : The independent thread waits for a new business message from the MQTT client and sends it to the available Broker, and temporarily stores the message ID of the new business message as a keyword in a temporary storage queue for messages to be verified, and then proceeds to step 107 .

[0037] Step 107: The independent thread waits for receiving a sending completion callback notification containing the message ID, and upon receiving the notification, clears the business message of the message ID from the temporary storage queue of messages to be verified with the message ID, and repeats step 106.

[0038] In step 107 , if the independent thread encounters a network failure while waiting for receipt, it proceeds to step 101 .

[0039] In this embodiment, if a network failure occurs and the service message sent during the period is not completed, no callback notification will be generated and the temporarily stored message will not be cleared.

[0040] In this embodiment, after reconnection, identity authentication is required again. After successful identity authentication, all temporarily stored messages are retrieved and sent. If the message fails to be sent again, the failed message will continue to flow back to the temporary message queue and wait for the next sending. After identity authentication fails, a new available Broker needs to be obtained from the Broker address management platform.

[0041] After step 107, when a set clearing cycle is reached, the independent thread clears out the business messages whose temporary storage time in the temporary storage queue of the to-be-verified messages reaches the set temporary storage time.

[0042] In this embodiment, because the sending of the message and the completion callback response are very rapid, usually, the length of the message temporary storage queue is close to 0, resulting in extremely low memory consumption.

[0043] The message storage queue has a set cleanup cycle, which will clean up messages that have been stored for too long. The storage period can be adjusted according to actual conditions.

[0044] This message assurance mechanism is mainly aimed at resolving the problem of message loss when switching between different Brokers in a multi-Broker available environment, achieving message reliability without losing performance.

[0045] This embodiment also provides an MQTT client message assurance system under multiple Brokers, which includes an acquisition module, a creation module and an independent thread module.

[0046] The acquisition module is used to obtain an available Broker address and its related configuration information from the Broker address management platform.

[0047] The creation module is used to create a single-point MQTT client based on the address of the available Broker and its related configuration information, and establish a connection between the single-point MQTT client and the available Broker.

[0048] The independent thread module is used to use an independent thread to wait for the authentication result of the available Broker for the single-point MQTT client. When the authentication result is successful, it determines whether there are historical unverified business messages in the temporary storage queue of messages to be verified. If there are historical unverified business messages, it will take out the historical unverified business messages and send them to the available Broker. If there are no historical unverified business messages, it will wait for the new business messages from the MQTT client and send them to the available Broker. The message id of the new business message is used as the keyword to temporarily store it in the temporary storage queue of messages to be verified. When the authentication result is failed, the acquisition module will be called again.

[0049] The independent thread module is also used to use an independent thread to wait for the receipt of a sending completion callback notification containing a message id, and when received, clear the business message of the message id from the temporary storage queue of messages to be verified with the message id, and wait again for a new business message to be sent.

[0050] The independent thread module is also used to call the acquisition module if a network failure occurs during the waiting process using the independent thread.

[0051] The independent thread module is further used to use the independent thread to clear out the business messages whose temporary storage time in the temporary storage queue of the message to be verified reaches the set temporary storage time when a set cleaning cycle is reached.

[0052] Although specific embodiments of the present invention have been described above, those skilled in the art will appreciate that these are merely illustrative and that the scope of the present invention is defined by the appended claims. Those skilled in the art may make various changes or modifications to these embodiments without departing from the principles and essence of the present invention, and such changes and modifications are intended to fall within the scope of the present invention.

Claims

1. A method for guaranteeing MQTT client messages under multiple brokers, characterized in that: It includes the following steps: S1. Obtain an available Broker address and related configuration information from the Broker address management platform; S2. Based on the address of the available Broker and its related configuration information, a single-point MQTT client is created and a connection is established between the single-point MQTT client and the available Broker. S3. An independent thread waits for the authentication result of the available Broker to the single-point MQTT client. If the authentication result is successful, the process proceeds to step S4. If the authentication result is failed, the process repeats step S1. S4, the independent thread determines whether there is a historical unverified business message in the temporary storage queue of the message to be verified. If yes, it proceeds to step S5; if not, it proceeds to step S6; S5. The independent thread retrieves the historical unverified business message and sends it to the available Broker, and then proceeds to step S7. S6. The independent thread waits for the new business message from the MQTT client and sends it to the available Broker. The message ID of the new business message is used as a keyword and temporarily stored in the temporary storage queue for messages to be verified, and then proceeds to step S7. S7. The independent thread waits for a send completion callback notification containing the message ID, and upon receipt, clears the business message of the message ID from the temporary storage queue of messages to be verified with the message ID, and repeats step S6. In step S7, if the independent thread encounters a network failure while waiting for receipt, it proceeds to step S1.

2. The method for guaranteeing MQTT client messages under multiple brokers according to claim 1, wherein: After step S7, when a set clearing cycle is reached, the independent thread clears out the business messages whose temporary storage time in the temporary storage queue of the to-be-verified messages reaches the set temporary storage time.

3. A multi-Broker MQTT client message assurance system, characterized in that: It includes acquisition module, creation module and independent thread module; The acquisition module is used to obtain an available Broker address and related configuration information from the Broker address management platform; The creation module is used to create a single-point MQTT client based on the address of the available Broker and its related configuration information obtained and returned, and establish a connection between the single-point MQTT client and the available Broker; The independent thread module is used to use an independent thread to wait for the authentication result of the available Broker for the single-point MQTT client, and when the authentication result is successful, determine whether there is a historical unverified business message in the temporary storage queue of the message to be verified, and when there is a historical unverified business message, take out the historical unverified business message and send it to the available Broker, and when there is no historical unverified business message, wait for the new business message of the MQTT client and send it to the available Broker, and temporarily store the message ID of the new business message as a keyword in the temporary storage queue of the message to be verified, and call the acquisition module again when the authentication result is failed. The independent thread module is also used to use an independent thread to wait for a sending completion callback notification containing a message ID, and when received, clear the business message of the message ID from the temporary storage queue of messages to be verified with the message ID, and wait again for a new business message to be sent; The independent thread module is further configured to utilize the independent thread to call the acquisition module if a network failure occurs during the process of waiting for reception.

4. The multi-Broker MQTT client message assurance system according to claim 3, wherein: The independent thread module is further configured to utilize an independent thread to clear out service messages whose temporary storage time in the temporary storage queue of messages to be verified reaches a set temporary storage time when a set cleaning cycle is reached.

Images