Large-scale equipment trunking communication method

Abstract

The invention relates to the technical field of Internet of Things communication, in particular to a large-scale equipment trunking communication method, which comprises the following steps that: when network interruption occurs between a central server and any Internet of Things equipment or a reconnection operation result is failure, the central server acquires a retry mark value and judges whether to continue to initiate connection retry; if the retry is allowed, the central server queries a communication resource table and judges whether effective communication resources corresponding to the Internet of Things equipment exist or not; if yes, progressively increasing a counting variable recording the number of reconnection times of the Internet of Things equipment to obtain the current number of reconnection times; if the current reconnection frequency does not exceed the maximum reconnection frequency threshold, obtaining the delay time corresponding to the current reconnection frequency according to the dynamic correction factor, the maximum allowable delay time, the jitter factor and the initial reconnection delay time or the delay time corresponding to the last reconnection frequency; and after the delay time arrives, initiating a reconnection operation to the Internet of Things device through the effective communication resource to obtain a reconnection operation result.

Description

Technical Field

[0001] The present application relates to the field of Internet of Things communication technology, and in particular to a large-scale device cluster communication method. Background Art

[0002] In modern highway IoT systems, large-scale device cluster communication has become a core requirement. With the rapid development of intelligent transportation infrastructure, highway systems must maintain stable communication with massive numbers of IoT devices (such as roadside sensors, cameras, and electronic signs) to enable real-time data collection, status monitoring, and remote control. However, in actual deployments, the communication link between the central server and IoT devices can frequently be interrupted due to network fluctuations, device failures, and physical link interruptions. In these situations, the system requires a reconnection mechanism to restore communication, but existing reconnection strategies have significant drawbacks.

[0003] Currently, common communication reconnection solutions typically employ a hard-coded retry mechanism with fixed intervals, such as initiating a reconnection request every fixed duration (e.g., 5 seconds). While this solution is simple to implement, it presents serious challenges in large-scale device cluster scenarios. When a large network outage occurs or devices go offline en masse, the central server will receive a large number of concurrent reconnection requests in a short period of time, causing server resources (such as CPU, bandwidth, and connection pools) to become instantly saturated, creating a "retry storm." This not only increases server pressure but can also trigger an avalanche effect, delaying or even paralyzing normal business services due to resource competition. Furthermore, fixed-interval retry strategies cannot adapt to dynamically changing network environments. For example, in the early stages of network recovery, premature or excessive retries can exacerbate congestion, while excessive delays can cause communication recovery to lag, impacting system real-time performance.

[0004] While some existing solutions employ exponential backoff to adjust retry intervals, these rely solely on a simple exponential growth rule (e.g., doubling the delay with each retry) and lack the ability to dynamically adapt to actual network conditions and server load. For example, during brief network fluctuations, excessively long backoff delays can lead to inefficient communication recovery. Furthermore, in high-load scenarios, the fixed parameters of the backoff algorithm may not effectively distribute the retry load. Furthermore, existing solutions often neglect the effective management of communication resources (such as connection handles and protocol adapter instances). Failure to promptly release inactive resources can lead to memory leaks or resource exhaustion. Furthermore, traditional reconnection mechanisms lack adaptability to intermittent network failures. For example, in scenarios with unstable network signals, such as highway tunnels and remote roads, devices may frequently disconnect. However, existing technologies cannot distinguish between temporary outages and permanent failures, resulting in excessive ineffective retries or premature abandonment of potentially recoverable device connections. This limitation not only reduces communication reliability but also increases operational costs. Summary of the Invention

[0005] (1) Technical issues to be resolved In view of the above-mentioned shortcomings and deficiencies of the prior art, the present application provides a large-scale device cluster communication method, which solves the technical problems in the prior art of excessive server pressure and low network recovery efficiency caused by fixed retry intervals.

[0006] (2) Technical solution In order to achieve the above objectives, the main technical solutions adopted in this application include: The present invention provides a large-scale device cluster communication method, which is applied to a highway system. The highway system includes a central server and a plurality of IoT devices connected to the central server through a network. The method includes: S1. When a network interruption or a reconnection operation fails between the central server and any IoT device, the central server obtains a retry flag value and determines whether to continue initiating a connection retry based on the retry flag value; S2. If the retry flag value indicates that retry is allowed, the central server queries a pre-stored communication resource table to determine whether there is a valid communication resource corresponding to the IoT device; S3. If there is a valid communication resource corresponding to the IoT device, increment a counting variable recording the number of reconnections of the IoT device to update the current number of reconnections. S4. If the current number of reconnections does not exceed the preset maximum reconnection threshold, then obtain the delay time corresponding to the current number of reconnections based on the preset dynamic correction factor, the preset maximum allowable delay time, the preset jitter factor, and the preset initial reconnection delay time or the previously obtained delay time corresponding to the last number of reconnections; S5. After the delay time corresponding to the current number of reconnection times has expired, a reconnection operation is initiated to the IoT device through the effective communication resource to obtain a reconnection operation result.

