A method of implementing an MQTT communication service

Abstract

The application provides a method for implementing MQTT communication service, comprising: each gateway sends a device information message to an MQTT server; the MQTT server verifies the device information messages sent by all the gateways, and after the verification is passed, generates network group information in combination with message content published by a user based on the MQTT protocol, and encapsulates the network group information in a network group configuration message and sends the network group configuration message to each gateway; each gateway analyzes the network group configuration message to determine whether it is a direct routing node or an intermediate routing node, and if so, forwards the network group configuration message to a source and / or target client through the MQTT protocol; and forwards a network group response message of the source and / or target client to the MQTT server; if the MQTT server receives the network group response message within a predetermined period, the MQTT server notifies network group through the MQTT protocol. The application can realize efficient message transmission and support cross-platform application of multiple platforms and multiple languages, and improves the transmission efficiency and convenience of network information.

Description

Technical Field

[0001] This invention relates to the field of communication network technology, and in particular to a method for implementing MQTT communication services. Background Technology

[0002] To meet the ever-increasing demands of the internet, the functions and technologies used are constantly evolving. The future internet belongs to IPv6, and VPN technology based on SRv6 combines the advantages of IPv6 and SR (Segment Routing). That is, using SRv6 as the data plane makes data transmission simpler, more efficient, and more flexible, completely replacing previously complex network protocols. It provides an important technical tool for building end-to-end networks, thus making SRv6 remote networking solutions more widely applicable and promoted.

[0003] However, in terms of communication implementation in SRV6 networking, the efficiency and convenience of network information transmission need further optimization, and cross-platform applications supporting multiple platforms and languages ​​are still lacking. Therefore, given the advantages of the MQTT protocol, such as efficient message passing and support for cross-platform applications supporting multiple platforms and languages, it is necessary to improve the existing communication methods in SRV6 networking. Summary of the Invention

[0004] The technical problem to be solved by the embodiments of the present invention is to provide a method for implementing MQTT communication service, which can achieve efficient message transmission and support cross-platform applications with multiple platforms and multiple languages, thereby improving the efficiency and convenience of network information transmission.

[0005] To address the aforementioned technical problems, embodiments of the present invention provide a method for implementing MQTT communication services, which is implemented on an MQTT server and multiple gateways interconnected with the MQTT server, wherein each gateway is connected to at least one client. The method includes the following steps:

[0006] Each gateway encapsulates its pre-stored device pre-shared key, its own device information, and the device information of each client it connects to in a device information message, and sends it to the MQTT server.

[0007] The MQTT server verifies all device information messages sent by the gateways. After verifying that the device information and pre-shared keys of each gateway and its connected clients are valid, the server generates network information by combining the message content published by the user based on the MQTT protocol. This network information is then encapsulated in a network configuration message and sent to each gateway. The network information includes the source client's device information, the target client's device information, and either the SRv6 BE scenario network mode or the SRv6 TE scenario network mode. The SRv6 BE scenario network mode is a VPN network mode with direct routing between the source client and the target client; the SRv6 TE scenario network mode is a VPN network mode where intermediate routing is required between the source client and the target client.

[0008] Each gateway parses the network configuration message to determine whether it is a direct routing node or an intermediate routing node. If it is determined to be a direct routing node or an intermediate routing node, it forwards the network configuration message to the source client and / or the target client via the MQTT protocol. Furthermore, upon receiving network response messages from the source client and / or the target client in response to the network configuration message, it forwards them to the MQTT server.

[0009] If the MQTT server receives network response messages from the source client and the target client within a predetermined time period, it notifies the source client, the target client, and the gateway acting as a direct or intermediate routing node via the MQTT protocol to establish a VPN communication tunnel based on the SRv6 BE scenario networking mode or the SRv6 TE scenario networking mode.

[0010] The method further includes:

[0011] The MQTT server sends link status messages to the source client and the target client based on a preset total number of transmissions and transmission interval to determine whether the link between the source client and the target client is connected.

[0012] The method further includes:

[0013] If the MQTT server receives at least one detection response message from the source client and the target client based on the link status message within the total number of transmissions, it determines that the link between the source client and the target client is connected.

[0014] The method further includes:

[0015] If the MQTT server does not receive a detection response message from either the source client or the target client based on the link status message within the total number of transmissions, it determines that the link between the source client and the target client is not connected.

[0016] The method further includes:

[0017] If the MQTT server determines that the network information contains an SRv6 TE scenario network mode, it needs to modify the original intermediate routing nodes in the network configuration message to update the routing path, and then resend the modified network configuration message to each gateway.

[0018] The total number of transmissions is 3; the transmission interval is 5 minutes.

[0019] The network configuration message includes the source client ID, the target client ID, SRH configuration parameters, and the target network segment.

[0020] Implementing the embodiments of the present invention has the following beneficial effects:

[0021] This invention is based on the MQTT protocol. It encapsulates the device's pre-shared key, its own device information, and the device information of each connected client in a device information message and sends it to the MQTT server through a gateway. After the MQTT server verifies the information, it generates a network configuration message based on the message content published by the user. This message is then forwarded to the source and target clients through each gateway. Upon receiving the network response message forwarded by the gateway, the network is notified to establish a VPN communication tunnel. This achieves efficient message transmission and supports cross-platform applications with multiple platforms and languages, improving the efficiency and convenience of network information transmission. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, obtaining other drawings based on these drawings without creative effort still falls within the scope of the present invention.

[0023] Figure 1 A flowchart illustrating a method for implementing MQTT communication service according to an embodiment of the present invention;

[0024] Figure 2 This is a connection topology diagram between an MQTT server, gateway, and client in a method for implementing MQTT communication services provided by an embodiment of the present invention.

[0025] Figure 3 This is a structural diagram of message types in a method for implementing MQTT communication service provided by an embodiment of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings.

[0027] like Figure 1 As shown in the illustration, this invention provides a method for implementing MQTT communication services. This method is implemented on an MQTT server and multiple gateways interconnected with the MQTT server, with each gateway connected to at least one client (e.g., ...). Figure 2 (as shown); at this time, the method includes the following steps:

[0028] Step S1: Each gateway encapsulates its pre-stored device pre-shared key, its own device information, and the device information of each client it connects to in a device information message and sends it to the MQTT server.

[0029] Step S2: The MQTT server verifies all device information messages sent by all gateways. After verifying that the device information and pre-shared keys of each gateway and its connected clients are valid, the server generates network information by combining the message content published by the user based on the MQTT protocol. This network information is then encapsulated in a network configuration message and sent to each gateway. The network information includes the source client's device information, the target client's device information, and either the SRv6 BE scenario network mode or the SRv6 TE scenario network mode. The SRv6 BE scenario network mode is a VPN network mode where the source client and the target client are directly routed; the SRv6 TE scenario network mode is a VPN network mode where the source client and the target client require intermediate routing.

[0030] Step S3: Each gateway parses the network configuration message to determine whether it is a direct routing node or an intermediate routing node. If it is determined to be a direct routing node or an intermediate routing node, it forwards the network configuration message to the source client and / or the target client via the MQTT protocol. And, when it receives the network response messages from the source client and / or the target client in response to the network configuration message, it forwards them to the MQTT server.

[0031] Step S4: If the MQTT server receives network response messages from the source client and the target client within a predetermined time period, it notifies the source client, the target client, and the gateway acting as a direct routing node or intermediate routing node through the MQTT protocol to establish a VPN communication tunnel based on the SRv6 BE scenario networking mode or the SRv6 TE scenario networking mode.

[0032] The specific process is as follows: In step S1, agent software is deployed on each gateway, which is mainly used for the management of router devices. It communicates with the MQTT server by using configuration command messages (which are MQTT messages that carry SRV6 configuration commands).

[0033] The core function of this agent software is to implement MQTT message encapsulation and parsing. Message parsing involves identifying the MQTT payload, enabling the SRV6 configuration commands in the payload to take effect, thereby realizing different application scenarios; message encapsulation involves carrying the device's own information and other content through the MQTT payload, allowing the MQTT server to recognize and utilize it.

[0034] At this point, the agent software comprises multiple functional modules, employing object-oriented design principles. Each module is abstracted into a class, with different classes possessing different functions to fulfill business function requirements. Specifically, it is divided into the following modules: central control module, connection control management module, network information management module, and network configuration management module.

