A cross-platform configuration synchronization method and system based on a private synchronization protocol

Abstract

This invention discloses a cross-platform configuration synchronization method and system based on a proprietary synchronization protocol, comprising: a client sending a network access request message; a server dynamically generating configuration information and sending it to the client; the client applying the configuration information and returning a confirmation message; the server updating the node list and notifying the control terminal of node status changes; the server periodically sending heartbeat request messages to online clients based on a timer and receiving corresponding heartbeat response messages, monitoring the client status through a multi-level timeout detection mechanism, and synchronizing status changes to the control terminal in real time; the control terminal sending a configuration modification message to the server; the server verifying the modification, updating its local configuration, and broadcasting a configuration update message using an incremental update mechanism to all online clients. This invention proposes a three-in-one role architecture of control terminal, server, and client, achieving efficient cross-role communication and collaborative work through the JYTL proprietary protocol, solving the core pain points of traditional distributed device management systems.

Description

Technical Field

[0001] This invention relates to the field of distributed system communication technology, specifically to a cross-platform configuration synchronization method and system based on a proprietary synchronization protocol. Background Technology

[0002] With the rapid development of IoT and smart home technologies, wireless mesh networks based on the EasyMesh standard have been widely adopted. Traditional distributed network device management systems typically employ a centralized configuration distribution mechanism, where the server pushes configuration information unidirectionally to each client device, lacking intelligent configuration optimization and real-time status feedback mechanisms.

[0003] Traditional configuration synchronization schemes use complete configuration file transmission, requiring the entire configuration file to be transmitted even for minor parameter changes. This results in significant network bandwidth waste and fails to meet the real-time requirements of applications. Existing heartbeat detection mechanisms often employ simple polling methods, leading to low detection accuracy, long fault detection delays, and a lack of multi-level verification mechanisms, resulting in a false positive rate as high as 5-8%, impacting system stability and user experience.

[0004] In traditional single-role or dual-role architectures, a single node often assumes multiple responsibilities (e.g., a node is responsible for both device management and user interaction logic), leading to blurred system functional boundaries and making it easy to cause compatibility issues when adding new functions or expanding the number of nodes. In networks composed of mixed devices, using a common protocol (such as MQTT) or different proprietary protocols can cause numerous compatibility problems and additional development costs due to differences in protocol parsing and inconsistent data formats. Summary of the Invention

[0005] The purpose of this invention is to provide a cross-platform configuration synchronization method and system based on a proprietary synchronization protocol, so as to solve the problems of low efficiency and insufficient reliability of existing configuration synchronization mentioned in the background art.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] According to one aspect of the present invention, a cross-platform configuration synchronization method based on a proprietary synchronization protocol is provided, the method comprising:

[0008] The client sends a network access request message to the server. The server dynamically generates configuration information based on the client's device capability information and the current network status, and then sends the configuration information to the client.

[0009] After applying the configuration information, the client returns a confirmation message to the server, and the server updates the node list and notifies the control terminal of the node status change.

[0010] The server periodically sends heartbeat request messages to online clients based on a timer and receives corresponding heartbeat response messages. It monitors the client status through a multi-level timeout detection mechanism and synchronizes the status changes to the control terminal in real time.

[0011] The control terminal sends a configuration modification message to the server. After verification, the server updates its local configuration and broadcasts the configuration update message using an incremental update mechanism to all online clients.

[0012] After each client application updates its configuration, it returns a confirmation message to the server. The server uses a thread pool to process the confirmation messages in batches, and after summarizing the results, it sends a configuration synchronization completion notification to the control terminal.

[0013] Based on the aforementioned scheme, before the client sends a network access request message to the server, the server, the client, and the control terminal respectively initialize core functional modules based on a private synchronization protocol and establish communication connections; the core functional modules include a message parsing module, a scheduled task module, a performance analysis module, and a data processing module.

[0014] Based on the aforementioned scheme, the network access request message is constructed based on a predefined format, including a fixed-length message header and a variable-length message body; the message header includes a start identifier, protocol version number, message type identifier, serial number, and checksum; the message body uses a lightweight structured data format to describe business information.

[0015] Based on the aforementioned scheme, the verification code uses CRC32 to ensure the integrity and security of message transmission.

[0016] Based on the aforementioned scheme, the incremental update mechanism includes identifying the changed fields of configuration parameters, encapsulating only the changed fields to generate a concise configuration update message; marking the configuration update message with a version to support version rollback and conflict detection; and adopting a grouped parallel broadcast strategy to perform intelligent grouped transmission based on the client's network topology and performance characteristics.

[0017] Based on the aforementioned scheme, the dynamic generation of configuration information, parsing of structured device capability information reported by the client, real-time collection of current network environment status data, and generation of personalized optimization configuration schemes through multi-objective optimization algorithms based on a predefined configuration strategy library are all part of the scheme.

[0018] Based on the aforementioned scheme, the device capability information includes hardware performance parameters, protocol support characteristics, and service function features; the current network environment status data includes topology information, load status indicators, and spectrum resource information.

[0019] Based on the aforementioned scheme, the multi-level timeout detection mechanism includes three levels of timeout detection. The first level of timeout detection is: if no response is received within a set time, a retry mechanism is triggered; the second level of timeout detection is: if no response is received multiple times consecutively, the device is marked as suspicious; and the third level of timeout detection is: if the maximum timeout threshold is exceeded, the device is confirmed to be offline and its status is updated.

[0020] Based on the aforementioned scheme, the thread pool is a dynamically adjustable thread pool that continuously monitors key indicators. When the number of tasks to be processed exceeds the set threshold of the core thread processing capacity and system resources are sufficient, the thread pool automatically increases the number of worker threads according to a preset step size. When the system is in a low-load state for a continuous period of time and the idle time of the threads exceeds the set threshold, the excess thread resources are gradually released.