[0007] Preferably, in some embodiments of the present application, the method further comprises: S6. If the reconnection operation result is failure, repeat steps S1-S5 until the reconnection operation result is success.

[0008] Preferably, in some embodiments of the present application, The retry flag value is generated according to a pre-set retry strategy; The pre-set retry strategy includes: counting the current number of retries, and prohibiting retry if it exceeds a preset maximum reconnection number threshold; or detecting the duration of the network interruption between the central server and the IoT device, and prohibiting retry if it exceeds a timeout threshold.

[0009] Preferably, in some embodiments of the present application, The valid communication resource includes at least one of the following: a connection handle, a protocol adapter instance, or a communication proxy object, and is generated and recorded when the central server and the IoT device are successfully connected for the first time.

[0010] Preferably, in some embodiments of the present application, the retry flag value is a value of continueTrying.

[0011] Preferably, in some embodiments of the present application, the S4 specifically includes: S41. If the current number of reconnections does not exceed the preset maximum reconnection number threshold, obtaining a corrected delay time corresponding to the current number of reconnections based on a preset dynamic correction factor, a preset maximum allowable delay time, and a preset initial reconnection delay time or a previously obtained delay time corresponding to the last number of reconnections; S42: Obtain the delay time corresponding to the current number of reconnection times based on the corrected delay time corresponding to the current number of reconnection times and a preset jitter factor.

[0012] Preferably, in some embodiments of the present application, the S41 specifically includes: If the current number of reconnections does not exceed the preset maximum reconnection number threshold, then the corrected delay time corresponding to the current number of reconnections is calculated using formula (1) based on the preset dynamic correction factor, the preset maximum allowable delay time, and the preset initial reconnection delay time or the delay time corresponding to the previously obtained last reconnection number; The formula (1) is: delay t =min(delay x ×factor, maxDelay); t is the current number of reconnections; delay t The corrected delay time corresponding to the current number of reconnections; factor is a pre-set dynamic correction factor; maxDelay is the preset maximum allowed delay time; When t=1, delay x It is the preset initial reconnection delay time; When t>1, delay x The delay time corresponding to the last reconnection number obtained in advance.

[0013] Preferably, in some embodiments of the present application, the S42 specifically includes: Corrected delay based on the current number of reconnections t and the preset jitter factor jitter, the normal distribution probability density function expressed by formula (2) is used to construct a delay time distribution model, and the actual delay time corresponding to the current reconnection number t is calculated through this distribution model; The formula (2) is:

[0014] Represents the probability density when the delay time is x; x is the delay time variable of this reconnection operation; Indicates the corrected delay time delay corresponding to the current number of reconnections t t ; Represents the standard deviation, which is ×jitter; jitter is the jitter factor; exp is the exponential function; Among them, from =delay t 、 =delay t The normal distribution constructed with ×jitter as the parameter uses random sampling to generate a delay time value x. The value of x is the delay time corresponding to the current reconnection number t.

[0015] Preferably, in some embodiments of the present application, the preset dynamic correction factor is a real value between 2.7 and 2.72; The preset jitter factor jitter value is a real value between 0.1 and 0.12.

[0016] Preferably, in some embodiments of the present application, the initial reconnection delay time is obtained by: Based on a pre-trained machine learning model, the central server combines the historical operating data and current status feature data of disconnected IoT devices to dynamically predict the initial reconnection delay time, including: Collecting historical operation data and state feature data of the IoT device, and performing feature engineering processing on the historical operation data and current state feature data of the IoT device to form a feature vector; The historical operation data and status characteristic data of the IoT device include: historical mean time between failures, last failure time, recent failure times, historical availability, and priority of the IoT device; Among them, the historical mean time between failures refers to the average duration of the continuous normal operation cycle of the IoT device; the last failure time refers to the time point when the device most recently experienced an abnormality; the number of recent failures refers to the cumulative number of failures within a preset time window; the historical availability rate is the ratio of the cumulative time that the IoT device is in normal network connection with the central server within a preset statistical period to the total time of the preset statistical period; the priority of the IoT device indicates the relative importance level of the IoT device; Input the feature vector into a trained gradient boosting decision tree model, and the trained gradient boosting decision tree model outputs a prediction result as the initial reconnection delay time of the IoT device; The training data of the gradient boosting decision tree model includes a plurality of training samples, wherein each training sample includes a feature vector and an initial reconnection delay time corresponding to the feature vector.