[0035] (1) The main control module is the core of the gateway agent software: when the device starts, it will create instances of each sub-module based on the product ID, device name and device pre-shared key provided by the user, and realize functions such as connecting to the controller, processing received messages, obtaining network information and configuring SRv6 routing;

[0036] (2) The main functions of the connection control management module include establishing connections, subscribing to and publishing messages, processing messages, and disconnecting connections;

[0037] (3) The network information collection module is an important component of the gateway agent system. Its main responsibility is to collect network information from the local router. This information will be used for the configuration parameters of the SRv6 networking scheme.

[0038] (4) The network configuration management module is an important support for the gateway agent system. It uses the pyroute2 library in Python to implement the underlying network routing and establish routing policies.

[0039] The MQTT protocol enables efficient message passing and supports cross-platform applications across multiple platforms and languages. Therefore, the design and implementation of the communication protocol are based on the MQTT protocol. The core operation is to use the payload part of the MQTT message (which can transmit specific information) to carry various SRv6 configuration commands to form various messages, thereby realizing different application scenarios.

[0040] Therefore, each gateway pre-stores the device pre-shared key, its own device information, and the device information of each client it connects to. It encapsulates this information in a device information message and sends it to the MQTT server so that the MQTT server can recognize and utilize it.

[0041] In step S2, the MQTT server first verifies the device information messages sent by all gateways to verify whether the device information and device pre-shared key of each gateway and its connected clients are qualified, thus completing the communication tunnel initialization phase between the gateway and the MQTT server.

[0042] Secondly, after verifying that the device information and pre-shared keys of each gateway and its connected clients are valid, the MQTT server receives messages published by users using the MQTT protocol, specifying the content to be published. For example, users can fill in network information via a webpage, including the source client's device information, the target client's device information, and the SRv6 BE or SRv6 TE network mode. In the SRv6 BE network mode, the source and target clients are directly routed via VPN; in the SRv6 TE network mode, the source and target clients are routed via VPN through intermediate routes. It should be noted that the main difference between the SRv6 TE and SRv6 BE scenarios is that intermediate routing node information, in addition to the source and target clients, needs to be selected.

[0043] Finally, the MQTT server encapsulates the network topology information in a network configuration message and sends it to each gateway. This network configuration message includes the source client ID, the target client ID, SRH configuration parameters, and the target network segment.

[0044] In step S3, firstly, each gateway receives and parses the network configuration message sent by the MQTT server, and then uses the parsing result to further determine whether it is a direct routing node or an intermediate routing node.

[0045] Secondly, when one or more gateways determine that they are direct routing nodes or intermediate routing nodes, they forward network configuration messages to the source client and / or the target client via the MQTT protocol. For example, one gateway connects to the source client, and another gateway connects to the target client.

[0046] Subsequently, the gateway, acting as a direct or intermediate routing node, forwards the network response messages received from the source and / or target clients in response to the network configuration messages to the MQTT server.

[0047] In step S4, if the MQTT server receives network response messages from the source client and the target client within a predetermined time period (e.g., 5 seconds after sending the network configuration message), it notifies the source client, the target client, and the gateway acting as a direct or intermediate routing node via the MQTT protocol to establish a VPN communication tunnel based on the SRv6BE or SRv6 TE scenario networking mode. It is understood that the gateway, acting as a direct or intermediate routing node, will parse the network configuration message to determine the complete routing path between the source and target clients, thereby enabling cross-network segment VPN networking between them.

[0048] In this embodiment of the invention, it is necessary to detect whether the link between the source client and the target client is connected in order to determine whether the VPN network tunnel has been successfully established. Therefore, the method further includes: the MQTT server sending link status messages to the source client and the target client based on a preset total number of transmissions (e.g., 3 times) and a transmission interval (e.g., once every 5 minutes) to determine whether the link between the source client and the target client is connected.

[0049] For example, if the MQTT server receives at least one detection response message based on the link status message from both the source client and the target client within the total number of transmissions, it determines that the link between the source client and the target client is connected.

[0050] For example, if the MQTT server does not receive any detection response messages based on link state messages from either the source or target client within the total number of transmissions, it determines that the link between the source and target clients is disconnected. In this case, if the MQTT server determines that the network topology information contains an SRv6 TE scenario network mode, it needs to modify the intermediate routing nodes configured in the original network configuration message to update the routing path, and then resend the modified network configuration message to each gateway.

