A MQTT-based device connection method, device, apparatus and medium

Abstract

The application discloses an MQTT-based device connection method and device, equipment and medium, relates to the technical field of Internet communication, and the method is applied to a device end and comprises the following steps: loading device identity configuration information; adopting a hierarchical domain name system resolution strategy to resolve access point information and acquiring a target connection address; initiating an MQTT connection request and completing authentication through an encrypted channel; if the connection fails, switching to a standby access point to repeat the resolution and connection processes; after the connection is established, directing message transmission based on a set topic format, realizing request and response interaction through a message association mechanism, and completing timeout control by using an MQTT delay message. The scheme improves the device connection speed, stability and interaction reliability, guarantees communication safety, and adapts to the multi-scene requirements of Internet of Things.

Description

Technical Field

[0001] This application relates to the field of Internet communication technology, and in particular to a device connection method, apparatus, device and medium based on MQTT. Background Technology

[0002] With the popularization of IoT technology, NAS devices, smart home devices and other terminals need to perform high-frequency command interaction and data transmission with the cloud and mobile applications, which puts forward stringent requirements on connection speed, reliability, security and interaction efficiency.

[0003] In related technologies, when designing IoT device connection system solutions, HTTP / HTTPS polling requires repeated establishment of TCP / TLS connections, resulting in high handshake overhead and poor real-time performance. Long polling consumes a large amount of server resources and is difficult to adapt to high-frequency, low-latency scenarios. Although the standard MQTT protocol is based on long connections and has a small header, it lacks a built-in request-response (RPC) mechanism, preventing the sender from quickly obtaining the receiver's processing results. Relying solely on TLS encryption at the transport layer makes it vulnerable to man-in-the-middle attacks or client forgery, resulting in insufficient security. Furthermore, in complex network environments such as DNS hijacking and slow resolution, connection establishment is slow, and the lack of an automatic backup link switching mechanism leads to poor stability. These problems result in long device connection times, low interaction efficiency, and high communication risks, failing to meet the core requirements of millisecond-level connection, highly reliable interaction, and secure transmission for IoT devices. Therefore, an optimized MQTT connection technology is urgently needed to overcome these bottlenecks. Summary of the Invention

[0004] This application provides a device connection method, apparatus, device, and medium based on MQTT. The device loads identity configuration information, obtains the target connection address through hierarchical DNS resolution with native priority and system fallback, initiates an MQTT connection, and authenticates through an encrypted channel. If the connection fails, it automatically switches to a backup access point for retry. Upon successful connection, it sends messages based on a topic containing the target identifier, realizes request-response interaction by using message identifiers and concurrent security mapping, and completes timeout control using delayed messages, thereby achieving fast, stable, and secure device connection and interaction.

[0005] In a first aspect, embodiments of this application provide a device connection method based on MQTT, the method comprising:

[0006] Load device identity configuration information;

[0007] Based on the device identity configuration information, the device access point interface is resolved using the native domain name system, and the domain name of the device access point information is queried. If the resolution is successful, the optimal public IP address is returned as the target connection address of the MQTT proxy server; if the resolution fails, the device access point interface is resolved using the system-level domain name system, and the system-level IP address is returned as the target connection address of the MQTT proxy server.

[0008] Initiate an MQTT connection request based on the target connection address, and complete identity authentication and connection establishment with the application through an encrypted channel;

[0009] Upon successful authentication and connection establishment, messages are transmitted to the application based on the topic format set by MQTT. During the transmission of these messages, a message identifier is generated for each request message, and a concurrent and secure mapping relationship is established between the message identifier and the asynchronous channel. The interaction between requests and responses is then implemented based on this secure mapping relationship. When sending a request message, a timeout trigger message for the message identifier is published to the MQTT broker server, and timeout control operations are performed based on the timeout trigger message.

[0010] Furthermore, the device identity configuration information includes device identifier, certificate, private key, and device access point information;

[0011] The process of resolving the domain name of the device access point interface and querying the device access point information through the native domain name system, and returning the optimal public IP address as the target connection address for the MQTT proxy server if the resolution is successful, includes:

[0012] The native domain name system is invoked to resolve the device access point interface, and a query command is sent to the pre-configured domain name system server for the domain name of the device access point information;

[0013] If the native domain name system resolution is successful, the public IP list is obtained based on the query command, and the optimal IP is selected as the target connection address of the MQTT proxy server according to the public IP list.

[0014] The step of resolving the device access point interface using the system-level domain name system and returning the system-level IP as the target connection address of the MQTT proxy server includes:

[0015] If the native domain name system resolution fails, the system-level domain name system is called to resolve the device access point interface, and a fallback query is performed on the domain name of the device access point information. If the system-level domain name system resolution succeeds, the system-level IP returned by the system is used as the target connection address of the MQTT proxy server.

[0016] If both the native domain name system and the system-level domain name system fail to resolve, the process will fall back to using the original domain name of the device access point information as the target connection address of the MQTT proxy server.

[0017] Furthermore, the targeted message delivery to the application based on the topic format set by MQTT includes:

[0018] Define a topic format that includes a target identifier, wherein the topic format includes a device identifier and a target identifier field;

[0019] The request message is sent to the topic format containing the target party identifier, so that the application subscribes to the topic format containing the target party identifier, thereby achieving targeted delivery of the request message.

[0020] Further, the step of generating a message identifier for each request message, establishing a concurrent and secure mapping relationship between the message identifier and the asynchronous channel, and implementing request and response interaction based on the secure mapping relationship includes:

[0021] A message identifier is generated for each request message, and a concurrent and secure mapping relationship between the message identifier and the asynchronous channel is established and stored. The message identifier is carried in the message payload, which is a structured data carrier containing request instructions, business data and the message identifier.

[0022] The concurrent security mapping relationship is updated in real time, and after sending a request message, the system blocks and waits for the response message from the asynchronous channel.

[0023] Upon receiving the response message sent by the application, the concurrent security mapping relationship is looked up based on the message identifier in the response message to obtain the response data and release the blocking state of the asynchronous channel.

[0024] Further, the step of publishing a timeout trigger message with the message identifier to the MQTT broker server when sending a request message, and performing timeout control operations based on the timeout trigger message, includes:

[0025] When sending a request message, a timeout trigger message is published to the delay topic of the MQTT broker server. The timeout trigger message carries the message identifier corresponding to the request message, and the delay time of the timeout trigger message is a preset timeout threshold.

[0026] If no response message is received for the request message within the timeout threshold, the timeout trigger message is triggered, and the mapping entry corresponding to the message identifier of the request message in the concurrency security mapping relationship is deleted accordingly. A timeout error is then returned through the asynchronous channel corresponding to the request message.

[0027] If a response message is received in response to the request message within the timeout threshold, the mapping entry corresponding to the message identifier carried in the response message in the concurrent security mapping relationship is deleted, and the response data in the response message is processed normally.

[0028] Furthermore, the process of authenticating the user's identity and establishing a connection through an encrypted channel includes:

[0029] Construct a transport layer encrypted channel based on transport layer security protocols;

[0030] A preset encryption algorithm is used to hash and sign the message payload, generating signature information, which is then carried in the user attribute field of the MQTT message.

[0031] The MQTT message carrying the signature information is sent to the application through the transport layer encryption channel, so that the application can extract the signature information from the user attribute field of the MQTT message;

[0032] The application verifies the validity of the signature information using a pre-set public key. If the verification passes, the sender's identity is confirmed as legitimate and the request message is received. The message payload is extracted based on the request message. If the verification fails, the sender's identity is determined to be illegitimate and the request message is discarded.

[0033] Furthermore, after initiating an MQTT connection request based on the target connection address and completing authentication and connection establishment with the application through an encrypted channel, the process also includes:

[0034] If the connection fails to be established, switch to the backup device access point and repeat the hierarchical domain name system resolution process and the MQTT connection request process until the connection with the application is established.

[0035] The switching to the backup device access point includes:

[0036] According to the list of pre-stored backup device access points, if the connection fails, other backup device access points are selected in the order of the list for reconnection;

[0037] Repeat the hierarchical domain name system resolution and MQTT connection request process for each backup device access point until the connection is successful or all backup device access points in the list are traversed.

[0038] If all the device access points in the list fail to connect, the device will enter a sleep state and retry, and then re-initiate the MQTT connection request after a preset time interval.

[0039] In a second aspect, embodiments of this application provide an MQTT-based device connection apparatus, comprising:

[0040] The configuration loading module is used to load device identity configuration information;

[0041] The domain name resolution module is used to resolve the domain name of the device access point interface and query the device access point information through the native domain name system based on the device identity configuration information. If the resolution is successful, it returns the optimal public IP as the target connection address of the MQTT proxy server; if the resolution fails, it uses the system-level domain name system to resolve the device access point interface and returns the system-level IP as the target connection address of the MQTT proxy server.

