Dual-link based device condition monitoring method, system, device and medium

Abstract

The embodiment of the application provides a kind of based on dual-link equipment state monitoring method, system, device and medium, belong to network communication field, this method includes: based on Netty framework builds main communication link, and carries out data transmission using preset encryption protocol;Based on main communication link, equipment sends heartbeat data to platform with first preset frequency;Establish backup communication link, and equipment sends HTTP heartbeat request to platform with second preset frequency through backup communication link;Cache last heartbeat timestamp sent by main, backup communication link, compare current time with cached heartbeat timestamp, and preliminary determine equipment state in combination with preset rule;In combination with main, backup link heartbeat state and preliminary determination result, the final state of equipment is determined using redundancy logic.Heartbeat monitoring is realized by combining Netty long link and HTTP short link, state management is carried out using timing task, so as to improve the reliability and real-time performance of equipment state determination.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and more specifically to a device status monitoring method, system, device, and medium based on dual links. Background Technology

[0002] With the widespread application of the Internet of Things (IoT) and smart terminal devices, real-time monitoring of device online status has become a core support for the stable operation of IoT platforms and efficient business scheduling. Market research data shows that the number of IoT devices globally is growing at a rate exceeding 20% ​​annually, and the online status management of large-scale device clusters is directly related to the service reliability in fields such as smart energy, intelligent transportation, and industrial IoT. However, traditional device status monitoring methods often rely on a single-link architecture, exposing many shortcomings in complex scenarios.

[0003] From the perspective of link reliability, a single link is prone to momentary connection interruption due to network fluctuations or device resource contention. Without reconnection strategies or backup links, it is very easy to trigger heartbeat loss. Moreover, due to the limitation of request intervals, it is difficult to balance real-time performance and resource consumption. In scenarios with network fluctuations or limited device resources, this type of single link design is more likely to cause misjudgment of status.

[0004] Furthermore, traditional solutions often lack end-to-end encryption mechanisms. Heartbeat packets and status data are easily tampered with or forged by man-in-the-middle attacks when transmitted over the public internet. This not only leads to a distortion of the platform's perception of device status but also allows attackers to exploit forged status data to send malicious control commands, causing device downtime, data breaches, and other security incidents, resulting in compliance risks and economic losses for enterprises. With the continuous expansion of device scale, increasingly complex network environments, and ever-stricter security requirements, traditional single-link, unencrypted status monitoring models are no longer sufficient to meet the three-dimensional needs of IoT platforms for "real-time performance, accuracy, and security." Summary of the Invention

[0005] The purpose of this invention is to provide a device status monitoring method, system, device, and medium based on dual links. By combining Netty long links and HTTP short links to achieve heartbeat monitoring and using timed tasks for status management, the reliability and real-time performance of device status determination are improved.

[0006] To achieve the above objectives, embodiments of the present invention provide a device status monitoring method based on dual links, comprising: A long-lived connection between the device and the platform is established based on the Netty framework to build the main communication link, and a preset encryption protocol is used for data transmission; Based on the main communication link, the device sends heartbeat data to the platform at a first preset frequency. After receiving the data, the platform returns a response and initiates a timeout management mechanism to determine the validity of the main communication link. An HTTP short connection is established between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link, and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link. The system uses a centralized caching device to cache the last heartbeat timestamp sent by the primary and backup communication links. A timed task compares the current time with the cached last heartbeat timestamp and uses preset rules to make a preliminary determination of the device status. Combining the heartbeat status of the primary link, the heartbeat status of the backup link, and the preliminary assessment of the device status, redundant logic is used to determine the final status of the device.

[0007] Optionally, a long-lived connection is established between the device and the platform based on the Netty framework to build the main communication link, and a preset encryption protocol is used for data transmission, including: The platform initializes the Netty server, configuring event loop groups, TCP socket parameters, and configuring a processing channel for each connection. In the processing channel, a frame decoder for solving the TCP packet fragmentation problem, an inbound processor for decrypting received data, an outbound processor for encrypting sent data, and a business logic processor for processing encrypted and decrypted plaintext data are added in sequence according to the data processing order. The device initiates a TCP connection request to establish a long connection with the Netty server on the platform side. After the connection is established, the device is authenticated. Once the authentication is successful, the platform binds the device identifier to the corresponding channel and includes it in the connection management. An idle state detection processor is set in the processing channel to maintain the heartbeat of the long connection. When the device or platform needs to transmit data, the sender encrypts the data and sends it through the long connection. The receiver decrypts and processes the data after receiving it.