[0017] (3) Beneficial effects The large-scale device cluster communication method provided by the embodiment of the present application, by introducing a dynamic delay adjustment mechanism in the reconnection strategy, can intelligently calculate the optimal reconnection interval based on the current network status, server load and historical reconnection records to avoid retry storms; by combining the jitter factor and the dynamic correction factor, the reconnection requests are evenly distributed in the time dimension, effectively alleviating the instantaneous pressure on the server; at the same time, through the maintenance and management of the communication resource table, it is ensured that each reconnection uses effective communication resources to avoid resource waste caused by invalid connections. In this way, even in extreme cases where the network fluctuates over a large area and the device cluster is collectively disconnected, a smooth, efficient and adaptive connection recovery can still be achieved, ensuring the communication reliability and service stability of the entire highway Internet of Things system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 1 is a flow chart of a large-scale device cluster communication method according to an embodiment of the present application; Figure 2 is a schematic structural diagram of a highway system according to one embodiment of the present application; Figure 3 The figure is a flow chart of a method for obtaining the delay time corresponding to the current number of reconnection times according to one embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to better explain the present application and facilitate understanding, the present application is described in detail below through specific implementation methods in conjunction with the accompanying drawings.

[0020] In related technologies, the existing solutions for reconnecting large-scale IoT devices after network interruptions can be summarized into the following categories: The first type is a communication recovery mechanism based on a fixed reconnection strategy. This type of method usually extends the waiting time after each reconnection failure according to a preset exponential backoff or linear increment strategy after the IoT terminal is disconnected. For example, after the system sets the initial delay time and the maximum number of retries, it increases the reconnection interval in sequence until the maximum upper limit is reached. Although this strategy is simple to implement and does not require dynamic judgment, it lacks awareness of the device's operating status and the occupancy of communication resources. It is easy to cause concentrated reconnection storms during large-scale disconnections or peak system loads, exacerbating network congestion and even causing the central server to crash. In addition, fixed strategies cannot adapt to differences in device priority, failure frequency, etc., resulting in low reconnection efficiency, long recovery time, and poor communication reliability.

[0021] The second category involves reconnection control methods based on task scheduling priorities. These methods predefine communication priorities, response levels, or task levels for IoT devices and adjust reconnection order or delay times accordingly. While this alleviates the issue of high reconnection latency for critical devices to some extent, this method relies heavily on manually set priorities and lacks an intelligent adjustment mechanism, making it difficult to dynamically adapt to changes in device status. Furthermore, their reconnection strategies often fail to consider historical operational stability and network connection quality data, resulting in weak policy generalization and insufficient control capabilities in the face of sudden network anomalies.

[0022] The third category involves reconnection throttling mechanisms based on centralized server scheduling and time window control. This approach maintains a connection status table and resource pool on the central server, employing rate limiting or time slicing strategies to control device reconnection behavior in batches to avoid concentrated peaks. However, when faced with tens of thousands of concurrent device disconnections, this mechanism has inherent limitations in scheduling granularity, resource matching, and latency strategies. It also lacks personalized modeling of individual device status and historical connection performance, resulting in crude reconnection scheduling and difficulty ensuring system recovery speed and overall robustness.

[0023] To this end, the embodiment of the present application provides a communication method for large-scale device clusters, which innovatively introduces a machine learning model based on historical operating data and state characteristics. By dynamically predicting the optimal initial reconnection delay time for each disconnected device, and combining the communication resource status and reconnection times on the central server side, a personalized reconnection strategy with adaptability is generated in real time. At the same time, a jitter factor introduction method based on the normal perturbation mechanism is designed, so that the actual delay of each reconnection is randomly perturbed on the basis of the theoretical value, further reducing the risk of resource competition and communication congestion caused by the simultaneous reconnection of large-scale devices. This solution takes into account both distributed intelligent decision-making capabilities and central unified control capabilities. It can not only significantly improve the recovery speed after large-scale disconnection, but also has good scalability and deployment adaptability. It is particularly suitable for scenarios such as highway Internet of Things, traffic monitoring, and industrial edge equipment where the equipment scale is large, the operating environment is complex, and the communication stability requirements are high. Its reconnection strategy is both accurate and efficient, and can effectively improve the overall robustness and stability of the system.