[0021] According to another aspect of the present invention, a cross-platform configuration synchronization system based on a private synchronization protocol is provided, the system comprising a server, a client, and a control terminal;

[0022] The server, the client, and the control terminal each have built-in core functional modules based on a private synchronization protocol; the core functional modules include a message parsing module, a scheduled task module, a performance analysis module, and a data processing module.

[0023] The server is used to receive and process messages from the client and the control terminal, and manage the synchronization logic between devices; the client is used to communicate with the server, execute instructions issued by the server, and report its own status; the control terminal is used to configure and manage the server and the client.

[0024] The message parsing module is used to parse and encapsulate messages based on a private synchronization protocol; the timed task module is implemented based on a time wheel timer and is used to manage heartbeat detection and timeout retransmission timed tasks; the performance analysis module is used to monitor and statistically analyze message processing latency, heartbeat response time, and system resource usage during configuration synchronization; and the data processing module is used to parse and generate structured configuration information and status data.

[0025] As can be seen from the above technical solutions, this invention has at least the following advantages and positive effects compared with the prior art: This invention proposes a three-in-one role architecture of control end, server end, and client end, and realizes efficient cross-role communication and collaborative work through the JYTL private protocol, solving the core pain points of traditional distributed device management systems in terms of scalability, compatibility, maintainability, and high concurrency performance; through incremental update mechanism and multi-threaded concurrent processing mechanism, the device network access time and configuration synchronization latency are significantly reduced; through heartbeat detection of time wheel timer and multi-level timeout mechanism, the status recognition rate is improved and the false judgment rate is reduced; through lightweight module design and static memory buffer technology, memory usage is reduced by more than 70% and server CPU load is reduced by 40%, which is especially suitable for resource-constrained embedded environments.

[0026] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0028] Figure 1 This is a schematic diagram of a cross-platform configuration synchronization method based on a private synchronization protocol according to the present invention;

[0029] Figure 2 This is a schematic diagram illustrating the heartbeat detection and status synchronization of the present invention;

[0030] Figure 3 This is a schematic diagram of the functional modules of the server side of the present invention;

[0031] Figure 4 This is a schematic diagram of the client side of the present invention. Detailed Implementation

[0032] To more clearly illustrate the purpose, technical solutions, and advantages of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein. On the contrary, these embodiments are provided so that the present invention will be more comprehensive and complete, and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0033] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of the invention. However, those skilled in the art will recognize that the technical solutions of the invention can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of the invention.

[0034] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0035] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0036] The present invention will now be described in detail with reference to specific embodiments:

[0037] Example 1, as Figure 1 As shown in the figure, this embodiment provides a cross-platform configuration synchronization method based on a private synchronization protocol. The specific steps of the method are as follows:

[0038] S1: The client sends a network access request message to the server. The server dynamically generates configuration information based on the client's device capability information and the current network status, and sends the configuration information to the client.

[0039] This embodiment is based on the JYTL proprietary synchronization protocol. Configuration synchronization is achieved through the collaborative work of three execution entities: a server, a client, and a control unit. Each entity has built-in core functional modules, including message parsing, scheduled tasks, performance analysis, and data processing. The three entities work together to complete the configuration synchronization process: the server is responsible for node management, message routing, and synchronization logic control; the client is responsible for application configuration and status feedback; and the control unit is responsible for configuration input and status monitoring. Both the client's network access request message (type 0x04) and the server's configuration message (type 0x02) use a custom JYTL protocol format. The proprietary protocol ensures communication security and customization flexibility. A unified JYTL proprietary protocol serves as the foundation for three-way communication: a unified message format, transmission standard, and verification mechanism are defined for all cross-role communication (control unit → server, server ↔ client); the protocol itself is designed to be lightweight and customizable, adaptable to everything from high-performance servers to resource-constrained embedded devices.

[0040] Before the device is connected to the network and its configuration is synchronized, the server, client and control terminals also initialize the core functional modules based on the private synchronization protocol and establish communication connections.

[0041] Specifically, for server initialization, after starting, the server first reads communication parameters from the pre-configured configuration file, including the listening port number, maximum connection limit, TCP Keep-Alive parameters, and timeout periods for each operation. Then, it initializes the core functional modules sequentially to build a stable communication foundation, including: a message parsing module, which initializes a MsgDecode class instance, sets the JYTL private protocol version number to 0x01, enables CRC32 data verification, and configures a maximum message length limit (e.g., 4096 bytes) to ensure the integrity and security of communication data; a scheduled task module, which creates a time wheel timer instance (e.g., 60 task slots), sets millisecond-level timing precision, and registers callback functions for critical tasks such as heartbeat detection (e.g., 5-second intervals) and timeout retransmission to achieve efficient and accurate task scheduling; a data processing module, which initializes a JSON parser and configures a static memory buffer (e.g., 1024 bytes); and a performance analysis module, which initializes a TimeUse class instance and configures a set of monitoring metrics such as message processing latency and concurrent connections, as well as data reporting intervals. Once the core functional modules are ready, a network listening socket is established, bound to a specified port (e.g., 8080), and a TCP connection listening service is started to accept client connections. For business data and management initialization, persistent node information data is loaded, and a hash table-based node management structure (SyncNodeManager) is constructed to enable fast node lookup and status maintenance; a separate statistics thread is started to continuously monitor the usage of system resources such as CPU and memory.