[0008] Optionally, the preset encryption protocol uses the SM4 algorithm to encrypt the message, and its protocol message format includes device identifier, operation instructions, data parameters and delimiters.

[0009] Optionally, based on the main communication link, the device sends heartbeat data to the platform at a first preset frequency. After receiving the data, the platform returns a response and initiates a timeout management mechanism to determine the validity of the main communication link, including: The device periodically generates and sends heartbeat data packets to the platform at a first preset frequency. The heartbeat data packets contain at least a device identifier and a heartbeat type identifier. After receiving and identifying the heartbeat data packet, the platform immediately returns a heartbeat response data packet to the corresponding device; The platform records the last valid communication timestamp for each device channel and updates the timestamp each time it receives any valid data from that device. The platform initiates a scheduled task to periodically check the last valid communication timestamp of each device channel. If the difference between the last valid communication timestamp and the current time exceeds a preset dynamic threshold, it determines that the device connection has timed out, closes the corresponding network channel, and triggers the device offline processing procedure.

[0010] Optionally, a centralized caching device can be used to cache the timestamp of the last heartbeat sent by the primary and backup communication links. A scheduled task compares the current time with the cached timestamp of the last heartbeat, and combines this with preset rules to preliminarily determine the device status, including: The platform stores the timestamp of the last successful heartbeat reception by each device on the primary and backup communication links in a centralized cache device, on a device-by-device basis. The platform initiates a timed judgment task, which periodically performs the following operations: Read the last heartbeat timestamp of the primary and backup communication links of each device from the centralized cache device; Obtain the current system time and calculate the difference between it and the last heartbeat timestamp of the primary and backup communication links. If the heartbeat of the primary communication link has not timed out, the device is online. If the heartbeat of the primary communication link timed out but the heartbeat of the backup communication link timed out, the backup communication link is online. If the heartbeats of both the primary and backup communication links timed out, the device is offline.

[0011] Optionally, the dynamic threshold is set according to the type of communication link; wherein, for the primary communication link, the dynamic threshold is consistent with the timeout management mechanism; for the backup communication link, the dynamic threshold is greater than its heartbeat transmission frequency.

[0012] Optionally, the redundant logic is characterized as follows: If either the main communication link or the backup communication link is within the corresponding dynamic threshold, it indicates that the main communication link and the backup communication link are effective and the device is online. When both the primary and backup communication links exceed the dynamic threshold, it indicates that the primary and backup communication links are invalid and the device is offline.

[0013] Secondly, the present invention also provides a device status monitoring system based on dual links, comprising: The main communication link construction unit is used to establish a long connection between the device and the platform based on the Netty framework to build the main communication link, and to use a preset encryption protocol for data transmission; The first determination unit is used to send heartbeat data to the platform at a first preset frequency based on the main communication link. After receiving the data, the platform returns a response and starts a timeout management mechanism to determine the validity of the main communication link. The backup communication link construction unit is used to establish an HTTP short connection between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link. The second determination unit is used to cache the last heartbeat timestamp sent by the primary and backup communication links using a centralized caching device, compare the current time with the cached last heartbeat timestamp through a timed task, and make a preliminary determination of the device status in combination with preset rules. The determination unit is used to combine the main link heartbeat status, the backup link heartbeat status, and the preliminary judgment of the device status, and to determine the final status of the device using redundant logic.

[0014] Thirdly, the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the dual-link-based device status monitoring method described above.

[0015] Fourthly, the present invention also provides a storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described dual-link-based device status monitoring method.

[0016] By combining Netty long connections and HTTP short connections to implement heartbeat monitoring and using scheduled tasks for status management, the reliability and real-time performance of device status determination are improved.