[0051] It is understandable that, such as Figure 3 As shown, the device information message is mainly used to carry the device's current network status information and is used for network formation; the network configuration message is mainly used to carry the device's network configuration information and is used for tunnel construction; and the link status message is mainly used for link connectivity testing.

[0052] Each message includes a `request_id` field that automatically increments from 0 to 999 and is used cyclically. When the `request_id` field of a network configuration message matches that of its corresponding network response message, it signifies confirmation of the network configuration message. Similarly, when the `request_id` field of a link status message matches that of its corresponding detection response message, it signifies confirmation of the link status message. In this case, both the network configuration message and the link status message are considered request messages, and both the network response message and the detection response message are considered response messages.

[0053] The MQTT server actively retrieves response messages every 0.5 seconds. A successful response is indicated by retrieving a message of the same response type and with the same request_id. If no response is found, the server waits for 1 second, resends the message, and actively retrieves the response again. If no response is received after three repetitions, the device is deemed to have encountered a message reporting failure, and the user is informed that the request delivery failed.

[0054] To facilitate successful message reception by both the sender and receiver, specific examples include Table 1 (request message header) and Table 2 (response message header), as follows:

[0055] Table 1

[0056]

[0057] Table 2

[0058]

[0059] At this point, the mapping between message operation type opcode and message type is shown in Table 3. The opcode value ranges from 0 to 99, providing an interface for subsequent message development.

[0060] Table 3

[0061] opcode Message type 1 Device information message 2 Network configuration message 3 Link state messages

[0062] In one example, taking the SRv6 BE scenario as an example, the working principle of a method for implementing MQTT communication service in an embodiment of the present invention is explained as follows:

[0063] In an SRv6 BE scenario, an SRV6 tunnel is directly constructed between the source client and the target client, which includes two phases: initialization and tunnel establishment.

[0064] Initialization Phase: The gateway first needs to establish a connection with the MQTT server. It needs to pre-store its device information (such as ID), client device information (such as device name), and pre-shared device keys to identify the specific device. The gateway then encapsulates this information into a device information message and sends it to the MQTT server. Upon receiving the message, the MQTT server parses it to obtain the specific device information, verifies the identity, and then proceeds with subsequent operations such as tunnel establishment.

[0065] Tunnel establishment phase: First, the user publishes a message to the MQTT server using the MQTT protocol, specifying the content and filling in network information including, but not limited to, selecting the source and target clients by device name, as well as the ingress and egress network cards, and selecting a specific establishment mode (such as BE Fast VPN mode). Second, after receiving the user message, the MQTT server encapsulates it into a network configuration message and sends the message to the source and target clients respectively through the gateway using the MQTT protocol. The source and target clients then return network response messages via the MQTT protocol. Finally, the MQTT server sends link status messages to the devices every 5 minutes. Upon receiving these messages, the source and target clients return detection response messages, allowing the MQTT server to determine that the VPN tunnel has been successfully established.

[0066] In another example, taking the SRv6 TE scenario as an example, the working principle of a method for implementing MQTT communication service in an embodiment of the present invention is explained as follows:

[0067] In SRv6 TE scenarios, it is necessary to solve the packet forwarding problem of intermediate routing nodes, especially the configuration of routing policies and path replacement, including the initialization and tunnel establishment phases.

[0068] Initialization Phase: The gateway first needs to establish a connection with the MQTT server. It needs to pre-store its device information (such as ID), client device information (such as device name), and pre-shared device keys to identify the specific device. The gateway then encapsulates this information into a device information message and sends it to the MQTT server. Upon receiving the message, the MQTT server parses it to obtain the specific device information, verifies the identity, and then proceeds with subsequent operations such as tunnel establishment.

[0069] Tunnel establishment phase: First, the user publishes a message to the MQTT server using the MQTT protocol, specifying the content and filling in network information including, but not limited to, selecting the source and target clients by device name, as well as the ingress and egress network cards, and selecting a specific establishment mode (such as BE Fast VPN mode). Second, after receiving the user message, the MQTT server encapsulates it into a network configuration message and sends the message to the source and target clients respectively through the gateway using the MQTT protocol. The source and target clients then return network response messages via the MQTT protocol. Finally, the MQTT server sends link status messages to the devices every 5 minutes. Upon receiving these messages, the source and target clients return detection response messages, allowing the MQTT server to determine if the VPN tunnel has been successfully established. Otherwise, it indicates that the VPN tunnel establishment has failed, and the intermediate routing nodes configured in the original network configuration message need to be adjusted to update the routing path and re-establish the VPN tunnel.