[0024] To better understand the above technical solutions, exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. Instead, these embodiments are provided to enable a clearer and more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0025] Figure 1 A large-scale device cluster communication method of the present application is applied to a highway system. Figure 2 The highway system includes a central server and a plurality of IoT devices connected to the central server network. Figure 1 As shown, the communication method for large-scale device clusters includes: S1. When a network interruption or a reconnection operation fails between the central server and any IoT device, the central server obtains a retry flag value and determines whether to continue initiating a connection retry based on the retry flag value; In some embodiments of the present application, the retry flag value is generated according to a pre-set retry strategy; the pre-set retry strategy includes: counting the current number of retries, and prohibiting retry if it exceeds a preset maximum reconnection threshold; or detecting the duration of the network interruption between the central server and the IoT device, and prohibiting retry if it exceeds a timeout threshold.

[0026] In this embodiment, when the central server detects a network interruption or reconnection failure with an IoT device, it generates a retry flag value based on a preset retry strategy and uses this value to determine whether to initiate a connection retry. The retry strategy includes methods such as counting whether the number of reconnection attempts exceeds a limit and whether the duration of the disconnection exceeds a threshold, thereby effectively avoiding resource waste and ineffective attempts, and enhancing system scheduling rationality and reconnection efficiency.

[0027] S2. If the retry flag value indicates that retry is allowed, the central server queries a pre-stored communication resource table to determine whether there is a valid communication resource corresponding to the IoT device; The valid communication resource includes at least one of the following: a connection handle, a protocol adapter instance, or a communication proxy object, and is generated and recorded when the central server and the IoT device are successfully connected for the first time.

[0028] In step S2, the present application implements a communication resource validity determination mechanism. This mechanism requires that, upon determining that a retry is permitted, the central server further queries a pre-stored communication resource table to determine whether valid communication resources exist for the current IoT device. These resources include, but are not limited to, connection handles, protocol adapter instances, or communication proxy objects. These resources are generated and recorded upon the first successful connection between the central server and the IoT device. This mechanism offers significant technical advantages. First, it effectively avoids resource waste and conflicts. In a large-scale device cluster environment, the communication resource status of different devices may be at different stages, for example, some connections may have been released, while others may remain in a half-closed or suspended state. Failure to determine resource status and rashly initiating a reconnection operation can lead to communication interface anomalies, thread conflicts, or duplicate connections, and in severe cases, even system-level anomalies. By preemptively confirming resource validity, subsequent operations are ensured to be based on available resources, fundamentally improving the success rate of reconnection operations and system stability. Second, this mechanism enables efficient reuse of communication resources. In some disconnection scenarios, communication resources are not completely released and can still be re-bound for use, avoiding the repeated creation of connection instances or protocol adapters, thereby reducing system overhead, speeding up reconnection, and improving the responsiveness of the highway system. Especially in scenarios where a large number of devices are disconnected at the same time, effective resource reuse will greatly improve the overall reconnection efficiency. In addition, the preset communication resource table, as a state cache maintained by the central server, also provides the basic conditions for the subsequent introduction of connection state tracking, dynamic management of resource pools, load balancing scheduling and other capabilities into the system, giving the highway system good scalability and adaptability. Therefore, by setting up the communication resource validity judgment mechanism in S2, not only the recovery capability and connection efficiency of the highway system in large-scale disconnection scenarios are improved, but also the refined control capability of resource management is enhanced.

[0029] S3. If there is a valid communication resource corresponding to the IoT device, increment a counting variable recording the number of reconnections of the IoT device to update the current number of reconnections. The reconnection count variable, a core control parameter, provides the foundation for dynamically calculating the delay time. Subsequent step S4 of this application introduces a dynamic backoff mechanism based on the number of reconnections. The greater the number of reconnections, the longer the corresponding delay time, thus creating an adaptive exponential backoff effect. Without this count variable, the delay rhythm cannot be adjusted according to the actual retry situation, and the highway system's backoff mechanism loses its dynamic control capabilities. Therefore, step S3 is a key prerequisite for the precise execution of the subsequent delay algorithm. Secondly, this counting mechanism provides state awareness and behavioral feedback capabilities. In a large-scale device cluster, a single device may frequently attempt to reconnect due to poor network quality, resource conflicts, or frequent failures. By recording its reconnection count, it can help determine whether the device is in an abnormal state, providing important input for the highway system's subsequent implementation of abnormal device identification, policy adjustment, or alarm modules. For example, if an IoT device's reconnection count is significantly higher than the average, the highway system can proactively limit its further attempts or place it in a waiting queue, improving overall resource allocation efficiency. Furthermore, recording the number of reconnections has operational and maintenance value and statistical data value. In subsequent analysis and maintenance, this data can be used to generate key operation and maintenance indicators such as connection success rate, average reconnection times, and abnormal retry rate. It can assist the highway system in optimizing and iterating communication strategies, and also help discover network bottlenecks or hidden equipment failures.