[0017] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a device status monitoring method based on dual links provided in an embodiment of the present invention; Figure 2 This is a detailed flowchart of a device status monitoring method based on dual links provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a device status monitoring system based on dual links provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] Various embodiments of this disclosure will be described more fully in the following detailed description. This disclosure may have various embodiments, and adjustments and changes may be made therein. However, it should be understood that there is no intention to limit the various embodiments of this disclosure to the specific embodiments disclosed herein, but rather this disclosure should be understood to cover all adjustments, equivalents, and / or alternatives falling within the spirit and scope of the various embodiments of this disclosure.

[0020] In the following, the terms “comprising” or “may include”, which may be used in various embodiments of this disclosure, indicate the presence of the disclosed functions or operations and do not limit the addition of one or more functions or operations. Furthermore, as used in various embodiments of this disclosure, the terms “comprising,” “having,” and their cognates are intended only to indicate a specific feature, number, step, operation, or combination of the foregoing and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, or combinations of the foregoing, or the possibility of adding one or more features, numbers, steps, operations, or combinations of the foregoing.

[0021] In various embodiments of this disclosure, the expression "or" or "at least one of A and / or B" includes any combination or all combinations of the words listed simultaneously. For example, the expression "A or B" or "at least one of A and / or B" may include A, may include B, or may include both A and B.

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] See Figure 1 The diagram shows a flowchart of a device status monitoring method based on a dual-link architecture in a specific embodiment, including the following execution steps: Step 100: Establish a long-lived connection between the device and the platform based on the Netty framework to build the main communication link, and use a preset encryption protocol for data transmission.

[0024] Specifically, when executing step 100, the following steps can be performed: S1000: The platform initializes the Netty server, configures the event loop group and TCP socket parameters, and configures the processing channel for each connection.

[0025] S1001: In the processing channel, a frame decoder for solving the TCP packet merging problem, an inbound processor for decrypting received data, an outbound processor for encrypting sent data, and a business logic processor for processing encrypted and decrypted plaintext data are added in sequence according to the data processing order.

[0026] S1002: The device initiates a TCP connection request to establish a long connection with the Netty server on the platform side. After the connection is established, the device is authenticated. After successful authentication, the platform binds the device identifier to the corresponding channel and includes it in the connection management.

[0027] S1003: An idle state detection processor is set in the processing channel to maintain the heartbeat of the long connection. When the device or platform needs to transmit data, the sender encrypts the data and sends it through the long connection. The receiver decrypts and processes the data after receiving it.

[0028] For example, the preset encryption protocol uses the SM4 algorithm to encrypt the message, and its protocol message format includes device identifier, operation instructions, data parameters and delimiters.

[0029] In one specific implementation, encrypting the message using the SM4 algorithm includes using a 128-bit (16-byte) pre-shared symmetric key; employing CBC mode, generating a 16-byte random initialization vector (IV), using a different IV for each encryption, padding the original message according to the PKCS#7 standard to ensure the length is an integer multiple of 16 bytes, dividing the plaintext into 16-byte blocks, performing an SM4 round transformation (32 rounds of non-linear iteration) on the padded plaintext using the key, and combining the IV with the XOR operation of the previous block's ciphertext and the current block's plaintext to generate ciphertext blocks. The final transmitted data format is "IV (16 bytes) + encrypted ciphertext (including padding)," which the receiver can extract and decrypt.