[0042] For client initialization, after the client device starts up, it obtains server connection parameters, including the primary and backup server address list, connection timeout configuration, and retry policy; it performs lightweight initialization of the message parsing module, scheduled task module, performance analysis module, and data processing module; it initializes the message processing module, registering callback functions for configuration updates, heartbeat responses, and status reporting; it performs local device self-checks to verify network interface status, hardware resource availability, and system compatibility; it generates device identification information and prepares network access authentication data; it establishes a communication connection with the server, employing an exponential backoff algorithm to implement an intelligent reconnection mechanism, and performs handshake verification after a successful connection. The intelligent reconnection mechanism using the exponential backoff algorithm includes a retry interval that increases exponentially, starting from an initial delay T0, with the delay doubling with each retry until the maximum delay T is reached. max A random jitter factor is introduced based on the calculated latency to prevent multiple clients from retrying simultaneously; backoff parameters are dynamically adjusted based on network quality indicators and historical server response data; the retry status is automatically reset after a successful connection, and the initial parameters are optimized after the connection becomes stable.

[0043] For the initialization of the control terminal, the core functional modules related to control functions are initialized first. This includes initializing the message parsing module, configuring JYTL protocol parameters to parse various status notifications and topology data from the server; initializing the scheduled task module to schedule tasks such as automatic UI refresh (e.g., periodically requesting the latest node list) and request timeout retries; and initializing the data processing module to generate configuration commands and parse structured data returned by the server. Optionally, a lightweight performance analysis module is initialized to monitor the control terminal's own response performance. Further, the user interface and management functions are initialized, including initializing user interface components, loading display configurations and theme settings; establishing a management connection with the server, subscribing to system status change notifications (e.g., node online / offline, configuration synchronization results); verifying user operation permission levels and establishing a secure communication channel; and obtaining initial node topology data from the server to construct a network topology visualization model.

[0044] Preferably, the server, client, and control end adopt a parallel initialization strategy, in which the core communication modules of each end are initialized independently and in parallel to reduce the overall startup time; connection dependencies are established, and the client initiates a connection after the server listens for service readiness; initialization status collaborative verification is implemented, and each end enters normal operation mode after reporting its readiness status to the server.

[0045] After detecting the network access trigger conditions, the client device sends a network access request message to the server. These trigger conditions include: the device completing basic initialization upon its first power-on; the device re-establishing a network connection after recovering from an abnormal state; and the device detecting a change in the network topology requiring re-registration. When any of these trigger conditions is met, the client enters the network access request preparation state. Basic initialization includes network interface readiness, protocol stack loading, and successful acquisition of the server's IP address and port information.

[0046] The client constructs an inbound request message according to the predefined JYTL private protocol format, which includes a fixed-length header and a variable-length body. The client sends this message via a TCP connection and simultaneously initiates reliability assurance mechanisms: 1) a timeout monitoring timer; 2) a retransmission mechanism based on an adaptive exponential backoff algorithm, performing a finite number of retries at exponentially increasing intervals after a timeout; and 3) serial number management, using monotonically increasing serial numbers to match and verify the order of requests and responses.

[0047] Specifically, the client constructs a network access request message according to a predefined JYTL private protocol format. This predefined JYTL private protocol format employs a layered structure, including: a fixed-length header and a variable-length body. The fixed-length header, to ensure efficient parsing, is defined as a fixed byte length (e.g., 40 bytes) for quick message boundary location. Its fields are arranged tightly in a preset order, including a start identifier (0x4A59), protocol version number, message type identifier, serial number, body length, and CRC32 checksum. The variable-length body follows the header, its length specified by the body length field in the header. The body uses a lightweight structured data format (e.g., JSON) to encapsulate variable business data, such as device capability information. The client sends the network access request message to the server through an established connection-oriented communication channel, while simultaneously implementing reliability assurance mechanisms, including: starting a timeout monitoring timer and setting a time threshold for waiting for a response; establishing a message retransmission mechanism to resend the request according to a predefined strategy if no response is received after timeout; and implementing serial number management to ensure message order and uniqueness. The core of the predefined strategy followed by the message retransmission mechanism is the adaptive exponential backoff algorithm. When no response is received within a timeout period, the client does not immediately retransmit but waits for an interval. This interval increases exponentially with the number of retries (for example, the interval for the nth retry is k*r^(n-1), where k is the initial interval and r is the backoff coefficient), until the maximum number of retries or the maximum interval limit is reached. To prevent the "avalanche effect" caused by multiple clients retrying simultaneously during network congestion, a random jitter value is introduced into the calculated retry interval. When a server response is received or the connection is broken, the retransmission status is automatically reset. The serial number management mechanism ensures the uniqueness and order of messages. This includes: the serial number is a monotonically increasing integer value within a communication session, typically starting from a random number, with each subsequent message's serial number incrementing by 1; when the server returns a response message, it carries the serial number of the corresponding request message as is, allowing the client to match the response with previous requests and verify their correct order; this mechanism allows the client to identify out-of-order response arrivals due to network latency or other reasons and to process business logic in the correct order. For example, based on TCP reliable transmission, a retransmission mechanism is enabled, with a maximum of 3 retries at 2-second intervals.

[0048] Furthermore, after receiving the network access request message, the server dynamically generates an optimized personalized configuration scheme, i.e., optimized configuration information, for each access device based on the capability feature set of the client device and the current network status. The configuration information is then encapsulated into a configuration message and sent to the client through a reliable transmission mechanism. The configuration information includes network connection parameters, communication protocol parameters, and service function parameters.

[0049] Specifically, the system dynamically generates optimized configuration information. The server parses the structured device capability information reported by the client, including hardware performance parameters (processor architecture, memory capacity, wireless transceiver capabilities, etc.), protocol support features (communication protocol version, encryption algorithm, QoS level, etc.), and service function characteristics (data forwarding capability, power consumption mode, etc.). Simultaneously, the server collects multi-dimensional status data of the current network environment in real time, including topology information (node ​​distribution, connection relationships, etc.), load status indicators (bandwidth utilization, channel interference level, etc.), and spectrum resource information (available channels, signal coverage quality, etc.). Based on these input parameters, the server performs intelligent matching through a predefined configuration strategy library and uses a multi-objective optimization algorithm to solve for the optimal configuration scheme under multiple constraints such as performance, power consumption, and stability. This algorithm comprehensively considers device capability level, network load balancing, and service requirement priority to generate a complete configuration set containing network connection parameters, communication protocol parameters, and service function parameters.