[0070] Implementing the embodiments of the present invention has the following beneficial effects:

[0071] This invention is based on the MQTT protocol. It encapsulates the device's pre-shared key, its own device information, and the device information of each connected client in a device information message and sends it to the MQTT server through a gateway. After the MQTT server verifies the information, it generates a network configuration message based on the message content published by the user. This message is then forwarded to the source and target clients through each gateway. Upon receiving the network response message forwarded by the gateway, the network is notified to establish a VPN communication tunnel. This achieves efficient message transmission and supports cross-platform applications with multiple platforms and languages, improving the efficiency and convenience of network information transmission.

[0072] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as ROM / RAM, disk, optical disk, etc.

[0073] The above description discloses only preferred embodiments of the present invention and should not be construed as limiting the scope of the present invention. Therefore, equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A method of implementing an MQTT communication service, characterized by, It is implemented on an MQTT server and a plurality of gateways interconnected with the MQTT server, and each gateway is connected with at least one client, and the method comprises the following steps: Each gateway encapsulates the pre-stored device pre-shared key, its own device information and the device information of each client connected thereto in a device information message and sends it to the MQTT server; The MQTT server verifies all the device information messages sent by the gateways, and after verifying that the device information and the device pre-shared key of each gateway and its connected clients are qualified, generates network configuration information in combination with the message content published by the user based on the MQTT protocol, encapsulates the network configuration information in a network configuration message and further sends it to each gateway; wherein the network configuration information comprises the device information of the source client, the device information of the target client, the SRv6 BE scenario network configuration mode or the SRv6 TE scenario network configuration mode; the SRv6 BE scenario network configuration mode is a VPN network configuration mode in which the source client and the target client are directly routed; the SRv6 TE scenario network configuration mode is a VPN network configuration mode in which the source client and the target client need to be routed through an intermediate node; Each gateway parses the network configuration message to determine whether it is a direct routing node or an intermediate routing node, and when it is determined to be a direct routing node or an intermediate routing node, it forwards the network configuration message to the source client and / or the target client through the MQTT protocol; and when it receives the network response message fed back by the source client and / or the target client to the network configuration message, it forwards it to the MQTT server; If the MQTT server receives the network response message fed back by the source client and the target client within a predetermined period of time, it notifies the source client, the target client and the gateway as the direct routing node or the intermediate routing node to configure the network based on the SRv6 BE scenario network configuration mode or the SRv6 TE scenario network configuration mode to establish a VPN communication tunnel.

2. The method of implementing an MQTT communication service as claimed in claim 1, wherein, The method further comprises: The MQTT server sends a link state message to the source client and the target client based on the preset total number of transmissions and transmission interval to determine whether the link between the source client and the target client is connected.

3. The method of implementing an MQTT communication service as claimed in claim 2, wherein, The method further comprises: If the MQTT server receives the detection response message fed back by the source client and the target client based on the link state message at least once within the total number of transmissions, it is determined that the link between the source client and the target client is connected.

4. The method of implementing an MQTT communication service as claimed in claim 2, wherein, If the MQTT server does not receive the detection response message fed back by the source client and the target client based on the link state message at least once within the total number of transmissions, it is determined that the link between the source client and the target client is not connected. The method further comprises:

5. The method of implementing an MQTT communication service as claimed in claim 4, wherein, ​ If the MQTT server judges that the networking information contains an SRv6 TE scenario networking mode, the original intermediate routing node in the networking configuration message needs to be modified to update the routing path, and the modified networking configuration message is re-sent to each gateway.

6. The method of implementing an MQTT communication service according to any one of claims 2 to 5, characterized in that, The total number of sending is 3 times; the sending interval time is every 5 minutes.

7. The method of implementing an MQTT communication service as claimed in claim 1, wherein, The networking configuration message includes the source client ID, the target client ID, SRH configuration parameters, and a target network segment.

Images