[0030] In one specific implementation, the platform builds a long-connection server based on the Netty framework, with the device acting as a client connecting to the platform. After the connection is established, the device sends heartbeat data in IPEM format every 5 seconds, with the format: {Device ID / HEARTBEAT / empty / ####}. The platform receives this data and returns {Device ID / REPLAY / empty / ####}. If no heartbeat is received within one minute, the device is determined to be offline, the connection is closed, and the session is cleared.

[0031] In one specific implementation, establishing a secure long-lived main communication link based on the Netty framework includes: Step 1: Netty server initialization and channel initialization: Create a Netty ServerBootstrap instance for configuring server parameters. Configure event loop groups (EventLoopGroup), one for accepting connections (bossGroup) and one for handling I / O operations (workerGroup). Specify the channel type as NioServerSocketChannel. Set TCP underlying parameters: SO_BACKLOG: connection queue size. SO_KEEPALIVE: enable TCP layer heartbeat keep-alive mechanism. Configure a processing chain (ChannelPipeline) for each new connection channel, adding the following key ChannelHandlers in sequence: Log Handler: used to record connection and data flow logs. Packet splicing / reassembly Handler: solves the TCP packet splicing problem and ensures the integrity of data packets. Encryption / decryption Handler: Decoder (Inbound): responsible for decrypting received ciphertext data. Decrypts data using a preset or negotiated key according to a preset encryption protocol. Encoder (Outbound): responsible for encrypting sent data. The plaintext commands or data issued by the platform are encrypted into ciphertext. The decrypted plaintext data is processed to execute core business logic such as device management, command issuance, and status reporting.

[0032] Step 2: The device connects to the Netty server via TCP. The server creates a corresponding Channel and adds it to the connection management pool. After the connection is established, the first data packet is used for device authentication via a specific Handler. The device sends its unique identifier and authentication credentials. The platform verifies the validity of the credentials. If verification fails, the connection is closed. If authentication is successful, the device's unique identifier is bound to the Netty Channel, facilitating subsequent message pushes by finding the corresponding channel using the device ID.

[0033] Step 3: Add an `IdleStateHandler` to the `ChannelPipeline` to detect read / write idle timeouts. Add a custom `HeartbeatHandler` to determine if the device is offline when a read idle event is triggered; it can proactively send heartbeat requests to the device or process heartbeat packets reported by the device to maintain connection activity. Add an `ExceptionHandler` to the `ChannelPipeline` to catch I / O exceptions, decoding exceptions, etc. When a connection is abnormally disconnected, the server removes the channel from the connection pool. The device should implement disconnection reconnection logic to attempt to reconnect according to a strategy after a connection is lost.

[0034] Step 4: Encrypted Data Transmission Process: Device Data → TCP Transmission → Netty Server Receive → Packet Assembly / Disassembly Processing → Decryption Handler Decryption → Business Handler Processes Plaintext Data. Platform business logic generates downlink commands → Locates the Channel corresponding to the target device → Encryption Handler encrypts → TCP Transmission → Device receives and decrypts.

[0035] Step 101: Based on the main communication link, the device sends heartbeat data to the platform at a first preset frequency. After receiving the data, the platform returns a response and initiates a timeout management mechanism to determine the validity of the main communication link.

[0036] Specifically, when executing step 101, the following steps can be performed: S1010: The device periodically generates and sends heartbeat data packets to the platform at a first preset frequency. The heartbeat data packets contain at least a device identifier and a heartbeat type identifier.

[0037] S1011: After receiving and identifying the heartbeat data packet, the platform immediately returns a heartbeat response data packet to the corresponding device.

[0038] S1012: The platform records the last valid communication timestamp for each device channel and updates the timestamp each time it receives any valid data from that device.

[0039] S1013: The platform starts a timed task to periodically check the last valid communication timestamp of each device channel. If the difference between the last valid communication timestamp and the current time exceeds a preset dynamic threshold, it is determined that the device connection has timed out, and the corresponding network channel is closed, triggering the device offline processing procedure.

[0040] Preferably, the dynamic threshold is set according to the type of communication link; wherein, for the primary communication link, the dynamic threshold is consistent with the timeout management mechanism; and for the backup communication link, the dynamic threshold is greater than its heartbeat transmission frequency.

[0041] In one specific implementation, the device sends heartbeats at a first preset frequency, and the platform responds and initiates a timeout management mechanism, including: Step 1: The device creates a scheduled task that executes periodically at a fixed first preset frequency. A heartbeat data packet is constructed, containing a unique device identifier, a data packet type identifier (used by the platform to distinguish business data from heartbeat data), and a timestamp. The device sends the heartbeat data packet to the platform through the established Netty main communication channel. Step 2: The business logic processor on the platform's Netty server receives the data, decrypts it, and parses the data packet type. If it is identified as a heartbeat packet, it is not uploaded to the upper-level business system but is directly processed by the connection management layer. The platform immediately constructs a heartbeat response data packet, containing a status code and a server timestamp. The heartbeat response packet is sent back to the device through the corresponding Netty channel. Step 3: The platform maintains a "last communication timestamp" for each connected device channel. This timestamp is refreshed whenever the platform receives any valid data packet from the device. The platform initiates a global scheduled scan task to check all connections at a second preset frequency and calculates the difference between the current time and the "last communication timestamp" of each channel. If the difference exceeds the preset timeout threshold, the device connection is determined to have timed out, and the device channel is marked as "invalid" or "deactivated" in the connection management pool. The platform calls the Netty channel's `close()` method to actively disconnect the TCP connection with the device and release server resources. Step 4: After sending a heartbeat packet, the device starts a waiting timer. If no heartbeat response is received from the platform within the specified time, a failure is recorded. When the number of consecutive heartbeat failures reaches a certain threshold, the device considers the main communication link unavailable, actively disconnects the current connection, and triggers a reconnection process to attempt to re-establish a connection with the platform.

[0042] Step 102: Establish an HTTP short connection between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link, and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link.

[0043] In one specific implementation, the device sends an HTTP GET or POST request to the platform every 60 seconds. The URL includes the device ID and a timestamp, and the request body may carry device status information (in JSON format). Upon receiving the request, the platform returns a status code 200 and optional instruction data.

[0044] Step 103: Use a centralized caching device to cache the last heartbeat timestamp sent by the primary and backup communication links. Compare the current time with the cached last heartbeat timestamp through a timed task, and make a preliminary determination of the device status based on preset rules.

[0045] Specifically, when executing step 103, the following steps can be performed: S1030: The platform stores the timestamp of the last successful heartbeat reception of each device on the primary and backup communication links in a centralized cache device on a device-by-device basis.

[0046] S1031: The platform initiates a timed judgment task and periodically performs the following operations: reads the last heartbeat timestamp of the primary and backup communication links of each device from the centralized cache device; obtains the current system time and calculates the difference between it and the last heartbeat timestamp of the primary and backup communication links; if the primary communication link heartbeat has not timed out, the device is online; if the primary communication link heartbeat timed out but the backup communication link heartbeat has not timed out, the backup communication link is online; if both the primary and backup communication link heartbeats timed out, the device is offline.

[0047] Step 104: Combining the main link heartbeat status, the backup link heartbeat status, and the preliminary determination of the device status, use redundant logic to determine the final status of the device.

[0048] In one embodiment, the redundancy logic is characterized as follows: if either the primary communication link or the backup communication link is within the corresponding dynamic threshold, it indicates that the primary communication link and the backup communication link are valid and the device is online; if both the primary communication link and the backup communication link exceed the dynamic threshold, it indicates that the primary communication link and the backup communication link are invalid and the device is offline.

[0049] In one specific implementation, leveraging the shared characteristics of centralized caching to achieve unified management and determination of the status of primary and backup dual links includes: Step 1: Selecting a centralized caching system, such as Redis or Redis Cluster, to ensure that all platform service instances can access the same data. A unique cache key and cache value are designed for each device, where the cache value contains at least two fields: `last_heartbeat_primary`: the server-side timestamp of the last successful heartbeat of the primary communication link, and `last_heartbeat_secondary`: the server-side timestamp of the last successful heartbeat of the backup communication link. When the platform receives and processes a valid heartbeat packet from a device via the primary link, it immediately updates the `last_heartbeat_primary` field in Redis for that device with the current server time. Similarly, when a heartbeat is received via the backup link, the `last_heartbeat_secondary` field is updated. Step 2: The platform starts an independent, periodic scheduled task to execute the status determination logic at a fixed frequency. After the scheduled task is triggered, it reads the list of devices requiring status determination and their corresponding primary and backup link last heartbeat timestamps from the centralized cache. Preset rules: For each device, obtain the current system time, calculate the difference between the current time and last_heartbeat_primary (delta_primary), and the difference between the current time and last_heartbeat_secondary (delta_secondary). Make a preliminary judgment based on the following preset rules: If delta_primary ≤ primary link timeout threshold, the device is preliminarily determined to be online with good communication quality. If delta_primary > primary link timeout threshold, but delta_secondary ≤ backup link timeout threshold, the device is preliminarily determined to be online on the backup link, indicating that the primary link is abnormal but the device has not completely lost connection. If delta_primary > primary link timeout threshold and delta_secondary > backup link timeout threshold, the device is preliminarily determined to be offline. Step 3: A scheduled task publishes the preliminary judgment results to an internal event bus or message queue. The service responsible for persisting device status subscribes to this event and updates the device status field in the database according to the preliminary judgment results. This achieves eventual consistency of device status in a distributed environment. When the status changes from online to backup link online or offline, a corresponding link switching alarm or device offline alarm can be triggered.

[0050] In this embodiment, the reliability and real-time performance of device status detection are improved by using long and short links to work together.

[0051] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0052] See Figure 2 The diagram shows a detailed flowchart of a dual-link device status monitoring method provided in this embodiment of the invention. The front-end device and the intelligent signaling platform establish a long connection via Netty, forming Link 1. A heartbeat interaction is performed every 5 seconds. The front-end device cyclically sends IPEM encrypted heartbeat packets. After receiving these packets, the intelligent signaling platform decodes and verifies them with a heartbeat, then replies with a REPLAY message. The intelligent signaling platform updates the device's last heartbeat timestamp in its Redis cache for subsequent status determination. The front-end device initiates an HTTP heartbeat request every 60 seconds as a supplementary mechanism to the Netty long connection, forming Link 2. The front-end device sends an HTTP request carrying device status information. The intelligent signaling platform processes the request, parses the status, and returns a 200 OK response (which may include control commands). It also updates the device's last heartbeat timestamp in Redis. Status adjudication process (timed execution): A timed task executes every 30 seconds to determine if the device is offline. The scheduled task retrieves the last heartbeat time of all devices from Redis, calculates the difference between the current time and the last heartbeat time, and if it exceeds 70 seconds, the device is considered to have timed out. The timed-out device is then marked as offline, and its status is synchronized to the intelligent message sending platform / front-end device. Control command distribution path (example): A primary / backup link is used to ensure the reliability of command distribution. Commands are preferentially distributed directly via a Netty long-lived connection. If the Netty link is unavailable, the command is included in the next HTTP heartbeat response.