[0042] The connection establishment module is used to initiate an MQTT connection request based on the target connection address, and complete the identity authentication and connection establishment with the application through an encrypted channel.

[0043] The communication interaction module is used to transmit messages to the application based on the topic format set by MQTT after successful authentication and connection establishment. During the transmission of messages, a message identifier is generated for each request message, and a concurrent and secure mapping relationship between the message identifier and the asynchronous channel is established. The interaction between requests and responses is realized based on the secure mapping relationship. When sending a request message, a timeout trigger message of the message identifier is published to the MQTT broker server, and timeout control operations are performed based on the timeout trigger message.

[0044] In a third aspect, embodiments of this application provide an electronic device, including: a memory and one or more processors;

[0045] The memory is used to store one or more programs;

[0046] When the one or more programs are executed by the one or more processors, the one or more processors implement the MQTT-based device connection method as described in the first aspect.

[0047] In a fourth aspect, embodiments of this application provide a storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform the MQTT-based device connection method as described in the first aspect.

[0048] This application's embodiments employ a tiered DNS resolution strategy, prioritizing queries to highly available DNS servers via native interfaces. If these queries fail, the system resolves the connection, ultimately falling back to the original domain name. This bypasses DNS cache pollution and hijacking, reducing resolution time. Combined with establishing connections directly using IP addresses, it solves the slow connection establishment problem of traditional solutions, achieving millisecond-level connection speeds. Because a pre-defined list of backup device access points is provided, automatic switching and repetition of the resolution and connection process occur upon connection failure. Coupled with a sleep retry mechanism, this ensures that devices can quickly restore connections even in complex network environments, improving connection stability and avoiding disconnection issues caused by single access point failures. Furthermore, by defining a topic format containing target identifiers, targeted message delivery is achieved. An asynchronous-to-synchronous RPC mechanism is constructed using message identifiers and a concurrent security mapping table, enabling blocking on the device side. The method addresses the lack of RPC functionality in standard MQTT, allowing upper-layer applications to initiate remote requests as if calling local functions, thus improving development efficiency. By constructing an encrypted transmission channel through TLS and employing the Ed25519 / RSA algorithm to sign the message payload and embed it into MQTT user attribute fields, a double security protection is formed. Even if TLS is cracked, message tampering and identity forgery can be prevented, ensuring communication security. Furthermore, by utilizing MQTT delayed messages for timeout control, a delay timeout signal is simultaneously published when sending a request, and resources are automatically cleaned up if a response is not received on time, preventing memory leaks and further improving interaction reliability. In summary, this method simultaneously achieves fast device connection, efficient interaction, secure communication, and stable operation, adapting to the multi-scenario application needs of IoT devices. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating a device connection method based on MQTT provided in an embodiment of this application;

[0050] Figure 2 This is a flowchart of the native Domain Name System (DNS) resolution device access point interface provided in this application embodiment;

[0051] Figure 3 This is a flowchart of the system-level domain name system resolution device access point interface provided in the embodiments of this application;

[0052] Figure 4 This is a flowchart illustrating the topic-based directed message delivery provided in this application embodiment;

[0053] Figure 5 This is a flowchart of the message identifier and asynchronous channel synchronization mechanism provided in the embodiments of this application;

[0054] Figure 6 This is a flowchart of the MQTT broker server delay timeout control provided in the embodiments of this application;

[0055] Figure 7 This is a flowchart illustrating the two-layer signature security provided in this application embodiment;

[0056] Figure 8 This is a flowchart of the primary / standby switchover retry provided in the embodiments of this application;

[0057] Figure 9 This is a structural diagram of a device connection device based on MQTT provided in an embodiment of this application;

[0058] Figure 10 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but additional steps not included in the drawings may also be present. The above processes can correspond to methods, functions, procedures, subroutines, subroutines, etc.

[0060] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0061] This application relates to the field of Internet communication technology and is applicable to remote communication between devices and the cloud and mobile applications in Internet of Things (IoT) scenarios, including but not limited to network storage (NAS) devices, smart home devices, industrial control devices, etc. By optimizing the connection process, strengthening security protection, and improving interaction reliability, it meets the communication requirements of high frequency, low latency, high security, and high stability.

[0062] Figure 1 This is a flowchart illustrating a device connection method based on MQTT provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The device connection method of this application includes steps such as configuration loading, hierarchical DNS resolution, connection establishment, directed communication and timeout control, forming a complete closed loop of configuration, resolution, connection and interaction, specifically including:

[0063] Step 101: Load device identity configuration information.

[0064] In one embodiment, the device loads pre-stored device identity configuration information first upon startup. Optionally, the device identity configuration information is stored in an encrypted file system, such as flash memory or EEPROM, including the device identifier (DeviceId), digital certificate (Cert), private key, and device access point information (initial access point domain name, port, and list of backup access points). All information is stored encrypted to prevent leakage and tampering. When the device-side dedicated communication service (MQTT Agent) starts, it decrypts and reads the configuration information through a hardware encryption module, verifying the certificate validity period, private key integrity, and access point information legality, such as domain name format and port range. If verification fails, an alarm is triggered and the process is terminated, ensuring the configuration information is legal and valid. After successful loading, the configuration information is cached in memory to avoid repeated reading of the encrypted file system, improving process execution efficiency, and supporting dynamic configuration updates via cloud push updates. Encrypted storage and verification ensure the security of device identity configuration information, memory caching improves execution efficiency, and dynamic updates support flexible configuration, solving the problems of easy leakage of device configuration information, low loading efficiency, and cumbersome updates.

[0065] Step 102: Based on the device identity configuration information, resolve the device access point interface and query the domain name of the device access point information through the native domain name system. If the resolution is successful, return the optimal public IP as the target connection address of the MQTT proxy server; if the resolution fails, use the system-level domain name system to resolve the device access point interface and return the system-level IP as the target connection address of the MQTT proxy server.

[0066] Among them, the native domain name system is an independent DNS resolution module built into the device firmware. It does not rely on the operating system's libc resolution library. The native domain name system directly constructs DNS query messages and initiates queries to the pre-configured high-availability DNS server through UDP port 53. The resolution result directly returns a list of IPs. The system-level domain name system is a DNS resolution module that comes with the device's operating system. As a fallback solution for the native DNS resolution, it uses the default DNS server configured in the device's current network (which is assigned by the operator or manually configured) and supports local DNS cache reuse.

[0067] In one embodiment, based on device access point information, a hierarchical strategy of prioritizing native DNS resolution, using system-based resolution as a fallback, and domain name fallback is employed to obtain the target connection address of the MQTT proxy server, thus avoiding DNS hijacking and slow resolution issues. Optionally, native Domain Name System (DNS) resolution (Inborn Lookup) resolves the device access point interface by calling the native resolution interface (DNSLookupInborn) of the DNS resolution module. The native resolution interface can bypass the system libc resolver and directly initiate a UDP query to a pre-configured high-availability DNS server, such as 114.114.114.114 or 8.8.8.8. If the resolution is successful, a list of public IP addresses is obtained, and the optimal public IP address is used as the target connection address of the MQTT proxy server. Obtaining the optimal public IP address involves sending ICMP packets to each IP address in the list, calculating the round-trip time (RTT) and packet loss rate, and selecting the optimal IP address based on the rules of minimum RTT, minimum packet loss rate, and ISP matching priority. The Host field in the connection configuration is then replaced with this IP address, eliminating the DNS query overhead of subsequent TCP handshakes. If the resolution fails, the system-level resolution process is initiated.

[0068] In one embodiment, the System Lookup DNS resolution calls the System Lookup DNS resolution interface to resolve the device access point interface. It uses the system's default DNS server, such as the DNS server assigned by the ISP, for the query. If the resolution is successful, the IP address returned by the system is used as the target connection address for the MQTT proxy server. If the System Lookup also fails, it falls back to using the original device access point's domain name as the target connection address for the MQTT proxy server, handing the resolution work over to the underlying MQTT network library. This tiered resolution strategy bypasses DNS cache pollution and hijacking, directly obtaining the public IP address through native resolution to improve connection speed, and multi-level fallback ensures a high success rate, solving the problems of slow DNS resolution, susceptibility to hijacking, and poor reliability.

[0069] Step 103: Initiate an MQTT connection request based on the target connection address, and complete identity authentication and connection establishment with the application through an encrypted channel.

[0070] The target connection address is the network identifier used by the device to establish a network connection with the MQTT broker server, which is used to specify the target endpoint for data transmission.