[0050] The multi-objective optimization algorithm models the configuration generation problem as a mathematical programming problem with multiple optimization objectives and constraints. The main optimization objectives include: performance maximization (pursuing the highest data transmission rate and the lowest communication latency), power minimization (reducing device power consumption as much as possible and extending battery life), stability optimization (ensuring connection reliability and anti-interference capability), and resource balancing (achieving a reasonable distribution of the overall network load). There are inherent constraints among these objectives. For example, high performance is often accompanied by high power consumption. The algorithm introduces an adaptive weighting mechanism to dynamically adjust the importance of each objective.

[0051] The predefined configuration policy library systematically stores and manages optimized configuration schemes validated under various typical network scenarios and device combinations. The library employs a three-tiered hierarchical storage structure. The top layer is the scenario classification layer, which categorizes major application scenarios based on macro-level characteristics such as network scale, service type, and device density, including home mesh networks, enterprise office environments, industrial IoT, and high-density public areas. The middle layer is the policy template layer, providing multiple basic configuration templates for each major scenario, including high-performance priority templates, energy-saving priority templates, stability priority templates, and balanced templates. The bottom layer is the parameter rule layer, storing specific configuration parameter adjustment rules and constraints, including channel selection rules, power control rules, QoS mapping relationships, and recommended protocol parameter values. Each configuration policy in the policy library contains the following core elements: policy identifier, applicable scenario description, target device characteristics, network environment conditions, configuration parameter set, expected performance indicators, and weight coefficient settings. The configuration parameter set covers physical layer parameters (channel width, transmit power), network layer parameters (routing protocols, IP allocation strategies), transport layer parameters (TCP window size, retransmission mechanism), and application layer parameters (service discovery, data synchronization interval). Preferably, the policy library also includes conflict resolution rules, providing priority determination and parameter fusion methods when multiple policy rules conflict. When the server processes a configuration request, the policy library selects the optimal policy through a multi-level matching algorithm; the first level of matching is based on device type and capability level to filter out compatible configuration templates; the second level of matching considers current network status indicators to select the policy variant most suitable for the current network conditions; the third level of matching combines business requirement characteristics to fine-tune the policy parameters.

[0052] Preferably, after receiving the network access request message, before generating configuration information, the server further includes verifying the integrity and legality of the network access request message; verifying the network access request message includes legality verification, integrity verification, and resource availability assessment. After verification, it further includes: intelligent configuration generation and reliable configuration distribution; wherein, legality verification checks whether the device's MAC address is within the whitelist of permitted access to complete device identity authentication; integrity verification verifies the CRC32 checksum of the message to ensure that the data has not been tampered with or damaged during transmission; resource availability assessment confirms that the current system's connection count, CPU, memory, and other resources are sufficient to support the access of new devices; intelligent configuration generation, after successful verification, the server dynamically generates optimized configuration information based on the client's capability feature set and real-time network status, which covers network connection, communication protocol, and business function parameters; reliable configuration distribution encapsulates the configuration information into a configuration message with a version number and distributes it to the client through a reliable transmission mechanism based on acknowledgment and retransmission. This mechanism requires the client to return the application result and triggers retransmission if no acknowledgment is received within a timeout, automatically retransmitting the configuration message; a unique version number is assigned to each configuration to prevent old configurations from overwriting new configurations and causing configuration rollback.

[0053] Preferably, during the device network access configuration synchronization process, the server uses SyncNodeManager to achieve batch creation and management of nodes, and builds a hash index table based on MAC address to achieve fast location and matching of device nodes (lookup time ≤ 3ms). In the configuration information distribution stage, an incremental update mechanism is adopted to transmit only the necessary core Mesh networking parameters, avoiding redundant transmission of complete configuration files. The optimized configuration message body length is compressed from 512 bytes in the traditional solution to less than 64 bytes, reducing network transmission time by about 85%, significantly reducing network bandwidth usage and transmission latency. The server uses thread pool technology (8 threads) to handle concurrent network access requests, avoiding serial blocking, and the total time is compressed to 420ms (the theoretical value of single node time is 850ms, but the actual time is shortened by 50.6% due to parallel optimization).

[0054] S2: After applying the configuration information, the client returns a confirmation message to the server, and the server updates the node list and notifies the control terminal of the node status change.

[0055] After receiving the configuration message, the client parses the message and verifies its validity; it applies the configuration information to the local system, including parameter settings and functional module initialization; and it sends a configuration confirmation message to the server, reporting the configuration application result. The configuration application result includes a success, failure, or partial success status and a detailed description. Preferably, the configuration generation process is based on device capability matching and network load balancing principles to generate a personalized optimized configuration scheme; the configuration application employs a transactional operation mechanism to ensure the atomicity and rollbackability of the configuration application. Parameter settings include configuring wireless parameters (channel, power, SSID, etc.), configuring network parameters (IP address, subnet mask, etc.), and configuring synchronization parameters (heartbeat interval, timeout, etc.).