[0053] The technical effects achieved by this application are as follows: Improved monitoring reliability: Dual links serve as backups for each other; as long as either link is functioning normally, status judgment can be maintained, avoiding misjudgments due to a single link failure. Enhanced security: The proprietary IPEM protocol, encrypted with the national cryptographic standard SM4, ensures secure data transmission. Support for functional expansion: The HTTP heartbeat link can carry device information and platform commands, enabling bidirectional communication and functional expansion. Avoidance of resource waste: Through a heartbeat timeout mechanism and Redis status caching, invalid connections are promptly cleaned up, preventing system resource waste and OOM (Out of Memory) risks.

[0054] like Figure 3 As shown, the following are embodiments of the device status monitoring system based on dual links provided in this disclosure. They belong to the same inventive concept as the device status monitoring methods based on dual links in the above embodiments. For details not described in detail in the embodiments of the device status monitoring system based on dual links, please refer to the embodiments of the device status monitoring methods based on dual links described above.

[0055] A dual-link-based device status monitoring system includes: The main communication link construction unit is used to establish a long connection between the device and the platform based on the Netty framework to build the main communication link, and to use a preset encryption protocol for data transmission; The first determination unit is used to send heartbeat data to the platform at a first preset frequency based on the main communication link. After receiving the data, the platform returns a response and starts a timeout management mechanism to determine the validity of the main communication link. The backup communication link construction unit is used to establish an HTTP short connection between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link. The second determination unit is used to cache the last heartbeat timestamp sent by the primary and backup communication links using a centralized caching device, compare the current time with the cached last heartbeat timestamp through a timed task, and make a preliminary determination of the device status in combination with preset rules. The determination unit is used to combine the main link heartbeat status, the backup link heartbeat status, and the preliminary judgment of the device status, and to determine the final status of the device using redundant logic.