[0071] In one embodiment, after obtaining the target connection address, the MQTT Agent initiates an MQTT connection request based on the target connection address, and completes authentication by establishing an encrypted channel to ensure a secure and reliable connection. Optionally, during the connection initiation phase, the device-side MQTT client carries the device identifier and certificate, initiates a TCP connection to the target connection address, and negotiates the MQTT protocol version (supporting 3.1.1 / 5.0), heartbeat parameters, and connection timeout. After the TCP connection is established, the client establishes a transport layer encrypted channel based on the TLS 1.3 protocol, exchanges certificates with the server, and verifies their legitimacy (certificate signature, validity period, domain name matching). If the verification is successful, a session key is negotiated using the ECDH algorithm (updated periodically, 30 minutes by default), and a transport layer encrypted channel is established to prevent data transmission from being eavesdropped on or tampered with; if the verification fails, the TCP connection is closed and an error log is recorded.

[0072] In one embodiment, the device signs the connection request using its private key (using the Ed25519 or RSA algorithm), embeds the signature information (including Key ID, signature value, and client identifier) ​​into the User Properties field of MQTT v5.0, and sends it to the application along with the device identifier. The application verifies the signature validity using a pre-configured device public key. If verification is successful, the identity is confirmed as legitimate, and a connection is established; if verification fails, the connection is rejected and a security log is logged. The TLS 1.3 encrypted channel ensures transmission security, application-layer signing and transport-layer encryption form a double protection, two-way authentication prevents unauthorized device access, and standardized MQTT connection parameters adapt to different servers, solving the problems of weak connection security and lack of authentication.

[0073] Step 104: If the identity authentication and connection establishment are successful, send messages to the application based on the topic format set by MQTT. During the message sending process, a message identifier is generated for each request message, and a concurrent security mapping relationship between the message identifier and the asynchronous channel is established. The interaction between requests and responses is realized based on the security mapping relationship. When sending a request message, a timeout trigger message of the message identifier is published to the MQTT broker server, and timeout control operations are performed based on the timeout trigger message.

[0074] The topic format is "MASTER_TOPIC / p2p / [sender identifier]@@@[destination identifier]" in the MQTT topic specification, where "MASTER_TOPIC" is a globally unified prefix and "@@@" is a special separator (ASCII code 0xE20x80). The sender and receiver identifiers are 1-32 character strings (including letters, numbers, and underscores) with a width of 0x8B (zero-width separator), ensuring the subject conforms to the MQTT protocol specification and enabling targeted message delivery. The message identifier (MsgId) is a globally unique identifier generated for each request message. It is a 64-bit integer generated using an atomic incrementing counter and snowflake algorithm, with the structure "1 sign bit + 41-bit timestamp + 10-bit worker node bits (device identifier hash + thread ID) + 12-bit sequence number", ensuring absolute uniqueness within a single machine and used to associate request and response messages. The concurrency safety mapping relationship is based on the association between message identifiers and asynchronous channels established by the thread-safe data structure (Go language sync.Map), supporting concurrent execution of storage, reading, and deletion operations by multiple threads / coroutines. The asynchronous channel is used as a communication carrier to transmit response data or timeout errors. Each request message corresponds to an independent channel with a buffer size of 1, ensuring immediate data transmission and supporting blocking wait and wake-up mechanisms to realize the conversion of asynchronous communication to synchronous RPC.

[0075] In one embodiment, after the connection is established, messages are delivered in a targeted manner based on a defined topic format, and reliable interaction is achieved through message identifier mapping and timeout control. Optionally, a topic format containing a target identifier (MASTER_TOPIC + " / p2p / consumerId@@@TARGET_ID") is defined. The sender (device) publishes the request message to the corresponding topic, and the application subscribes to the dedicated topic (containing its own ID) to achieve targeted reception, avoiding resource waste caused by message broadcasting.