[0056] After receiving the configuration confirmation message, the server updates the node management information according to the configuration application results; marks the client status as online and records the configuration version information; and sends a status synchronization message to the control terminal to notify of the node status change. The status synchronization message includes the node identifier, status type, and timestamp information. Preferably, status synchronization adopts an incremental update mechanism, synchronizing only the status information of nodes that have changed. For example, after receiving the confirmation message, the server updates the system status, including adding node information, adding the new device to the node list managed by SyncNodeManager; updating the connection status, marking the device as online, and recording the last communication time; establishing topology relationships, updating the network topology diagram, and establishing logical relationships between devices. For example, the server pushes a status change message to the control terminal. The message type is 0x03 (status synchronization message), and the notification content includes: event type "device_online", device ID, timestamp, number of nodes, and topology change flag (topology_changed: true). After receiving the notification, the control terminal refreshes the device list and topology diagram display.

[0057] In one implementation, if configuration application fails, it automatically reverts to the previous valid configuration, retrying or adjusting configuration parameters based on the error type. After multiple failures, the administrator is notified for manual configuration. In case of network interruption: TCP connection abnormalities are automatically reconnected while maintaining session state; after reconnection, interrupted configuration transactions are resumed using a serial number; and state changes during the interruption are automatically synchronized after network recovery. Preferably, batch configurations are generated, allowing the server to handle multiple network access requests simultaneously, improving throughput; an asynchronous application mechanism is executed, preventing the client from blocking other message processing while applying configuration; incremental state synchronization only synchronizes changed node information, reducing network traffic. Preferably, configuration templates are reused, with devices of the same type sharing the same template, reducing generation overhead; configuration messages use pre-allocated memory to avoid frequent allocation and release; and multiple configuration transactions on the same device reuse TCP connections.

[0058] S3: The server periodically sends heartbeat request messages to online clients based on a timer and receives corresponding heartbeat response messages. It monitors the client status through a multi-level timeout detection mechanism and synchronizes the status changes with the control terminal in real time.

[0059] In this embodiment, as Figure 2 As shown, the server monitors the client's status and maintains system status synchronization through a periodic heartbeat mechanism; the server periodically sends heartbeat requests to the client, the client responds to the heartbeat, the server monitors the client's status, and if the client is offline, it marks it and notifies the control end.

[0060] The heartbeat mechanism includes heartbeat scheduling, heartbeat message management, status assessment, and timeout control. Heartbeat scheduling, implemented using a time wheel timer, is responsible for triggering heartbeat requests periodically. Heartbeat message management handles the sending of heartbeat requests and the receiving of responses. Status assessment analyzes heartbeat response data to determine the client's health status. Timeout control monitors unresponsive clients and triggers timeout handling procedures. The server initializes heartbeat detection parameters, including the heartbeat interval, response timeout threshold, and number of retries. The heartbeat interval is dynamically adjusted based on the network environment and device importance, ranging from 3 to 10 seconds. For example, with a heartbeat detection interval of 5 seconds, if a client fails to respond to a heartbeat request three consecutive times, it is marked as offline.

[0061] For heartbeat request sending, the server periodically sends heartbeat request messages (message type 0x01) to all online clients based on a time wheel timer (e.g., every 5 seconds). The time wheel timer adopts a multi-level time wheel structure, supporting high-precision scheduled task scheduling with millisecond-level accuracy. For example, the time wheel is configured with 60 slots, each slot representing 1 second, with an accuracy of 1 millisecond. Heartbeat requests are evenly distributed to avoid network congestion. The heartbeat frequency is dynamically adjusted (3-10 seconds) according to network load. The heartbeat request message includes a request timestamp, serial number, and session identifier, using a lightweight message format to reduce network overhead. The server uses a batch processing mechanism to improve efficiency, sending messages in groups according to client geographical location or network topology. Multiple heartbeat requests are sent in parallel without blocking the main thread, with critical devices receiving priority and ordinary devices receiving messages later.

[0062] Furthermore, upon receiving a heartbeat request message, the client executes a rapid response process, including: parallel collection of device status information, including processor load, memory usage, and network connection quality; construction of a heartbeat response message containing multi-dimensional status parameters; and immediate transmission of the heartbeat response message (message type 0x01) to the server using an optimized transmission mechanism, carrying device status information such as CPU load and signal strength. The collection of device status information employs a multi-threaded parallel execution method to reduce response latency; the heartbeat response message uses differential encoding technology to transmit only status changes; and the transmission process uses a zero-copy mechanism to avoid data copying overhead.

[0063] Furthermore, the server receives heartbeat response messages from the client and parses and verifies them; it analyzes response time, device status parameters, and resource usage to comprehensively assess the client's health status; the server performs multi-dimensional analysis of the heartbeat response, calculates network latency and identifies potential network problems, and performs response time analysis; it comprehensively evaluates device health based on indicators such as CPU, memory, and signal strength, and performs device status assessment. Furthermore, the server implements a multi-level timeout detection mechanism, including three levels of timeout detection: Level 1 timeout detection: if no response is received within a set time, a retry mechanism is triggered; Level 2 timeout detection: if no response is received multiple times consecutively, the device is marked as suspicious; Level 3 timeout detection: if the maximum timeout threshold is exceeded, the device is confirmed offline and its status is updated. If the detected device responds normally within a set time, the last active time is updated; the multi-level timeout detection uses adaptive timeout thresholds, dynamically adjusting the timeout time at each level according to network quality. Furthermore, the server updates the client's status based on the heartbeat detection results and sends a status synchronization message to the control end. The status synchronization message includes details of the status change, a timestamp, and a description of the reason for the change. Preferably, after the offline client restarts, it automatically reconnects to the server and re-executes the device network access and configuration synchronization in step S1, using incremental updates to synchronize only the changed configurations.

[0064] S4: The control terminal sends a configuration modification message to the server. After verification, the server updates its local configuration and broadcasts the configuration update message using an incremental update mechanism to all online clients.