[0056] Figure 4 This is a schematic diagram of the hardware structure of an electronic device that implements various embodiments of the present invention.

[0057] The dual-link-based device status monitoring method provided in this application can be applied to electronic devices. Those skilled in the art will understand that the electronic device structure described in this embodiment does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In this embodiment, the electronic device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0058] Electronic devices may include processors, external memory interfaces, internal memory, universal serial bus (USB) interfaces, charging management modules, power management modules, batteries, wireless communication modules, audio modules, speakers, microphones, sensor modules, buttons, cameras, displays, and SIM card interfaces, etc.

[0059] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0060] A processor may include one or more processing units, such as: a central processing unit (CPU), an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0061] The processor can serve as the nerve center and command center of an electronic device. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0062] The processor may also include memory for storing instructions and data. In some embodiments, the memory in the processor is a cache memory. This memory can store instructions or data that the processor has just used or that are used repeatedly. If the processor needs to use the instruction or data again, it can retrieve it directly from this memory. This avoids repeated accesses, reduces processor latency, and thus improves system efficiency.

[0063] An external storage interface (ESI) can be used to connect external memory cards, such as microSD cards, to expand the storage capacity of electronic devices. The external memory card communicates with the processor through the ESI to perform data storage functions, such as saving music and video files on the external memory card.