[0030] S4. If the current number of reconnections does not exceed the preset maximum reconnection threshold, then obtain the delay time corresponding to the current number of reconnections based on the preset dynamic correction factor, the preset maximum allowable delay time, the preset jitter factor, and the preset initial reconnection delay time or the previously obtained delay time corresponding to the last number of reconnections; Optionally, in some embodiments of the present application, see Figure 3 , the S4 specifically includes: S41. If the current number of reconnections does not exceed the preset maximum number of reconnections threshold, then according to the preset dynamic correction factor, the preset maximum allowable delay time, and the preset initial reconnection delay time or the delay time corresponding to the previous number of reconnections obtained in advance, obtain the corrected delay time corresponding to the current number of reconnections; preferably, in some embodiments of the present application, the S41 specifically includes: if the current number of reconnections does not exceed the preset maximum number of reconnections threshold, then according to the preset dynamic correction factor, the preset maximum allowable delay time, and the preset initial reconnection delay time or the delay time corresponding to the previous number of reconnections obtained in advance, use formula (1) to calculate the corrected delay time corresponding to the current number of reconnections; the formula (1) is: delay t =min(delay x ×factor, maxDelay); t is the current number of reconnections; delay t is the correction delay time corresponding to the current number of reconnections; factor is the pre-set dynamic correction factor; maxDelay is the pre-set maximum allowable delay time; when t=1, delay x is the preset initial reconnection delay time; when t>1, delay x The delay time corresponding to the last reconnection number obtained in advance.

[0031] S42: Obtain the delay time corresponding to the current number of reconnection times based on the corrected delay time corresponding to the current number of reconnection times and a preset jitter factor.

[0032] Preferably, in some embodiments of the present application, the step S42 specifically includes: modifying the delay time corresponding to the current number of reconnections t and the preset jitter factor jitter, the normal distribution probability density function expressed by formula (2) is used to construct a delay time distribution model, and the actual delay time corresponding to the current reconnection number t is calculated through this distribution model; The formula (2) is:

[0033] Represents the probability density when the delay time is x; x is the delay time variable of this reconnection operation; Indicates the corrected delay time delay corresponding to the current number of reconnections t t ; Represents the standard deviation, which is ×jitter; jitter is the jitter factor; exp is the exponential function; =delayt 、 =delay t The normal distribution constructed with ×jitter as the parameter uses random sampling to generate a delay time value x. The value of x is the delay time corresponding to the current reconnection number t.

[0034] This application dynamically calculates the reconnection delay corresponding to the current number of reconnections based on multiple parameters, including the current number of reconnections, a dynamic correction factor, the maximum allowed delay, a jitter factor, and the initial reconnection delay. This mechanism offers significant advantages over traditional fixed-delay strategies or simple linear backoff mechanisms in terms of scheduling efficiency, system stability, and large-scale control capabilities.

[0035] First, step S4 implements a dynamic delay control strategy to adaptively adjust the reconnection rhythm. As the number of IoT device reconnections increases, the waiting time is gradually extended, forming a gradual reconnection mechanism. This prevents multiple devices from frequently and simultaneously initiating connection requests within a short period of time, effectively reducing network resource competition and server-side load, preventing communication storms and system avalanches, and significantly improving stability and robustness in large-scale scenarios.

[0036] Specifically in step S41, this application constructs a mathematical model delay by introducing a dynamic correction factor and a maximum delay time limit, and combining the device's historical delay time or setting an initial delay. t = min(delay x × factor, maxDelay) to obtain the corrected delay time corresponding to the current number of reconnections. This method has the following technical advantages: First, a correction factor is introduced to allow the delay time to increase exponentially, forming an exponential backoff mechanism, which can more quickly reduce the interference of failed reconnections on the system. Second, a maximum delay limit (maxDelay) is introduced to prevent the delay time from increasing indefinitely, ensuring the timeliness of the reconnection behavior. Third, the correction logic recursively references the delay value of the previous reconnection result, giving the mechanism memory and self-adjustment capabilities, which can better cope with complex network fluctuations.