[0065] Users initiate configuration modifications through the control terminal. The control terminal generates and sends a configuration modification request message (message type 0x02, serial number 0x000A) to the server. The configuration modification request message includes the target configuration parameters, the scope of modification, and application policy information. The configuration modification request message uses digital signature technology to ensure its integrity and authenticity.

[0066] Furthermore, after receiving the configuration modification request message, the server performs multi-layered verification processing. The first layer verifies the message signature and sender permissions; the second layer checks the legality and validity of the configuration parameters; and the third layer detects configuration conflicts and dependencies. Specifically, the first layer uses the RSA-256 algorithm to verify the message signature, ensuring the message source is trustworthy and verifying whether the user has configuration modification permissions (read-only / operator / administrator); it also confirms whether the user's permissions cover the target configuration scope. The second layer verifies whether the configuration parameter format conforms to the specifications, checks whether the parameter values ​​are within a reasonable range, and ensures that the parameters comply with business logic constraints. The third layer identifies mutually exclusive parameter combinations, checks the impact of configuration changes on related parameters, and ensures that the new configuration is compatible with the existing system state. After successful verification, the server atomically updates the local configuration and generates a new configuration version number; the atomic configuration update uses a transaction log mechanism to ensure the integrity and recoverability of the configuration update. Atomicity configuration updates refer to configuration update operations following an "all or nothing" principle, ensuring that configuration changes are executed as an indivisible unit: if any failure occurs during the configuration update process, the system automatically rolls back to the state before the update; the configuration update is only confirmed as complete after all configuration parameters have been successfully updated; and the system is prevented from being in an inconsistent state due to partial configuration updates. A transaction log mechanism is used to ensure the integrity and recoverability of configuration updates: before the configuration update begins, the configuration state before the update is recorded in the transaction log; every critical step in the configuration update process is recorded in the log; when a system failure occurs, the system can be restored to a consistent state by replaying the transaction log; the log records include timestamps, operation types, and verification information to ensure log reliability.

[0067] Furthermore, the server broadcasts configuration update messages (message type 0x02, serial number 0x000B) to all online clients. These messages use an incremental update method, identifying changed fields in the configuration parameters and encapsulating only the changed fields to generate a concise update message; that is, only the changed configuration parameters are transmitted. Versioning of these update messages supports version rollback and conflict detection. A grouped parallel broadcast strategy is employed, intelligently grouping and transmitting messages based on the client's network topology and performance characteristics. Upon receiving the configuration update message, the client verifies its validity and applies the configuration changes. After successful application, the client returns the configuration application result to the server (message type 0x05, serial number 0x000B). Configuration application uses transactional operations and supports a configuration rollback mechanism. If a configuration application failure is detected, the rollback mechanism automatically reverts to the previous valid configuration version. Transactional operations refer to configuration application processes possessing the characteristics of atomicity, consistency, isolation, and durability. Atomicity means that configuration application operations are indivisible; either all succeed or all fail. Consistency ensures that the system remains in a valid state before and after configuration application. Isolation means that concurrent configuration application operations do not interfere with each other. Durability means that successfully applied configuration changes are permanently effective. The configuration rollback mechanism is automatically executed when a configuration application failure is detected: the system maintains a history of configuration versions, with each successfully applied configuration corresponding to a version number; during rollback, the version number is used to quickly locate and restore the previous stable configuration; the rollback process also possesses transactional characteristics, ensuring the reliability of the rollback operation; both manual and automatic rollback triggering methods are supported.

[0068] S5: After each client application updates its configuration, it returns a confirmation message to the server. The server uses a thread pool to process the confirmation messages in batches, and after summarizing the results, it sends a configuration synchronization completion notification to the control terminal.

[0069] After successfully applying the configuration update, each client immediately sends a structured confirmation message to the server. This message contains key information such as device identifier, configuration version number, application status, timestamp, and processing time. The server can establish a dedicated receive buffer to perform format validation and preliminary classification on the incoming confirmation messages, ensuring data integrity and processability. The server uses a dynamically adjustable thread pool mechanism to process the confirmation messages in parallel. Messages are grouped by device or divided into multiple batches by time windows and processed concurrently by worker threads in the thread pool. Each processing thread is responsible for verifying message validity, parsing application results, recording performance metrics, and storing the processing results in a unified result set. This thread pool mechanism dynamically adjusts based on multi-dimensional monitoring metrics. The system continuously monitors key indicators such as task queue length, average processing time of a single task, and system CPU and memory utilization. When the number of tasks to be processed exceeds the set threshold of the core thread processing capacity and system resources are sufficient, the thread pool automatically increases worker threads according to a preset step size. When the system is in a low-load state for a continuous period and the idle time of threads exceeds the set threshold, excess thread resources are gradually released. Preferably, this mechanism also has predictive scaling capabilities, which identify business patterns by analyzing historical load data and pre-allocate computing resources before the expected load peak arrives to achieve smooth response.

[0070] Optionally, the processed results are intelligently aggregated and analyzed to generate a comprehensive report encompassing four dimensions: Synchronous statistics, calculating overall response rate, success rate, failure rate, and number of pending tasks; performance metrics, analyzing average application time, maximum and minimum processing time, and success rate percentage; fault analysis, classifying and statistically analyzing failure cases by error type and device category; and quality assessment, calculating a comprehensive quality score based on timeliness, reliability, and integrity. A structured synchronous report is automatically generated based on the analysis results. The report includes an execution summary, detailed findings, recommended actions, and follow-up steps. The execution summary highlights the overall status, progress, and key issues; detailed findings provide in-depth analytical data across various dimensions; recommended actions propose specific solutions to the identified problems; and follow-up steps clarify subsequent operational guidelines.