[0064] Internal memory can be used to store computer executable program code, which includes instructions. The processor executes various functional applications and data processing of electronic devices by running the instructions stored in internal memory. Internal memory can include a program storage area and a data storage area. Internal memory can include high-speed random access memory, and can also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0065] Wireless communication functionality in electronic devices can be achieved through antennas, wireless communication modules, modem processors, and baseband processors.

[0066] Wireless communication modules can provide solutions for wireless communication applications in electronic devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies.

[0067] Electronic devices can implement audio functions through audio modules, speakers, receivers, microphones, headphone jacks, and application processors.

[0068] Electronic devices can achieve shooting functions through ISPs, cameras, video codecs, GPUs, displays, and application processors.

[0069] Electronic devices can achieve display functions through GPUs, displays, and application processors.

[0070] A GPU is a microprocessor for image processing, connected to the display screen and application processor. GPUs are used to perform mathematical and geometric calculations for graphics rendering. A processor may include one or more GPUs, which execute program instructions to generate or modify display information.

[0071] A display screen is used to display images, videos, etc. A display screen includes a display panel.

[0072] The storage medium provided in this application stores a program product capable of implementing a dual-link-based device status monitoring method.

[0073] The dual-link-based device status monitoring method includes: establishing a long connection between the device and the platform based on the Netty framework to build the main communication link, and using a preset encryption protocol for data transmission; Based on the main communication link, the device sends heartbeat data to the platform at a first preset frequency. After receiving the data, the platform returns a response and initiates a timeout management mechanism to determine the validity of the main communication link. An HTTP short connection is established between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link, and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link. The system uses a centralized caching device to cache the last heartbeat timestamp sent by the primary and backup communication links. A timed task compares the current time with the cached last heartbeat timestamp and uses preset rules to make a preliminary determination of the device status. Combining the heartbeat status of the primary link, the heartbeat status of the backup link, and the preliminary assessment of the device status, redundant logic is used to determine the final status of the device.

[0074] In some possible implementations, the subject matter of this disclosure, namely, a dual-link-based device status monitoring method and system, can be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0075] The storage medium disclosed herein may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0076] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A device status monitoring method based on dual links, characterized in that, include: A long-lived connection between the device and the platform is established based on the Netty framework to build the main communication link, and a preset encryption protocol is used for data transmission; Based on the main communication link, the device sends heartbeat data to the platform at a first preset frequency. After receiving the data, the platform returns a response and initiates a timeout management mechanism to determine the validity of the main communication link. An HTTP short connection is established between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link, and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link. The system uses a centralized caching device to cache the last heartbeat timestamp sent by the primary and backup communication links. A timed task compares the current time with the cached last heartbeat timestamp and uses preset rules to make a preliminary determination of the device status. Combining the heartbeat status of the main link, the heartbeat status of the backup link, and the preliminary determination of the device status, redundant logic is used to determine the final status of the device. A long-lived connection is established between the device and the platform based on the Netty framework to build the main communication link, and data transmission is performed using a preset encryption protocol, including: The platform initializes the Netty server, configuring event loop groups, TCP socket parameters, and configuring a processing channel for each connection. In the processing channel, a frame decoder for solving the TCP packet fragmentation problem, an inbound processor for decrypting received data, an outbound processor for encrypting sent data, and a business logic processor for processing encrypted and decrypted plaintext data are added in sequence according to the data processing order. The device initiates a TCP connection request to establish a long connection with the Netty server on the platform side. After the connection is established, the device is authenticated. Once the authentication is successful, the platform binds the device identifier to the corresponding channel and includes it in the connection management. An idle state detection processor is set in the processing channel to maintain the heartbeat of the long connection. When the device or platform needs to transmit data, the sender encrypts the data and sends it through the long connection. The receiver decrypts and processes the data after receiving it. A centralized caching device is used to cache the timestamp of the last heartbeat sent by the primary and backup communication links. A scheduled task compares the current time with the cached timestamp of the last heartbeat, and combines this with preset rules to preliminarily determine the device status, including: The platform stores the timestamp of the last successful heartbeat reception by each device on the primary and backup communication links in a centralized cache device, on a device-by-device basis. The platform initiates a timed judgment task, which periodically performs the following operations: Read the last heartbeat timestamp of the primary and backup communication links of each device from the centralized cache device; Obtain the current system time and calculate the difference between it and the last heartbeat timestamp of the primary and backup communication links. If the heartbeat of the primary communication link has not timed out, the device is online. If the heartbeat of the primary communication link timed out but the heartbeat of the backup communication link timed out, the backup communication link is online. If the heartbeats of both the primary and backup communication links timed out, the device is offline. A dynamic threshold is set according to the type of communication link; wherein, for the primary communication link, the dynamic threshold is consistent with the timeout management mechanism; for the backup communication link, the dynamic threshold is greater than its heartbeat transmission frequency.