[0037] In step S42, the present application further calculates the actual reconnection delay time for execution by combining the jitter factor jitter on the basis of the correction delay time by constructing a normal distribution probability model and adopting a random sampling method. This design has important engineering significance: first, by introducing a normal perturbation mechanism, it generates a waiting time with slight differences for each device without destroying the overall delay trend, thereby decentralizing the originally concentrated and intensive reconnection operations and significantly reducing the risk of communication congestion caused by concurrent reconnections; secondly, the mechanism is highly coupled with the current reconnection state of the device, and the delay value always fluctuates around the device-specific correction time point, ensuring the fairness and rationality of the reconnection scheduling; finally, the mechanism has strong adaptability to the deployment environment, and is suitable for actual application scenarios with dynamic networks, non-stable connection environments, and uneven device loads, and has good versatility and flexibility.

[0038] In step S42, the delay time is modified by constructing t is the mean , with delay t × jitter is the standard deviation The normal distribution function of the network is used, and random sampling is used to generate the actual delay time x used to perform the reconnection operation. This mechanism not only integrates statistical methods and engineering scheduling strategies, but also significantly improves the system's scheduling balance and robustness in high-concurrency disconnection and recovery scenarios. First, the deterministic flaws of traditional exponential backoff or linear backoff strategies are overcome through the use of normal distribution perturbations. In traditional backoff strategies, all IoT devices often have the same or very similar delay times for the same number of reconnections, which can easily cause reconnection time overlap and concentrated reconnection operations, leading to instantaneous load peaks in the system. The normal distribution perturbation mechanism constructed in this application, on the other hand, allows devices to produce subtle and unpredictable random differences through natural sampling based on the same corrected delay. This effectively reduces the probability of a large number of devices reconnecting "simultaneously", thereby achieving load discretization during the reconnection process and mitigating concurrency shocks. Second, this mechanism is highly adaptive and adjustable. The degree of discreteness of the sampling delay can be flexibly controlled by adjusting the jitter parameter (i.e., the scaling factor of the standard deviation). For example, increasing the jitter value when the system load is high can expand the time distribution range of the reconnection delay, thereby further distributing the request load; when the network status is stable or the number of devices is small, the jitter can be reduced, making the reconnection more centralized and completed faster. This adjustment mechanism not only meets the scheduling needs in different scenarios, but also enables the solution to have the ability of dynamic optimization and intelligent regulation. Third, the mechanism has a good theoretical basis and feasibility. As a model widely used in probability statistics and engineering modeling, the normal distribution has stable properties, simple calculations, and low implementation costs. Especially in embedded edge devices or low-power nodes, this solution can quickly generate disturbance values ​​through simple mathematical transformations or table lookups, with the advantages of low complexity and high efficiency.

[0039] S5. After the delay time corresponding to the current number of reconnection times has expired, a reconnection operation is initiated to the IoT device through the effective communication resource to obtain a reconnection operation result.

[0040] In this embodiment, the method further includes: S6, if the reconnection operation result is failure, repeating steps S1-S5 until the reconnection operation result is success.

[0041] In this embodiment, in step S5, the application proposes that after the delay time corresponding to the current reconnection count expires, the central server initiates a reconnection operation for the disconnected IoT device based on previously confirmed valid communication resources. This mechanism, with clear timing control logic and resource management pre-emptive mechanisms, has significant engineering advantages and scheduling value in the communication reestablishment scenario of large-scale device clusters.

[0042] First, by waiting for the delay time window to end before initiating a reconnection, it can be ensured that the device attempts to connect in an orderly manner according to the reasonable rhythm calculated in the early stage, avoiding multiple devices trying to connect in the same time period, which may cause communication channel congestion or resource competition conflicts, and greatly improving the concurrent access capability and service stability. At the same time, by synchronizing the delay control mechanism with the communication resource status, it is ensured that the reconnection operation is performed under the premise that the resources are ready and have the processing capacity, effectively preventing problems such as invalid connection attempts, response failures and thread accumulation, and improving communication efficiency and connection success rate. Secondly, this step emphasizes that valid communication resources must be called when initiating a reconnection, which means that the system avoids the blind reuse of resources with unknown status or released resources, reduces the connection failure rate, and lays the technical foundation for the introduction of subsequent resource recovery mechanisms, connection status identification mechanisms and connection pool management mechanisms, further improving the accuracy and controllability of resource management.