[0071] The server sends a configuration synchronization completion notification to all online control instances. The notification messages use a priority distribution mechanism, adjusting the sending order according to the importance of the synchronization results. Each notification contains a digital signature to ensure authenticity and integrity, and supports delivery confirmation and retransmission upon failure. The notification content includes both a concise status summary and instructions for accessing the full report.

[0072] This embodiment collects the configuration application results of all clients in the distributed environment, performs unified analysis and processing, and provides a complete synchronization status report to the control terminal, thereby achieving closed-loop management of the configuration synchronization process.

[0073] Optionally, this embodiment also includes node management. After receiving a node deletion command, the server locates the target node connection (TcpSocket object) based on the device identifier (node ​​MAC address); sends a deletion command to the target client, the client executes the deletion operation and returns an operation status code; if the client is offline, the deletion command is cached and resent after the client comes online; after receiving the deletion response, the server closes the corresponding network connection and atomically cleans up the node-related resources using a batch resource release interface; and sends a deletion result notification to the control terminal and updates the network topology through a status synchronization message. The node deletion operation is triggered actively by the control terminal, such as when a user initiates a deletion operation through the management interface; or automatically by the server, when a heartbeat detection timeout occurs consecutively and the device is determined to be offline; or triggered by system policies, when resources are insufficient, non-critical nodes are cleaned up according to the policy. For example, NodeController manages Socket connections and node data in a unified manner. When deleting, the TcpSocket handle, SyncNode object and cached messages (Msgs list) are cleared at once through the "batch resource release interface", which takes ≤8ms. With the offline node command cache, if the node is temporarily offline, the deletion command is temporarily stored on the server and automatically pushed after the node comes back online, without the need for a second delivery. The deletion of a single node takes 92ms.

[0074] Example 2 presents an exemplary cross-platform configuration synchronization system based on a private synchronization protocol, including a server, a client, and a control terminal, each of which has a built-in core functional module based on the JYTL private synchronization protocol. The core functional modules include a message parsing module, a scheduled task module, a performance analysis module, and a data processing module.

[0075] The server is used to receive and process messages from the client and the control terminal, manage the synchronization logic between devices, message routing, and node management; the client is used to communicate with the server, execute the instructions issued by the server, apply configuration information, and report its own status; the control terminal is used to configure and manage the server and the client; the server, client, and control terminal communicate through a private synchronization protocol, and the three work together to complete the entire process from configuration issuance and status synchronization to result aggregation.

[0076] In this embodiment, the message parsing module is implemented using the MsgDecode class to parse and encapsulate messages based on the JYTL private protocol; the scheduled task module is implemented using a time wheel timer to manage heartbeat detection and timeout retransmission scheduled tasks, achieving high-precision task scheduling; the performance analysis module is implemented using the TimeUse class to monitor and statistically analyze message processing latency, heartbeat response time, and system resource usage during configuration synchronization, providing data for optimizing synchronization strategies; the data processing module integrates the JsonCpp library to parse and generate configuration information and status data in structured formats such as JSON. It should be noted that the message parsing module is optimized for the JYTL private protocol, supporting fast CRC32 checksum and streaming message parsing, reducing parsing latency while ensuring data integrity; the protocol design uses a fixed header length to facilitate quick message boundary location and improve processing efficiency.

[0077] The server, client, and controller call the corresponding modules to complete the communication and synchronization functions according to their respective roles and responsibilities.

[0078] like Figure 3 As shown, the server acts as the communication hub, fully utilizing all core modules and undertaking the most complex management and scheduling tasks. Specifically, the message parsing module continuously processes messages from clients and the control unit, supporting fast verification and streaming parsing using the JYTL protocol; the scheduled task module achieves high-precision scheduling based on a time-wheel algorithm, managing global heartbeat detection (e.g., sending heartbeats to all clients every 5 seconds), managing timeout retransmissions (e.g., timeouts while waiting for client confirmation), and scheduling other background tasks; the performance analysis module monitors key system metrics in real time, providing data support for optimization, such as message processing latency, connection count, and resource usage, which are the main data sources for system optimization; and the data processing module generates configuration information (JSON format) to be sent to clients and parses configuration modification commands issued by the control unit. The server's scheduled task module is implemented using a time-wheel timer, achieving millisecond-level scheduling accuracy and reducing memory usage by 80% compared to traditional timers; the performance analysis module uses incremental statistics to calculate key metrics in real time without affecting system performance.

[0079] Combination Figure 4The client primarily interacts with the server using message parsing and data processing modules, while its scheduled task module is mainly used for local state maintenance. Specifically, the message parsing module parses instructions from the server (such as configuration messages and heartbeat requests) and encapsulates them into messages to be sent to the server (such as acknowledgment messages and heartbeat responses); the scheduled task module may be used to manage local reconnection mechanisms (such as periodic retries after a connection is lost) and to handle certain local tasks that need to be executed periodically; the data processing module parses JSON configurations sent by the server and may encapsulate its own state into JSON format for reporting; the performance analysis module may be simplified or omitted, and on clients with extremely limited resources, it may only retain basic logging functionality instead of complete performance statistics. It should be noted that the client typically does not actively initiate global heartbeats but instead responds to heartbeat requests from the server.

[0080] The control side focuses on using message parsing and data processing modules to implement configuration distribution and status monitoring. Specifically, the message parsing module parses status synchronization messages from the server (such as node list updates and device offline notifications) and encapsulates them into query or control messages to be sent to the server; the data processing module is mainly used to generate and parse structured data related to UI interaction; the scheduled task module has relatively fewer uses, possibly for automatic UI refresh (such as periodically requesting the latest node list from the server); the performance analysis module mainly focuses on user experience-related metrics; the control side prioritizes business logic and UI display over underlying communication performance.