2. The device status monitoring method based on dual links according to claim 1, characterized in that, The preset encryption protocol uses the SM4 algorithm to encrypt messages, and its protocol message format includes device identifier, operation instructions, data parameters, and delimiters.

3. The device status monitoring method based on dual links according to claim 1, characterized in that, Based on the main communication link, the device sends heartbeat data to the platform at a first preset frequency. After receiving the data, the platform returns a response and initiates a timeout management mechanism to determine the validity of the main communication link, including: The device periodically generates and sends heartbeat data packets to the platform at a first preset frequency. The heartbeat data packets contain at least a device identifier and a heartbeat type identifier. After receiving and identifying the heartbeat data packet, the platform immediately returns a heartbeat response data packet to the corresponding device; The platform records the last valid communication timestamp for each device channel and updates the timestamp each time it receives any valid data from that device. The platform initiates a scheduled task to periodically check the last valid communication timestamp of each device channel. If the difference between the last valid communication timestamp and the current time exceeds a preset dynamic threshold, it determines that the device connection has timed out, closes the corresponding network channel, and triggers the device offline processing procedure.

4. The device status monitoring method based on dual links according to claim 1, characterized in that, Redundant logic is characterized as follows: If either the main communication link or the backup communication link is within the corresponding dynamic threshold, it indicates that the main communication link and the backup communication link are effective and the device is online. When both the primary and backup communication links exceed the dynamic threshold, it indicates that the primary and backup communication links are invalid and the device is offline.

5. A dual-link-based equipment status monitoring system, applicable to the dual-link-based equipment status monitoring method according to any one of claims 1-4, characterized in that, include: The main communication link construction unit is used to establish a long connection between the device and the platform based on the Netty framework to build the main communication link, and to use a preset encryption protocol for data transmission; The first determination unit is used to send heartbeat data to the platform at a first preset frequency based on the main communication link. After receiving the data, the platform returns a response and starts a timeout management mechanism to determine the validity of the main communication link. The backup communication link construction unit is used to establish an HTTP short connection between the device and the platform as a backup communication link. The device sends an HTTP heartbeat request to the platform at a second preset frequency through the backup communication link and carries the device status information in the request, forming a redundant monitoring channel in parallel with the main communication link. The second determination unit is used to cache the last heartbeat timestamp sent by the primary and backup communication links using a centralized caching device, compare the current time with the cached last heartbeat timestamp through a timed task, and make a preliminary determination of the device status in combination with preset rules. The determination unit is used to combine the main link heartbeat status, the backup link heartbeat status, and the preliminary judgment of the device status, and to determine the final status of the device using redundant logic.

6. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the dual-link-based device status monitoring method as described in any one of claims 1 to 4.

7. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the dual-link-based device status monitoring method as described in any one of claims 1 to 4.

Images