[0043] In step S6, the present application further proposes that when a reconnection operation fails, the system will automatically re-execute steps S1 to S5 until the connection is successful, thus building a complete, closed-loop communication recovery mechanism. This design has good fault tolerance and recovery stability. In actual scenarios where the deployment environment of IoT devices is complex and the communication link is unstable, a single reconnection is often not guaranteed to be successful. By setting up this automatic loop mechanism, it is possible to continuously attempt to connect until it succeeds, significantly enhancing the robustness and reliability of the system in the face of emergencies such as instantaneous channel interference and network fluctuations. More importantly, a logical closed loop is formed between step S6 and step S1. Instead of blind retry, each cycle is based on dynamically updated retry flag judgment, communication resource judgment, delay parameter update and disturbance mechanism, realizing an intelligent, rhythmic and feedback reconnection management strategy. This mechanism effectively prevents problems such as resource congestion and server overload caused by traditional "dead loop" reconnection, and ensures the overall recovery efficiency and stable operation of the system in large-scale device clusters in communication anomaly scenarios. To sum up, S5 and S6 constitute the core execution mechanism and fault-tolerant recovery mechanism in the communication method of this application. Through orderly delay control and automatic closed-loop retry, while ensuring the connection success rate, the risks of concurrency conflicts, communication congestion and resource waste are significantly reduced, ensuring that the device cluster can complete communication reconstruction smoothly, efficiently and safely even in extreme cases of large-scale simultaneous disconnection.

[0044] In some embodiments of the present application, the retry flag value is a value of continueTrying.

[0045] Preferably, in some embodiments of the present application, the value of the pre-set dynamic correction factor factor is a real value between 2.7 and 2.72; specifically, the value of the pre-set dynamic correction factor factor is 2.7182818284590451. The value of the pre-set jitter factor jitter is a real value between 0.1 and 0.12. Specifically, the value of the pre-set jitter factor jitter is 0.119626565582.

[0046] In a specific application of this embodiment, the initial reconnection delay time is obtained by: Based on a pre-trained machine learning model, the central server combines the historical operating data and current status feature data of disconnected IoT devices to dynamically predict the initial reconnection delay time, including: Collecting historical operation data and state feature data of the IoT device, and performing feature engineering processing on the historical operation data and current state feature data of the IoT device to form a feature vector; The historical operation data and status characteristic data of the IoT device include: historical mean time between failures, last failure time, recent failure times, historical availability, and priority of the IoT device; Among them, the historical mean time between failures refers to the average duration of the continuous normal operation cycle of the IoT device; the last failure time refers to the time point when the device most recently experienced an abnormality; the number of recent failures refers to the cumulative number of failures within a preset time window; the historical availability rate is the ratio of the cumulative time that the IoT device is in normal network connection with the central server within a preset statistical period to the total time of the preset statistical period; the priority of the IoT device indicates the relative importance level of the IoT device; Input the feature vector into a trained gradient boosting decision tree model, and the trained gradient boosting decision tree model outputs a prediction result as the initial reconnection delay time of the IoT device; The training data of the gradient boosting decision tree model includes a plurality of training samples, wherein each training sample includes a feature vector and an initial reconnection delay time corresponding to the feature vector.

[0047] In this implementation, a device-specific "initial reconnection delay" is generated through a machine learning model. Compared to traditional fixed values ​​(such as a uniform 5-second setting), this value more closely reflects the device's actual performance and health. For example, devices that frequently disconnect can be assigned a longer initial wait time to avoid impacting server resources; stable, high-priority devices can receive a shorter initial delay to quickly restore communication.

[0048] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0049] In this application, unless otherwise specified or limited, the terms "mounted," "connected," "connect," "fixed," etc. should be understood broadly. For example, they can refer to fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two components or interaction between two components. Those skilled in the art will understand the specific meanings of the above terms in this application based on the specific circumstances.

[0050] In this application, unless otherwise expressly specified or limited, when a first feature is “on” or “below” a second feature, it may mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. Moreover, when a first feature is “above”, “above”, or “above” a second feature, it may mean that the first feature is directly above or obliquely above the second feature, or simply means that the first feature is at a higher level than the second feature. When a first feature is “below”, “below”, or “below” a second feature, it may mean that the first feature is directly below or obliquely below the second feature, or simply means that the first feature is at a lower level than the second feature.

[0051] In the description of this specification, the description of the terms "one embodiment", "some embodiments", "embodiment", "example", "specific example" or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.