[0081] Preferably, each core module has a built-in anomaly detection and recovery mechanism; the message parsing module isolates and logs abnormal message formats; the scheduled task module supports task execution timeout monitoring and automatic restart; and the performance analysis module proactively triggers alarms and degradation strategies when performance degradation is detected. Each module exchanges data and synchronizes its state through standardized interfaces; for example, after the scheduled task module triggers heartbeat detection, it constructs and sends messages through the message parsing module, while the performance analysis module monitors the latency and success rate of the entire process, forming a closed-loop monitoring and optimization mechanism. For resource-constrained environments such as embedded systems, the core modules support feature trimming and parameter tuning; the client's data processing module can dynamically adjust the buffer size based on available memory, and the scheduled task module automatically reduces the scheduling frequency in low-power mode, achieving an adaptive balance between performance and resource consumption.

[0082] The system supports cross-platform deployment, including Windows, Linux, and embedded OpenWRT systems, and adapts to the network interfaces and system calls of different platforms through a unified protocol abstraction layer. All core modules support feature customization and parameter tuning to adapt to various deployment environments, from resource-rich servers to resource-constrained embedded clients, and ensure system reliability through a unified exception handling mechanism.

[0083] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims. It should be understood that the invention is not limited to the precise structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A cross-platform configuration synchronization method based on a private synchronization protocol, characterized in that, The method is cooperatively executed by a control terminal, a service terminal and a client based on the same private synchronization protocol communication, and comprises the following steps: The client sends an access request message to the service terminal, the service terminal dynamically generates configuration information through a multi-objective optimization algorithm according to the device capability information and the current network state of the client, and sends the configuration information to the client; The client returns an acknowledgement message to the service terminal after applying the configuration information, the service terminal updates a node list and notifies the control terminal of a node state change; The service terminal periodically sends a heartbeat request message to online clients based on a timer, receives corresponding heartbeat response messages, monitors the state of the clients through a multi-level timeout detection mechanism, and synchronizes the state change to the control terminal in real time; The control terminal sends a configuration modification message to the service terminal, the service terminal updates the local configuration after verification and broadcasts a configuration update message to all online clients using an incremental update mechanism; Each client returns an acknowledgement message to the service terminal after applying the configuration update, the service terminal processes the acknowledgement messages in batches using a dynamically adjustable thread pool, sends a configuration synchronization completion notification to the control terminal after summarizing the results.

2. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 1, characterized in that, Before the client sends the access request message to the service terminal, the service terminal, the client and the control terminal respectively initialize core function modules based on the private synchronization protocol and establish a communication connection; the core function modules include a message parsing module, a timing task module, a performance analysis module and a data processing module.

3. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 1, characterized in that, The access request message is constructed based on a predefined format, including a fixed-length message header and a variable-length message body; the message header includes a start identifier, a protocol version number, a message type identifier, a serial number and a check code; the message body uses a lightweight structured data format to describe business information.

4. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 3, characterized in that, The check code uses a CRC32 check code to ensure the integrity and security of message transmission.

5. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 1, characterized in that, The incremental update mechanism includes identifying the change field of the configuration parameter, encapsulating only the change field to generate a simplified configuration update message; version marking is performed on the configuration update message to support version rollback and conflict detection; a grouping and parallel broadcasting strategy is used for intelligent grouping transmission according to the network topology and performance characteristics of the client.

6. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 1, characterized in that, The dynamically generated configuration information includes parsing the structured device capability information reported by the client, collecting state data of the current network environment in real time, generating an individualized optimization configuration scheme through a multi-objective optimization algorithm based on a predefined configuration strategy library.

7. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 6, characterized in that, The device capability information includes hardware performance parameters, protocol support characteristics and business function features. The state data of the current network environment includes topology structure information, load condition indicators and spectrum resource information.

8. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 1, characterized in that, The multi-level timeout detection mechanism includes three-level timeout detection, the first-level timeout detection is that if no response is received within a set time, a retry mechanism is triggered; the second-level timeout detection is that if no response is received for multiple times in succession, the device is marked as suspicious; the third-level timeout detection is that if the maximum timeout threshold is exceeded, the device is confirmed to be offline and the state is updated.

9. The cross-platform configuration synchronization method based on a private synchronization protocol according to claim 1, characterized in that, The service end adopts a thread pool that can be dynamically adjusted to batch process the confirmation messages, including continuously monitoring key indicators, when the number of tasks to be processed exceeds the set threshold of the processing capacity of core threads and the system resources are sufficient, the thread pool automatically increases the working threads according to a preset step; when the system is continuously in a low load state and the thread idle time exceeds a set threshold, then the excess thread resources are gradually released; the key indicators include the task queue length, the average processing time of a single task, the CPU and memory utilization of the system.

10. A cross-platform configuration synchronization system based on a private synchronization protocol, for implementing the method according to any one of claims 1-9, characterized in that, The system comprises a service end, a client end and a control end; The service end, the client end and the control end are respectively built-in core function modules based on a private synchronization protocol; the core function modules include a message analysis module, a timing task module, a performance analysis module and a data processing module; The service end is used for receiving and processing the messages of the client end and the control end, managing the synchronization logic between devices, monitoring the state of the client end and synchronizing the state information to the control end in real time; the client end is used for communicating with the service end, executing the instructions issued by the service end and feeding back the state of itself; the control end is used for issuing configuration instructions to the service end and receiving and processing the system state and configuration synchronization result information from the service end; The message analysis module is used for analyzing and encapsulating the messages based on the private synchronization protocol; The timing task module is realized based on a time wheel timer and is used for managing the heartbeat detection and the timing task of the timeout retransmission; The performance analysis module is used for monitoring and counting the message processing delay, the heartbeat response time and the system resource occupation in the configuration synchronization process; the data processing module is used for analyzing and generating the configuration information and state data in a structured format.

Images