[0076] In one embodiment, during the RPC interaction implementation phase, a unique message identifier (MsgId) is generated for each request message. This is achieved using an atomic incrementing counter and a snowflake algorithm. A composite key strategy of target device ID + MsgId is used to ensure that even if different business threads generate the same MsgId, they remain independent entries in the mapping table due to different target devices, thus avoiding conflicts. A concurrent and safe mapping relationship between the message identifier and the asynchronous channel is established (based on Go's sync.Map, supporting lock-free concurrent read and write). After the sender publishes a request message, it blocks and waits for the asynchronous channel's response. Upon receiving the message, the application parses the request instructions and business data, executes corresponding business processing (such as data storage and device control), and encapsulates the business result and the original MsgId into a response message, which is then published to the sender's dedicated response topic. Upon receiving the response, the sender looks up the mapping relationship using the MsgId, obtains the corresponding asynchronous channel, writes the response data, and unblocks, completing the RPC interaction.

[0077] In one embodiment, when sending a request, a timeout trigger message is published to the $delayed topic of the MQTT broker server (delay time = RPC timeout threshold, default 10 seconds). If no response is received within the timeout threshold, the MQTT broker server triggers a timeout message and sends it to the response topic. After receiving the message, the sender calls the LoadAndDelete atomic operation to delete the entry corresponding to the MsgId from the mapping table and returns a timeout error through an asynchronous channel to prevent memory leaks. If a response is received normally within the timeout threshold, the mapping table entry is deleted in advance. Subsequent timeout messages are ignored because the corresponding entry cannot be found, thus avoiding side effects. Targeted topics enable precise message delivery, the RPC mechanism solves the shortcomings of asynchronous interaction in MQTT, concurrent and safe mapping supports high-concurrency scenarios, and timeout control ensures resource release, thus improving overall interaction reliability and efficiency and solving problems such as weak interaction, lack of timeout management, and memory leak risks.

[0078] The device connection method of this application covers the entire process of configuration loading, hierarchical parsing, encrypted connection, and targeted interaction. Through multi-level fallback and dual security protection, it solves the problems of slow connection, weak security, and chaotic interaction. At the same time, it achieves millisecond-level connection establishment and high-concurrency reliable interaction, adapts to multiple IoT scenarios, and improves the efficiency and stability of device communication.

[0079] Figure 2 This is a flowchart of the native Domain Name System (DNS) resolution device access point interface provided in this application embodiment. Please refer to [link / reference]. Figure 2 The native DNS resolution process is the core of the hierarchical resolution strategy. By directly querying highly available DNS servers, it improves resolution speed and accuracy. Specifically, it includes:

[0080] Step 201: Call the native domain name system to resolve the device access point interface, and send a query command to the preset domain name system server for the domain name of the device access point information.

[0081] In one embodiment, the device can bypass the system resolver and directly send a query to the pre-configured server by calling the DNSLookupInborn interface of the native domain name system's DNS resolution module. This interface does not rely on the system libc resolution library and directly constructs DNS query messages (query type A / AAAA records), supporting IPv4 / IPv6 dual-stack resolution.

[0082] In one embodiment, the server is randomly selected from a pre-configured list of highly available DNS servers (supporting 114.114.114.114, 8.8.8.8, 223.5.5.5, etc.). A query message is sent via UDP protocol (port 53) with a timeout of 3 seconds. If no response is received within the timeout period, the system switches to the next server, attempting a maximum of 3 servers. If all 3 servers fail to respond, the native DNS resolution is considered to have failed, triggering a fallback system resolution process. This bypasses the system resolver to avoid cache pollution, uses multiple servers for retries to improve resolution success rate, and utilizes the UDP protocol to reduce transmission overhead, addressing the slow and easily polluted resolution issues of traditional systems.

[0083] Step 202: If the native domain name system resolution is successful, obtain the public IP list based on the query command, and select the optimal IP as the target connection address of the MQTT proxy server according to the public IP list.

[0084] In one embodiment, if the native Domain Name System (DNS) resolves the IP address successfully, a list of public IP addresses is obtained, and the optimal IP address is selected as the target connection address through network quality testing. Optionally, a DNS server response message is received, all associated public IP addresses are resolved, duplicate IPs are removed, and a list of available IP addresses (supporting a mixed IPv4 / IPv6 list) is formed.

[0085] In one embodiment, three ICMP probe packets are sent to each IP to measure round-trip time (RTT) and packet loss rate. The detection time per IP should not exceed one second to avoid excessive time consumption. The IPs are sorted in ascending order of latency, descending order of packet loss rate, and prioritizing carrier matching. The IP ranked first is selected as the target connection address for the MQTT proxy server. If all IPs have similar latency (difference ≤ 50ms), the IP with the same network carrier as the device is prioritized as the target connection address for the MQTT proxy server to improve connection stability. Network quality testing ensures the selection of the optimal IP, and carrier matching improves connection stability, avoiding slow connections and frequent interruptions caused by blind selection, further optimizing connection speed.

[0086] Native Domain Name System (DNS) resolution bypasses the system resolver and directly connects to a highly available DNS server. By using multi-node retries and network quality filtering to select the optimal IP, it avoids DNS hijacking and cache pollution, improves resolution speed, and saves the DNS query overhead for TCP handshakes, which is the foundation for achieving fast connections.

[0087] Figure 3 This is a flowchart of the system-level domain name system resolution device access point interface provided in this application embodiment. Please refer to [link / reference]. Figure 3 The system-level DNS resolution process, as a fallback solution for native DNS resolution, ensures that the resolution process is not interrupted. Specifically, it includes:

[0088] Step 2011: If the native domain name system resolution fails, the system-level domain name system is called to resolve the device access point interface, and a downgrade query is performed on the domain name of the device access point information.

[0089] In one embodiment, after the native DNS resolution module fails, the system-level DNS resolution calls the system-level DNS resolution interface for a fallback query. Optionally, relying on operating system resolution libraries, such as Linux glibc or Windows dnsapi.dll, the DNSLookup system interface is called, using the device access point domain name, with the query type consistent with native resolution (A / AAAA record), and a query timeout of 5 seconds is set, allowing the system to use the local DNS cache. If the system returns a list of valid IPs (non-empty and in a valid format), the IP filtering process begins; if it returns an empty list or an incorrect format, such as a domain name not existing, the system-level DNS resolution is deemed to have failed, triggering domain name fallback logic. Relying on the system resolution library ensures compatibility, and a longer timeout improves the query success rate, serving as a fallback solution to ensure the resolution process is not interrupted and addressing the problem of having no alternative solution after native resolution failure.

[0090] Step 2012: If the system-level domain name resolution is successful, then the system-level IP returned by the successful resolution shall be used as the target connection address of the MQTT proxy server.

[0091] In one embodiment, if the system-level domain name system (DNS) resolution is successful, the selected IP address is chosen as the target connection address for the MQTT proxy server. Optionally, consistent with the IP selection rules of native DNS resolution, network quality is detected through ICMP probes, and the optimal IP address is selected as the target connection address to ensure consistent connection quality.

[0092] In one embodiment, if system-level DNS resolution fails (no valid IP address), the device sets the target connection address to the original access point domain name. Subsequent DNS resolution is handled automatically by the underlying MQTT network library, such as by calling system resolution or third-party resolution libraries, thus preventing a complete interruption of the resolution process. Regardless of resolution success or failure, the reason for the failure is recorded, such as DNS server unresponsiveness, domain name non-existence, and number of attempts. This information is then logged to the cloud to facilitate network troubleshooting by operations and maintenance personnel. Unified IP filtering rules ensure connection quality, a domain name fallback mechanism prevents resolution interruption, and status reporting improves operational convenience, resolving the issue of direct connection loss after resolution failure.

[0093] As a fallback solution for native DNS resolution, it reuses IP filtering logic to ensure connection quality and falls back to the original domain name to avoid process interruption when resolution fails; it effectively copes with resolution anomalies in complex network environments, improves resolution success rate, and ensures the continuity of connection process.

[0094] Figure 4 This is a flowchart illustrating the topic-based directed message delivery based on MQTT settings, as provided in this application embodiment. Please refer to [link / reference]. Figure 4 The implementation process of targeted message delivery, through defining a standardized topic format, achieves precise message delivery, specifically including:

[0095] Step 301: Define a topic format containing the target identifier, wherein the topic format includes a device identifier and a target identifier field.

[0096] In one embodiment, a topic format including a target identifier is designed, clearly defining the composition and meaning of fields to ensure consistency between the device and the application. Optionally, the topic format is "MASTER_TOPIC / p2p / [sender identifier]@@@[target identifier]", where MASTER_TOPIC is a globally unified prefix, such as "iot / devices", the sender identifier is a unique ID of the device / application, the target identifier is a unique ID of the receiver, and "@@@" is a dedicated separator to avoid identifier confusion. Identifiers can contain letters, numbers, and underscores.

[0097] In one embodiment, the sender identifier and destination identifier are limited to 1-32 characters in length, and the MASTER_TOPIC is limited to 1-64 characters in length, ensuring that the topic conforms to the MQTT protocol specification (maximum length 65535 characters). Both the device and application sides have built-in topic format validation logic. Before sending a message, the integrity of the topic fields is checked (whether they contain delimiters, whether the identifiers are empty). If the format does not conform, the message is rejected and an error log is recorded to avoid invalid message delivery. Standardized topic format ensures compatibility between the two parties, clear field division enables accurate routing, and format validation avoids message delivery errors, solving the problems of message broadcasting and delivery chaos.

[0098] Step 302: Send the request message to the topic format containing the target party identifier, so that the application subscribes to the topic format containing the target party identifier, thereby realizing the targeted delivery of the request message.

[0099] In one embodiment, the device sends messages according to a topic format, and the application subscribes to a dedicated topic to achieve targeted interaction. Optionally, the device generates a request message (including instructions, business data, and MsgId), concatenates the topic with the target identifier, such as "iot / devices / p2p / Device001@@@CloudService001", publishes the message through an MQTT client, and sets the QoS level to 1 (ensuring the message is delivered at least once) to avoid message loss. When the application starts, it subscribes to a topic containing its own identifier, such as "iot / devices / p2p / +@@@CloudService001", where "+" is a single-level wildcard in MQTT. It only receives messages with its own target identifier, filtering out irrelevant messages and reducing resource consumption. After receiving the message, the MQTT broker server, such as EMQX, parses the target identifier in the topic and accurately forwards the message to the application that subscribed to the topic through a topic routing mechanism, without pushing it to other devices, thus saving bandwidth resources. QoS levels ensure reliable message delivery, dedicated subscriptions filter irrelevant messages, and proxy servers enable precise message routing, achieving targeted message delivery, improving communication efficiency and security, and solving the problems of message overload and wasted bandwidth.

[0100] Messages are delivered precisely by using topic formats that include target identifiers, avoiding resource waste caused by broadcasting. Applications subscribe to dedicated topics to filter irrelevant messages, reducing invalid data processing and improving communication efficiency and data security.

[0101] Figure 5 This is a flowchart of the message identifier and asynchronous channel synchronization mechanism provided in the embodiments of this application. Please refer to [link / reference]. Figure 5 The mapping and interaction mechanism between message identifiers and asynchronous channels is the core of realizing synchronous RPC interaction, and specifically includes:

[0102] Step 401: Generate a message identifier for each request message, establish and store the concurrent security mapping relationship between the message identifier and the asynchronous channel, wherein the message identifier is carried in the message payload, and the message payload is a structured data carrier containing request instructions, business data and the message identifier.

[0103] In one embodiment, a unique identifier is generated for each request message, a concurrent security mapping relationship is established, and the identifier is stored. Optionally, the identifier generation uses an atomic incrementing counter and a snowflake algorithm to generate a 64-bit MsgId (structure: "1 sign bit + 41-bit timestamp (millisecond level) + 10-bit worker node bit (device identifier hash + thread ID) + 12-bit serial number") to ensure uniqueness within a single machine; the key of the concurrent security mapping relationship uses a composite key "TargetPeerId:MsgId" (format: "CloudService001:1234512345123451234") to avoid MsgId conflicts between different target devices. An independent asynchronous channel is created for each request to transmit response data or timeout errors. The channel is set to a buffer size of 1 to ensure timely data delivery. The Go standard library's `sync.Map` is used as the storage medium. Internally, it implements a read-write separation mechanism, supporting multiple goroutines to perform `Store`, `Load`, and `Delete` operations simultaneously. This eliminates the need for additional mutex locks in the business layer, avoiding lock contention bottlenecks under high concurrency and ensuring nanosecond-level operation performance. Composite keys prevent identifier conflicts, `sync.Map` ensures concurrency safety, and atomic increment and snowflake algorithms ensure identifier uniqueness, resolving issues of identifier duplication and concurrency conflicts.

[0104] Step 402: Update the concurrent security mapping relationship in real time, and block and wait for the response message from the asynchronous channel after sending the request message.

[0105] In one embodiment, after the message is sent, the business layer blocks and waits for a response from the asynchronous channel, achieving a synchronous call experience. Optionally, the device-side MQTT client publishes a message carrying the MsgId to the target topic. After successful publication, the current business thread is blocked (through Goroutine blocking or thread suspension) to wait for channel data. An independent coroutine is started to monitor the blocking time. If the timeout exceeds a preset timeout threshold (default 10 seconds, configurable), a timeout error (error code Timeout_001, description "request timed out") is written to the channel to unblock and avoid infinite waiting.

[0106] In one embodiment, the channel status (waiting for response / responded / timeout) is recorded in a mapping table to facilitate subsequent troubleshooting, such as querying the MsgId of unresponsive requests through logs. Blocking waiting provides a synchronous RPC experience, while independent coroutines monitor timeouts, preventing business threads from blocking and freezing, thus solving the problem of traditional MQTT asynchronous interactions failing to synchronously obtain results.

[0107] Step 403: After receiving the response message sent by the application, look up the concurrent security mapping relationship based on the message identifier in the response message, obtain the response data, and release the blocking state of the asynchronous channel.

[0108] In one embodiment, after receiving a message, the application processes the business logic and returns a response carrying the original MsgId. Optionally, the application subscribes to a dedicated topic, and upon receiving a request message, extracts the MsgId, instructions, and business data, verifies message integrity (e.g., by checking a CRC32 checksum to prevent message tampering or incompleteness). Based on the instructions, it executes the corresponding business logic (e.g., data storage, device control, parameter query) and generates a processing result. If processing fails, it records error information, such as business logic exception or invalid parameters. The processing result (success / failure identifier, business data / error information) and the original MsgId are encapsulated into a response message, and the response topic is constructed using the format "MASTER_TOPIC / p2p / [application identifier]@@@[device identifier]", and published to the MQTT broker server. Message integrity verification ensures data reliability, separation of business processing and response encapsulation improves scalability, and carrying the original identifier in the response topic ensures accurate association, resolving the issue of incompatible responses and requests.

[0109] In one embodiment, the device subscribes to its own dedicated response topic (e.g., "iot / devices / p2p / CloudService001@@@Device001") and extracts the MsgId and processing result after receiving the response message. It then searches the sync.Map using the composite key "device identifier: MsgId" to obtain the corresponding asynchronous channel. If not found, the message is considered timed out or invalid. If the MsgId is incorrect or the response delay is too long, the message is discarded and logged. The processing result is written to the channel, waking up the blocked business thread and simultaneously invoking the LoadAndDelete atomic operation. This retrieves the channel object and physically removes the entry from the Map, preventing memory leaks and ensuring each request is processed only once. The dedicated response topic ensures accurate message reception, the composite key lookup improves association efficiency, and the atomic operation releases resources to avoid memory leaks, achieving a complete closed loop for requests and responses and solving the problems of lost responses and wasted resources.

[0110] The composite key strategy avoids MsgId conflicts, and sync.Map supports lock-free concurrent read and write, enabling asynchronous-to-synchronous interaction; it solves the defect of no response feedback in traditional MQTT asynchronous communication, supports tens of thousands of concurrent requests without blocking, and ensures the orderliness and reliability of interaction.

[0111] Figure 6 This is a flowchart illustrating the MQTT broker server latency and timeout control provided in this application embodiment. Please refer to [link / reference]. Figure 6The timeout control process based on MQTT delayed topics is a key mechanism to prevent resource leaks, specifically including:

[0112] Step 501: When sending a request message, publish a timeout trigger message to the delay topic of the MQTT broker server. The timeout trigger message carries the message identifier corresponding to the request message, and the delay time of the timeout trigger message is a preset timeout threshold.

[0113] In one embodiment, when the device sends a request message, it simultaneously publishes a timeout trigger message to the MQTT broker server's delay topic. Optionally, the delay topic adopts the format "$delayed / [timeout] / [response topic]", where the timeout is a preset threshold, such as 10 seconds, consistent with the RPC timeout threshold, and the response topic is the device's dedicated response topic, such as "iot / devices / p2p / CloudService001@@@Device001". The timeout trigger message is in JSON format, carrying the corresponding MsgId, trigger type (timeout), and sending timestamp. The publication of the business request message and the timeout trigger message are atomic operations (ensured by transactions or synchronization locks), ensuring that both either succeed simultaneously or fail simultaneously, avoiding logical inconsistencies. For example, if the business message is successfully sent but the timeout message is not published, the timeout will not trigger. Atomic operations ensure logical consistency, the standardized delay topic format is compatible with MQTT broker servers such as EMQX and Mosquitto, and the timeout trigger message carries key identifiers for easy association, solving the problem of timeout control and business message asynchrony.

[0114] Step 502: If no response message is received for the request message within the timeout threshold, the timeout trigger message is triggered, the mapping entry corresponding to the message identifier of the request message in the concurrent security mapping relationship is deleted accordingly, and a timeout error is returned through the asynchronous channel corresponding to the request message.

[0115] In one embodiment, if no business response message is received within a timeout period, a delayed message is triggered, and the device cleans up the concurrent security mapping relationship and returns a timeout error. Optionally, after a preset timeout period, the MQTT broker forwards the timeout trigger message to the device's response topic, such as "iot / devices / p2p / CloudService001@@@Device001". After receiving the message, the device identifies it as a timeout message through the "type: timeout" field, extracts the MsgId, and ignores other irrelevant messages.

[0116] In one embodiment, the `sync.Map` is searched based on `MsgId`, and the corresponding mapping entry is deleted (if it exists) using the `Delete` operation. A timeout error is written to the corresponding asynchronous channel, waking up the blocked business thread and ensuring resource release. Timeout events (`MsgId`, timeout duration, trigger time, current network status) are recorded for subsequent analysis of network latency or slow application processing. Delay topics enable precise timeout triggering, resource cleanup prevents memory leaks, and timeout logs facilitate troubleshooting, resolving issues of no timeout handling or untimely handling.

[0117] Step 503: If a response message is received in response to the request message within the timeout threshold, delete the mapping entry in the concurrent security mapping relationship corresponding to the message identifier carried in the response message, and process the response data in the response message normally.

[0118] In one embodiment, if a business response message is received before the timeout, the device ignores subsequent timeout messages. Optionally, after receiving a business response message, the device follows the process to look up the mapping, write the result, delete the entry, and unblock, ensuring normal business processing. When a subsequent timeout trigger message with the corresponding MsgId is received, if the corresponding entry is not found in sync.Map, it is determined to be a "processed timeout message" and discarded directly without any side effects, such as returning errors repeatedly. The message filtering mechanism avoids duplicate processing, ensures that timeout control does not affect the normal response process, improves system robustness, and resolves the conflict between timeout messages and normal responses.

[0119] By utilizing delayed topics to achieve automatic timeout triggering, and through a mapping entry cleanup mechanism to prevent memory leaks, the timeout response time is precisely controlled within a preset threshold, avoiding long-term resource occupation and improving the long-term stability and resource utilization of the system.

[0120] Figure 7 This is a flowchart illustrating the two-layer signature security provided in this application embodiment. Please refer to [link / reference]. Figure 7 A two-layer security mechanism of transport layer encryption and application layer signature comprehensively protects communication security, specifically including:

[0121] Step 601: Construct a transport layer encrypted channel based on the transport layer security protocol.

[0122] In one embodiment, an encrypted channel is built based on the TLS 1.3 protocol to ensure security during data transmission. Optionally, after the TCP connection is established, the device and the MQTT broker / application negotiate the TLS version (preferably TLS 1.3, but compatible with TLS 1.2) and the encryption suite, such as TLS_AES_256_GCM_SHA384, prioritizing suites with high security and performance. Both parties exchange digital certificates (X.509 v3 format). The device verifies the signing authority, validity period, and domain name matching of the server certificate, while the server / application verifies the legitimacy of the device certificate, rejecting invalid or forged certificates, such as self-signed certificates not on the trust list.

[0123] In one embodiment, a session key is negotiated using the ECDH (Elliptic Curve Diffie-Hellman) algorithm for subsequent encrypted data transmission. The key is updated periodically (every 30 minutes by default) to reduce the risk of key leakage. During transmission, AEAD (Authorized Encryption) mode is used to ensure data confidentiality and integrity. The TLS 1.3 protocol balances security and performance, with strong encryption suites ensuring data confidentiality, certificate verification preventing man-in-the-middle attacks, and periodic session key updates enhancing security, thus addressing the weaknesses in traditional transport layer security.

[0124] Step 602: Use a preset encryption algorithm to hash and sign the message payload, generate signature information, and carry the signature information in the user attribute field of the MQTT message.

[0125] In one embodiment, the device uses a preset algorithm to sign the message payload and embeds the signature information into the user attribute field of the MQTT message. Optionally, the algorithm supports two algorithms: Ed25519 (performance priority) and RSA (compatibility priority). The device defaults to loading the Ed25519 algorithm (LoadX25519Secure) and can switch to RSA-2048 / 4096 through configuration. Ed25519 is suitable for embedded devices with limited computing power, such as low-end NAS, IoT gateways, or high-frequency communication scenarios. It offers fast signing / verification speed (tens of times faster than RSA), a signature length of only 64 bytes, reduced network transmission overhead, and natural resistance to side-channel attacks. RSA is suitable for devices that need to interface with older systems or have hardware-integrated RSA hardware acceleration engines. It has comprehensive industry standard support and relatively fast verification speed, but signature generation is time-consuming (high concurrency under software decoding may cause a surge in CPU utilization).

[0126] In one embodiment, the message payload (including instructions, business data, and MsgId) is hashed (Ed25519 with SHA-512, RSA with SHA-256), and the hash value is signed using the device's private key to generate Base64 encoded signature information. The signature information (Key ID, Base64 encoded signature value, device identifier) ​​is encapsulated as a key-value pair and stored in the User Properties field of MQTT v5.0, with the key being "sign," without affecting the message payload structure. The dual algorithms adapt to different scenarios: SHA-512 / SHA-256 hashing improves collision resistance, Base64 encoding ensures signature transmission compatibility, and the User Properties field does not affect the message payload, solving the problem of application-layer lack of signatures and difficulty in identity verification.

[0127] Step 603: Send the MQTT message carrying the signature information to the application through the transport layer encryption channel, so that the application can extract the signature information from the user attribute field of the MQTT message.

[0128] In one embodiment, the device sends messages through an encrypted channel, ensuring dual security for both transmission and content. Optionally, the message payload (JSON format) and User Properties (including signature information) are encapsulated into an MQTT message, with a QoS level (default 1) and a retention flag (default no retention) set to prevent message duplication or residue. Messages are sent to the application via a TLS encrypted channel. Data transmission is encrypted during transmission, and even if the channel is compromised, the signature still ensures the message has not been tampered with and the sender's identity is legitimate. The system waits for a publication confirmation (QoS level 1) from the MQTT broker server to confirm successful message delivery. If no confirmation is received, the system retryes (default 3 retries, 1-second intervals) to ensure reliable message delivery. QoS level guarantees message delivery, encrypted channels and application-layer signatures provide dual protection, and the retry mechanism improves transmission reliability, addressing the issues of message loss and tampering.

[0129] Step 604: The application verifies the validity of the signature information using a preset public key. If the verification is successful, the sender's identity is confirmed as legitimate and the request message is received. The message payload is extracted based on the request message. If the verification fails, the sender's identity is determined to be illegitimate and the request message is discarded.

[0130] In one embodiment, the application extracts signature information to verify validity and processes only legitimate messages. Optionally, after receiving an MQTT message, the application extracts the signature information corresponding to the "sign" key from the User Properties field, parsing out the KeyID, signature value, and client identifier. Based on the Key ID, it retrieves the corresponding device public key (pre-registered and stored, supporting dynamic updates) from the public key store. If the Key ID does not exist, the message is deemed invalid and discarded. The message payload undergoes the same hash calculation (consistent with the device-side algorithm), and the signature value is verified using the public key. If verification passes, the message is confirmed to be complete and the sender's identity is legitimate, proceeding to the business processing flow. If verification fails, such as a hash value mismatch or an invalid signature, the message is discarded, and a security alert is recorded (including the sender identifier, message content digest, and reason for failure). Centralized management of the public key store improves maintenance efficiency, signature verification ensures message integrity and identity legitimacy, and security alerts facilitate timely detection of attacks, addressing the lack of content security verification.

[0131] TLS transmission encryption and application layer signature provide dual protection, supporting Ed25519 / RSA dual algorithms to adapt to different scenarios; effectively resisting man-in-the-middle attacks and data tampering, ensuring accurate identity authentication, and guaranteeing the security of the entire device communication chain.

[0132] Figure 8 This is a flowchart of the primary / standby switchover retry provided in the embodiments of this application. Please refer to it. Figure 8 The primary / backup failover and retry process after connection failure improves connection stability in complex network environments, specifically including:

[0133] Step 701: Based on the list of pre-stored backup device access points, if the connection fails, select other backup device access points in the order of the list to reconnect.

[0134] In one embodiment, when the current device access point fails to connect, the next backup device access point is selected according to the pre-stored list. Optionally, connection timeout (exceeding 15 seconds), TLS handshake failure, authentication failure, MQTT protocol negotiation failure, etc., are all considered connection failures, and the reason for failure and the number of failures are recorded. The backup device access point list (pre-stored in an encrypted file system, supporting dynamic updates) is read from the device configuration. The list contains the domain name, port, and priority of multiple access points, sorted in descending order of priority (default is the configuration order). The next untried device access point is selected according to the list order. If the current device access point is the last one, the loop continues to the first one (maximum loop 3 times) to avoid infinite loop attempts. Multi-scenario failure judgment ensures no omissions, priority sorting ensures the use of high-quality device access points first, and loop attempts improve the connection success rate, solving the problem of no backup device access point.

[0135] Step 702: Repeat the hierarchical domain name system resolution and MQTT connection request process for each backup device access point until the connection is successful or all backup device access points in the list are traversed.

[0136] In one embodiment, the hierarchical DNS resolution and MQTT connection process is repeated for the selected backup device access point. Optionally, for the domain name of the backup device access point, the target connection address of the MQTT proxy server is obtained according to the hierarchical DNS resolution strategy (native resolution → system resolution → domain name fallback), ensuring that the backup connection also receives DNS acceleration, rather than a simple retrieval. Based on the new target connection address, the connection establishment and authentication process is repeated, using the same device identity configuration information, without the need to reload the configuration. If the backup device access point connection also fails, the failure information (access point domain name, target IP, failure reason) is recorded, and the next backup device access point is selected until the connection is successful or all backup device access points are traversed. This reuses existing resolution and connection logic, reduces development complexity, ensures the connection quality of backup device access points, and solves the problem of non-optimized resolution after switching backup device access points.

[0137] Step 703: If all the device access points in the list fail to connect, then enter sleep mode and retry, and re-initiate the MQTT connection request after a preset interval.

[0138] In one embodiment, if all backup device access points fail to connect, a hibernation and retry process is initiated to avoid frequent retries consuming resources. Optionally, an exponential backoff algorithm is used to calculate the hibernation time, with an initial hibernation time of 5 seconds, doubling after each retry (5 seconds, 10 seconds, 20 seconds, ...), and a maximum hibernation time of 300 seconds (5 minutes) to avoid infinite waiting. The device enters a hibernation state, suspending connection attempts. During this period, some non-essential modules, such as the network detection module, are shut down to reduce CPU and network resource consumption, maintaining only the core processes running.

[0139] In one embodiment, after the hibernation period ends, the connection attempt is restarted from the initial device access point, repeating the primary / backup switchover, hierarchical resolution, and connection process until the connection is successful or the maximum number of retries (default 10) is reached. After reaching the maximum number of retries, the device enters a low-power standby state, periodically (every 30 minutes) to retry, and triggers an alarm (indicator light flashing, log reporting). The exponential backoff algorithm avoids resource waste, the maximum hibernation time prevents infinite waiting, and the cyclic retries ensure eventual connection success, solving the resource exhaustion problem caused by frequent retries.

[0140] Automatically switching to backup access points based on priority, hierarchical resolution process reuse to ensure connection quality, exponential backoff and hibernation to avoid resource waste, and addressing access point failures and network fluctuations, thereby improving connection recovery success rate and enhancing the system's fault tolerance.

[0141] Figure 9 This is a structural diagram of a device connection apparatus based on MQTT provided in an embodiment of this application. Please refer to [link / reference]. Figure 9 The functional modules of the device connection apparatus of this application include a configuration loading module 801, a domain name resolution module 802, a connection establishment module 803, and a communication interaction module 804. These modules work together to achieve complete connection and interaction functions, specifically including:

[0142] The configuration loading module 801 is used to load and verify device identity configuration information, providing data for subsequent processes. It reads configuration information from encrypted storage media, verifies the integrity and legitimacy of the configuration, caches it in memory, and supports dynamic configuration updates.

[0143] The configuration reading unit reads configuration data from encrypted storage media (flash memory / EEPROM) via a hardware driver interface (SPI / I2C), supporting multiple storage formats (JSON / binary). The configuration verification unit verifies the uniqueness of the device identifier, certificate format and validity period, private key and certificate matching, and access point information legitimacy (domain name format, port range). Verification failure triggers an alarm. The configuration caching unit caches legitimate configuration information in memory (supporting LRU eviction to avoid memory overflow), provides a fast read interface, and supports dynamic configuration updates (receiving configuration update commands pushed from the cloud, verifying signatures, and updating the cache and storage). Multiple storage media adapt to different devices, verification ensures configuration security, memory caching improves access efficiency, and dynamic updates support flexible configuration adjustments, solving the problems of single configuration loading and lack of verification.

[0144] The domain name resolution module 802 is used to implement a hierarchical DNS resolution strategy to obtain the optimal target connection address. Optionally, it can filter the optimal IP and record the resolution status by performing native DNS resolution, system-level DNS resolution, and domain name fallback.

[0145] The native resolution unit implements the DNSLookupInborn interface, initiating queries to pre-configured high-availability DNS servers, handling IP list filtering and optimal IP selection, and supporting IPv4 / IPv6 dual-stack. The system resolution unit calls the system DNS interface, handling fallback queries and result judgment, reusing IP filtering logic. The fallback processing unit, when both native and system resolution fail, falls back to the original domain name, records the reason for failure, and reports it. The resolution log unit records the resolution process (DNS servers attempted, resolution results, IP filtering data, and reasons for failure), and the log supports local storage and cloud reporting. Tiered resolution improves resolution speed and reliability, resolution logs facilitate operation and maintenance, fallback processing ensures process continuity, and solves the problem of a single resolution strategy.

[0146] The connection establishment module 803 is used to initiate an MQTT connection, build an encrypted channel, and complete authentication. Optionally, it initiates a TCP / MQTT connection, negotiates connection parameters, builds a TLS encrypted channel, performs two-way authentication, and handles connection failures.

[0147] The connection initiation unit creates an MQTT client instance, configures the protocol version, heartbeat parameters, and timeout, and initiates a TCP connection and MQTT CONNECT request to the target connection address. The encryption channel unit initializes the TLS context, negotiates the TLS version and cipher suite, verifies certificate validity, negotiates the session key, and builds an encrypted channel. The authentication unit generates application-layer signature information, embeds it into the User Properties field of the MQTT message, receives and verifies the authentication response from the server / application, and handles authentication failures, such as retries and switching access points. The connection monitoring unit monitors the connection status in real time, detects connection drops, and triggers a reconnection process if the heartbeat times out. This standardized connection process adapts to different MQTT servers, strong encryption and authentication ensure connection security, and connection monitoring enables automatic reconnection after a disconnection, resolving issues of connection instability and weak security.

[0148] The communication interaction module 804 is used to implement targeted message passing, RPC interaction, and timeout control to ensure reliable and efficient interaction. Optionally, it constructs targeted topics, generates MsgId and concurrent security mappings, handles request / response interactions, and executes timeout control.

[0149] The topic management unit defines and validates topic formats, generates request / response topics, and manages subscription relationships, such as subscribing to dedicated response topics. The RPC interaction unit generates a unique MsgId (atomic increment + snowflake algorithm), establishes a concurrent safety mapping (sync.Map), and implements asynchronous-to-synchronous interaction (blocking wait - response wake-up). The timeout control unit publishes timeout trigger messages, handles timeout events (cleaning up mappings, returning errors), and filters invalid timeout messages. The message processing unit receives response messages, extracts the MsgId and result, finds the mapping relationship, wakes up the business thread, and cleans up resources. Topic management ensures targeted message delivery, the RPC interaction unit addresses the asynchronous limitations of MQTT, the timeout control unit prevents resource leaks, and the message processing unit ensures accurate result feedback, thus improving the overall reliability and efficiency of interaction.

[0150] Each module has a clear division of labor and a loosely coupled design, supporting independent updates and extensions. Configuration loading ensures information security, domain name resolution improves connection speed, connection establishment strengthens security protection, communication interaction ensures reliable interaction, and collaboration enables efficient and stable device connection.

[0151] Figure 10 This is a structural diagram of an electronic device provided in an embodiment of this application. Please refer to it. Figure 10The hardware structure of the electronic device described in this application, which can integrate the MQTT-based device connection device of this application, ensures efficient system operation through the collaborative work of hardware components, specifically including:

[0152] The electronic device includes a processor 901, a memory 902, an input device 903, an output device 904, and a communication module (integrating network communication and MQTT communication functions). All components are connected via industrial-grade buses, such as PCIe, USB 3.0, and SPI, to achieve data transmission and command interaction.

[0153] Processor 901 is used to run software programs and modules in memory 902, coordinate the work of various hardware components, and realize MQTT-based device connection functions. Optionally, an appropriate processor is selected according to the device type. On the device side, such as NAS and IoT gateway, a high-performance multi-core CPU, such as Intel Core i5 / i7, AMD Ryzen 5 / 7, ARM Cortex-A53 / A72, is used to support multi-threaded concurrent processing and meet the high-performance requirements of parsing, encoding, encryption, and instruction execution. Cloud servers use server-grade CPUs, such as Intel Xeon and AMD EPYC, with ≥16 cores and a main frequency ≥2.4GHz, supporting millions of concurrent device access and data relay.

[0154] It runs software programs for configuration loading, domain name resolution, connection establishment, and communication interaction, and controls the collaborative work of various modules. For example, it coordinates the data flow transmission between the configuration loading module and the memory, schedules the network connection and data transmission and reception of the communication module, and allocates hardware resources, such as GPU for TLS acceleration and encryption module for signature / verification acceleration, to ensure that the various functions of the system are implemented efficiently and collaboratively.

[0155] It supports hardware acceleration technology. On the device side, GPUs, such as NVIDIA CUDA and AMD OpenCL, are used to accelerate TLS encryption and decryption, video encoding and decoding, and reduce CPU utilization. On the server side, network card multi-queue and hardware interrupt balancing technologies are used to improve network data processing efficiency. On the device side, DSPs (Digital Signal Processors) are used to accelerate speech recognition and noise filtering (if voice control is involved), improving processing speed and accuracy. Differentiated processor selection adapts to different device requirements, multi-threading and hardware acceleration ensure high-performance system operation, and resource scheduling optimization improves component collaboration efficiency, solving the problems of insufficient hardware performance and unreasonable resource allocation in traditional devices.

[0156] The memory 902 is used to store software programs, configuration information, cached data, log data, etc., providing data support for the processor 901 and functional modules. Optionally, an appropriate memory is configured according to the device type. For devices, RAM ≥ 4GB (high-speed DDR4 / DDR5), SSD ≥ 128GB, or flash memory ≥ 32GB are configured to ensure the storage and fast access requirements of configuration information, cached data, and software programs; for servers, RAM ≥ 64GB and SSD ≥ 2TB are configured to meet the needs of large amounts of session data, data stream caching, and log storage.

[0157] The storage is divided into a system area (storing the operating system and core software), an application area (storing the storage device connection program), a cache area (storing DNS resolution results, concurrent mapping tables, and message cache), a log area (storing connection logs, interaction logs, and error logs), and a configuration area (storing the storage device identity configuration information and a list of backup access points). This partitioned management improves the orderliness and security of storage and avoids interference between different types of data.

[0158] It supports encrypted data storage, such as SSD hardware encryption and software AES-256 encryption, protecting configuration information, log data, and cached sensitive data from unauthorized access. It also supports data backup and recovery functions, automatically backing up critical configurations and log data periodically to prevent data loss. The server adopts a distributed storage architecture to ensure high availability of session data and data streams. Large-capacity, high-speed storage meets the storage needs of different devices, partition management improves storage orderliness, encryption and backup ensure data security, and distributed storage enhances server data availability, solving the problems of insufficient storage and lack of data security in traditional devices.

[0159] Input device 903 is used to receive user input or external configuration data and provide a parameter configuration interface for device connection. Optionally, the device-side input device includes buttons, a touch screen, a USB interface, and a network interface. Users can configure access point information, timeout thresholds, and other parameters through buttons or the touch screen, import certificates and private keys through the USB interface, and receive configuration update commands pushed from the cloud through the network interface.

[0160] Server input devices include a keyboard, mouse, and remote management terminal, such as an SSH client. Administrators can configure server parameters, such as the maximum number of concurrent connections, latency topic prefix, log storage policy, monitor server operating status, and troubleshoot problems through the remote management terminal.

[0161] It receives user-input parameters, such as access point domain name, port, and timeout, converts them into electrical signals recognizable by the device, and transmits them to the processor 901 to update the configuration. It supports parameter verification, such as port range 1-65535 and timeout ≥ 1 second, to prevent illegal input from causing system anomalies. Diverse input methods adapt to different configuration scenarios, parameter verification ensures configuration legitimacy, and configuration updates are convenient and flexible, solving the problems of traditional devices having limited configuration methods and complex operations.

[0162] Output device 904 is used to output device operating status, configuration information, and alarm information, providing users with visual feedback. Optionally, the device-side output device includes indicator lights, a display screen, a buzzer, and a network interface. The indicator lights are used to display the connection status (solid green light = normal connection, solid red light = connection failure, flashing yellow light = retrying), the display screen is used to display configuration information, parsing results, and log summaries, the buzzer is used for alarms, such as sounding when authentication fails or configuration is abnormal, and the network interface is used to report operating status and logs to the cloud.

[0163] The server output devices include a monitor, indicator lights, and a log server interface. The monitor displays the server operation monitoring interface (CPU / memory usage, concurrent connections, data transfer rate), the indicator lights display the server operating status (power light, network light, fault light), and the log server interface synchronizes logs to a dedicated log server for centralized management and analysis.

[0164] It outputs real-time device operating status (parsing status, connection status, interaction status), configuration information (device identifier, access point address, timeout threshold), and alarm information (failure reason, error code), facilitating user viewing and troubleshooting. It supports alarm tiering (general alarms = log notifications, critical alarms = indicator lights + buzzers + cloud reporting), improving fault response efficiency. Multiple output formats meet diverse feedback needs; real-time status display facilitates monitoring; and the alarm mechanism promptly alerts to anomalies, solving the problems of opaque device status and difficult fault diagnosis inherent in traditional devices.

[0165] Differentiated hardware selection adapts to terminals and servers, large-capacity high-speed storage ensures data security, diversified inputs and outputs facilitate configuration and monitoring, hardware acceleration technology reduces CPU utilization, distributed storage improves server availability, and provides stable hardware support for device connectivity.

[0166] In one embodiment, the computer-readable storage medium provided in this application adopts a high-speed Flash memory, SSD, or cloud storage medium with a capacity of ≥32GB (device-side) or ≥2TB (server), supports a wide operating temperature range of -40℃ to 85℃ (industrial-grade scenarios), and has characteristics such as power failure prevention, electromagnetic interference resistance, and high durability (flash memory ≥100,000 erase and write cycles). The storage medium stores computer-readable instructions, which are organized in a modular structure and include execution code for core functions such as configuration loading, domain name resolution, connection establishment, communication interaction, and security protection. At the same time, it stores basic data such as system configuration parameters, instruction mapping library, device identification information, session token, and log template.

[0167] When the processor executes the above instructions, it starts the corresponding functional module according to the device type (device / server). Optionally, the device-side initialization configuration loading module loads and verifies the device identity configuration information; the domain name resolution module starts, performs hierarchical DNS resolution to obtain the target connection address; the connection establishment module starts, initiates an MQTT connection and authenticates through a two-layer security mechanism; the communication interaction module starts, transmits messages based on targeted topics, achieves synchronous interaction through the RPC mechanism, and uses delayed messages to complete timeout control; if the connection fails, it initiates the primary / backup switchover and sleep retry process to ensure connection stability.

[0168] The server-side initializes the session management module to maintain device connection status and session association; it starts the data relay module to forward messages (business messages, timeout trigger messages) between the device and the application; it starts the command routing module to accurately forward response messages based on MsgId and device identifier; and it starts the log module to record device connection, interaction, and error logs, supporting log querying and export. This storage medium supports hot-swapping (device-side) and online expansion (server-side) to adapt to deployment needs of different scales; encrypted storage and backup mechanisms ensure data security and prevent leakage and loss; it is compatible with multiple operating systems such as Windows, Linux, Android, iOS, and VxWorks, and can be directly deployed on various electronic devices without additional driver installation, effectively supporting the stable implementation of MQTT-based device connection functions and improving device deployment flexibility and maintenance convenience.

[0169] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments provided herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A method for connecting devices based on MQTT, characterized in that, The method includes: Load device identity configuration information; Based on the device identity configuration information, the device access point interface is resolved using the native domain name system, and the domain name of the device access point information is queried. If the resolution is successful, the optimal public IP address is returned as the target connection address of the MQTT proxy server; if the resolution fails, the device access point interface is resolved using the system-level domain name system, and the system-level IP address is returned as the target connection address of the MQTT proxy server. Initiate an MQTT connection request based on the target connection address, and complete identity authentication and connection establishment with the application through an encrypted channel; Upon successful authentication and connection establishment, messages are transmitted to the application based on the topic format set by MQTT. During the transmission of these messages, a message identifier is generated for each request message, and a concurrent and secure mapping relationship is established between the message identifier and the asynchronous channel. The interaction between requests and responses is then implemented based on this secure mapping relationship. When sending a request message, a timeout trigger message for the message identifier is published to the MQTT broker server, and timeout control operations are performed based on the timeout trigger message.

2. The device connection method based on MQTT according to claim 1, characterized in that, The device identity configuration information includes the device identifier, certificate, private key, and device access point information; The process of resolving the domain name of the device access point interface and querying the device access point information through the native domain name system, and returning the optimal public IP address as the target connection address for the MQTT proxy server if the resolution is successful, includes: The native domain name system is invoked to resolve the device access point interface, and a query command is sent to the pre-configured domain name system server for the domain name of the device access point information; If the native domain name system resolution is successful, the public IP list is obtained based on the query command, and the optimal IP is selected as the target connection address of the MQTT proxy server according to the public IP list. The step of resolving the device access point interface using the system-level domain name system and returning the system-level IP as the target connection address of the MQTT proxy server includes: If the native domain name system fails to resolve, the system-level domain name system is invoked to resolve the device access point interface, and a downgrade query is performed on the domain name of the device access point information; If the system-level domain name is successfully resolved, the system-level IP returned by the system will be used as the target connection address of the MQTT proxy server. If both the native domain name system and the system-level domain name system fail to resolve, the process will fall back to using the original domain name of the device access point information as the target connection address of the MQTT proxy server.

3. The device connection method based on MQTT according to claim 1, characterized in that, The method of sending messages to the application based on the topic format set by MQTT includes: Define a topic format that includes a target identifier, wherein the topic format includes a device identifier and a target identifier field; The request message is sent to the topic format containing the target party identifier, so that the application subscribes to the topic format containing the target party identifier, thereby achieving targeted delivery of the request message.

4. The device connection method based on MQTT according to claim 1, characterized in that, The step of generating a message identifier for each request message, establishing a concurrent and secure mapping relationship between the message identifier and the asynchronous channel, and implementing request and response interaction based on the secure mapping relationship includes: A message identifier is generated for each request message, and a concurrent security mapping relationship between the message identifier and the asynchronous channel is established and stored. The message identifier is carried in the message payload, which is a structured data carrier containing request instructions, business data and the message identifier. The concurrent security mapping relationship is updated in real time, and after sending a request message, the system blocks and waits for the response message from the asynchronous channel. After receiving the response message sent by the application, the concurrent security mapping relationship is looked up based on the message identifier in the response message to obtain the response data and release the blocking state of the asynchronous channel.

5. The device connection method based on MQTT according to claim 1, characterized in that, The step of publishing a timeout trigger message with the message identifier to the MQTT broker server when sending a request message, and performing timeout control operations based on the timeout trigger message, includes: When sending a request message, a timeout trigger message is published to the delay topic of the MQTT broker server. The timeout trigger message carries the message identifier corresponding to the request message, and the delay time of the timeout trigger message is a preset timeout threshold. If no response message is received for the request message within the timeout threshold, the timeout trigger message is triggered, and the mapping entry corresponding to the message identifier of the request message in the concurrency security mapping relationship is deleted accordingly. A timeout error is then returned through the asynchronous channel corresponding to the request message. If a response message is received in response to the request message within the timeout threshold, the mapping entry in the concurrent security mapping relationship corresponding to the message identifier carried in the response message is deleted, and the response data in the response message is processed normally.

6. The device connection method based on MQTT according to claim 1, characterized in that, The process of authenticating identity and establishing a connection with the application through an encrypted channel includes: Construct a transport layer encrypted channel based on transport layer security protocols; A preset encryption algorithm is used to hash and sign the message payload, generating signature information, which is then carried in the user attribute field of the MQTT message. The MQTT message carrying the signature information is sent to the application through the transport layer encryption channel, so that the application can extract the signature information from the user attribute field of the MQTT message; The application verifies the validity of the signature information using a pre-set public key. If the verification passes, the sender's identity is confirmed as legitimate and the request message is received. The message payload is extracted based on the request message. If the verification fails, the sender's identity is determined to be illegitimate and the request message is discarded.

7. The MQTT-based device connection method according to any one of claims 1-5, characterized in that, After initiating an MQTT connection request based on the target connection address and completing authentication and connection establishment with the application through an encrypted channel, the process also includes: If the connection fails to be established, switch to the backup device access point and repeat the hierarchical domain name system resolution process and the MQTT connection request process until the connection with the application is established. The switching to the backup device access point includes: According to the list of pre-stored backup device access points, if the connection fails, other backup device access points are selected in the order of the list for reconnection; Repeat the hierarchical domain name system resolution and MQTT connection request process for each backup device access point until the connection is successful or all backup device access points in the list are traversed. If all the device access points in the list fail to connect, the device will enter a sleep state and retry, and then re-initiate the MQTT connection request after a preset time interval.

8. A device connection device based on MQTT, characterized in that, include: The configuration loading module is used to load device identity configuration information; The domain name resolution module is used to resolve the domain name of the device access point interface and query the device access point information through the native domain name system based on the device identity configuration information. If the resolution is successful, it returns the optimal public IP as the target connection address of the MQTT proxy server; if the resolution fails, it uses the system-level domain name system to resolve the device access point interface and returns the system-level IP as the target connection address of the MQTT proxy server. The connection establishment module is used to initiate an MQTT connection request based on the target connection address, and complete the identity authentication and connection establishment with the application through an encrypted channel. The communication interaction module is used to transmit messages to the application based on the topic format set by MQTT after successful authentication and connection establishment. During the transmission of messages, a message identifier is generated for each request message, and a concurrent and secure mapping relationship between the message identifier and the asynchronous channel is established. The interaction between requests and responses is realized based on the secure mapping relationship. When sending a request message, a timeout trigger message of the message identifier is published to the MQTT broker server, and timeout control operations are performed based on the timeout trigger message.

9. An electronic device, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the MQTT-based device connection method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the MQTT-based device connection method as described in any one of claims 1-7.

Images