[0052] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A large-scale device cluster communication method, applied to a highway system, wherein the highway system includes a central server and a plurality of Internet of Things devices connected to the central server through a network, characterized in that: The method comprises: S1. When a network interruption or a reconnection operation fails between the central server and any IoT device, the central server obtains a retry flag value and determines whether to continue initiating a connection retry based on the retry flag value; S2. If the retry flag value indicates that retry is allowed, the central server queries a pre-stored communication resource table to determine whether there is a valid communication resource corresponding to the IoT device; S3. If there is a valid communication resource corresponding to the IoT device, increment a counting variable recording the number of reconnections of the IoT device to update the current number of reconnections. S4. If the current number of reconnections does not exceed the preset maximum reconnection threshold, then obtain the delay time corresponding to the current number of reconnections based on the preset dynamic correction factor, the preset maximum allowable delay time, the preset jitter factor, and the preset initial reconnection delay time or the previously obtained delay time corresponding to the last number of reconnections; S5. After the delay time corresponding to the current number of reconnection times has expired, a reconnection operation is initiated to the IoT device through the effective communication resource to obtain a reconnection operation result.

2. The large-scale device cluster communication method according to claim 1, characterized in that: The method further comprises: S6. If the reconnection operation result is failure, repeat steps S1-S5 until the reconnection operation result is success.

3. The large-scale device cluster communication method according to claim 2, characterized in that: The retry flag value is generated according to a pre-set retry strategy; The pre-set retry strategy includes: counting the current number of retries, and prohibiting retry if it exceeds a preset maximum reconnection number threshold; or detecting the duration of the network interruption between the central server and the IoT device, and prohibiting retry if it exceeds a timeout threshold.

4. The large-scale device cluster communication method according to claim 3, characterized in that: in, The valid communication resource includes at least one of the following: a connection handle, a protocol adapter instance, or a communication proxy object, and is generated and recorded when the central server and the IoT device are successfully connected for the first time.

5. The large-scale device cluster communication method according to claim 4, characterized in that: The retry flag value is the value of continueTrying.

6. The large-scale device cluster communication method according to claim 5, characterized in that: The S4 specifically includes: S41. If the current number of reconnections does not exceed the preset maximum reconnection number threshold, obtaining a corrected delay time corresponding to the current number of reconnections based on a preset dynamic correction factor, a preset maximum allowable delay time, and a preset initial reconnection delay time or a previously obtained delay time corresponding to the last number of reconnections; S42: Obtain the delay time corresponding to the current number of reconnection times based on the corrected delay time corresponding to the current number of reconnection times and a preset jitter factor.

7. The large-scale device cluster communication method according to claim 6, characterized in that: The S41 specifically includes: If the current number of reconnections does not exceed the preset maximum reconnection number threshold, then the corrected delay time corresponding to the current number of reconnections is calculated using formula (1) based on the preset dynamic correction factor, the preset maximum allowable delay time, and the preset initial reconnection delay time or the delay time corresponding to the previously obtained last reconnection number; The formula (1) is: delay t =min(delay x ×factor,maxDelay); t is the current number of reconnections; delay t The corrected delay time corresponding to the current number of reconnections; factor is a pre-set dynamic correction factor; maxDelay is the preset maximum allowed delay time; When t=1, delay x It is the preset initial reconnection delay time; When t>1, delay x The delay time corresponding to the last reconnection number obtained in advance.

8. The large-scale device cluster communication method according to claim 7, characterized in that: The S42 specifically includes: Corrected delay based on the current number of reconnections t and the preset jitter factor jitter, the normal distribution probability density function expressed by formula (2) is used to construct a delay time distribution model, and the actual delay time corresponding to the current reconnection number t is calculated through this distribution model; The formula (2) is: ； Represents the probability density when the delay time is x; x is the delay time variable of this reconnection operation; Indicates the corrected delay time delay corresponding to the current number of reconnections t t ; Represents the standard deviation, which is ×jitter; jitter is the jitter factor; exp is the exponential function; Among them, from =delay t 、 =delay t The normal distribution constructed with ×jitter as the parameter uses random sampling to generate a delay time value x. The value of x is the delay time corresponding to the current reconnection number t.

9. The large-scale device cluster communication method according to claim 8, characterized in that: The preset dynamic correction factor is a real value between 2.7 and 2.72; The preset jitter factor jitter value is a real value between 0.1 and 0.

12.

10. The large-scale device cluster communication method according to claim 9, characterized in that: The initial reconnection delay time is obtained by: Collecting historical operation data and status feature data of the IoT device, and performing feature engineering processing on the historical operation data and status feature data of the IoT device to form a feature vector; The feature vector is input into a trained gradient boosting decision tree model, and the trained gradient boosting decision tree model outputs a prediction result as the initial reconnection delay time of the IoT device.

Images