A method for communicating in a large cluster of devices

Abstract

The application relates to the technical field of Internet of Things communication, in particular to a large-scale device cluster communication method, which comprises the following steps: when network interruption occurs between a center server and any Internet of Things device or the reconnection operation result is failure, the center server acquires a retry flag value and judges whether to continue initiating connection retry; if the retry is allowed, the center server queries a communication resource table and judges whether there is valid communication resource corresponding to the Internet of Things device; if yes, a counting variable recording the reconnection times of the Internet of Things device is incremented to obtain the current reconnection times; if the current reconnection times do not exceed a maximum reconnection times threshold, a delay time corresponding to the current reconnection times is acquired according to a dynamic correction factor, a maximum allowed delay time, a jitter factor and an initial reconnection delay time or a delay time corresponding to the last reconnection times; after the delay time arrives, the reconnection operation is initiated to the Internet of Things device through the valid communication resource to obtain a reconnection operation result.

Description

TECHNICAL FIELD

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

[0002] In modern highway Internet of Things systems, large-scale device cluster communication has become a core requirement. With the rapid development of intelligent transportation infrastructure, the highway system needs to maintain stable communication with a large number of Internet of Things devices (such as roadside sensors, cameras, electronic signs, etc.) to realize real-time data collection, state monitoring and remote control. However, in actual deployment, due to network fluctuations, device failures, physical link interruptions and other reasons, the communication link between the center server and the Internet of Things devices may frequently interrupt. At this time, the system needs to recover communication through a reconnection mechanism, but the existing reconnection strategy has significant defects.

[0003] Currently, the common communication reconnection scheme usually adopts a fixed time interval hard-coded retry mechanism, such as initiating a reconnection request every fixed time interval (such as 5 seconds). Although this scheme is simple to implement, it has serious problems in the large-scale device cluster scenario: when the network is paralyzed in a large area or the devices are offline collectively, the center server will receive a large number of concurrent reconnection requests in a short time, causing the server resources (such as CPU, bandwidth, connection pool) to be momentarily occupied, forming a "retry storm". This not only increases the server pressure, but also may trigger an avalanche effect, causing normal business services to be delayed or even paralyzed due to resource competition. In addition, the fixed interval retry strategy cannot adapt to the dynamically changing network environment, for example, in the early stage of network recovery, too early or too intensive retries may exacerbate congestion, while too long a delay will cause communication recovery to lag, affecting system real-time performance.

[0004] Although some improved schemes in the prior art adjust the retry interval through exponential backoff, they only rely on a simple multiple growth rule (such as doubling the delay for each retry), and lack the ability to dynamically allocate actual network status and server load. For example, when the network fluctuates temporarily, the long backoff delay will result in low communication recovery efficiency; while in a high-load scenario, the fixed parameters of the backoff algorithm may not effectively disperse the retry pressure. In addition, existing schemes usually ignore the effective management of communication resources (such as connection handles, protocol adapter instances), and if invalid resources are not released in time, it may further cause memory leakage or resource exhaustion. More seriously, the traditional reconnection mechanism lacks adaptability to intermittent network failures. For example, in scenarios such as highway tunnels, remote road sections, etc., where the network signal is unstable, devices may frequently disconnect, but the existing technology cannot distinguish between temporary interruptions and permanent failures, resulting in too many invalid retries or too early giving up on devices that can be recovered. This limitation not only reduces communication reliability, but also increases operational costs. SUMMARY

[0005] (One) technical problems to be solved

[0006] In view of the above-mentioned defects and deficiencies of the prior art, the present application provides a large-scale device cluster communication method, which solves the technical problems of excessive server pressure and low network recovery efficiency caused by fixed retry interval in the prior art.

[0007] (Two) technical solutions

[0008] In order to achieve the above-mentioned purpose, the main technical solution adopted by the present application includes:

[0009] The embodiment of the present application provides a large-scale device cluster communication method, which is applied to a highway system, the highway system includes a center server and a plurality of Internet of Things devices network connected with the center server, and the method includes:

[0010] S1, when network interruption occurs between the center server and any Internet of Things device or the reconnection operation result is failure, the center server acquires a retry flag value, and judges whether to continue to initiate connection retry according to the retry flag value;

[0011] S2, if the retry flag value is allowed retry, the center server queries a pre-stored communication resource table to judge whether there is valid communication resource corresponding to the Internet of Things device;

[0012] S3, if there is valid communication resource corresponding to the Internet of Things device, the count variable recording the reconnection times of the Internet of Things device is incremented to update the current reconnection times;

[0013] S4, if the current reconnection times does not exceed the preset maximum reconnection times threshold, the delay time corresponding to the current reconnection times is acquired according to the pre-set dynamic correction factor, the pre-set maximum allowed delay time, the pre-set jitter factor and the pre-set initial reconnection delay time or the delay time corresponding to the last reconnection times acquired in advance;

[0014] S5, after the delay time corresponding to the current reconnection times arrives, the reconnection operation is initiated to the Internet of Things device through the valid communication resource to obtain the reconnection operation result.

[0015] Preferably, in some embodiments of the present application, the method further includes:

[0016] S6, if the reconnection operation result is failure, steps S1-S5 are repeated until the reconnection operation result is success.

[0017] Preferably, in some embodiments of the present application,

[0018] The retry flag value is generated according to a preset retry strategy.

[0019] The preset retry strategy includes: counting the current retry times, and if the preset maximum reconnection times threshold is exceeded, the retry is prohibited; or, detecting the duration of network interruption between the center server and the Internet of Things device, and if the timeout threshold is exceeded, the retry is prohibited.

[0020] Preferably, in some embodiments of the present application,

[0021] The effective communication resource includes at least one of the following: a connection handle, a protocol adapter instance, or a communication agent object, and is generated and recorded when the center server and the Internet of Things device are first successfully connected.

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

[0023] Preferably, in some embodiments of the present application, the S4 specifically includes:

[0024] S41, if the current reconnection times do not exceed the preset maximum reconnection times threshold, the current reconnection times corresponding correction delay time is obtained according to the preset dynamic correction factor, the preset maximum allowed delay time, and the preset initial reconnection delay time or the delay time corresponding to the last reconnection times obtained in advance.

[0025] S42, based on the current reconnection times corresponding correction delay time and the preset jitter factor, the current reconnection times corresponding delay time is obtained.

[0026] Preferably, in some embodiments of the present application, the S41 specifically includes:

[0027] If the current reconnection times do not exceed the preset maximum reconnection times threshold, the current reconnection times corresponding correction delay time is calculated and obtained by using formula (1) according to the preset dynamic correction factor, the preset maximum allowed delay time, and the preset initial reconnection delay time or the delay time corresponding to the last reconnection times obtained in advance.

[0028] The formula (1) is:

[0029] delay t =min(delay x ×factor,maxDelay);

[0030] t is the current reconnection times.

[0031] delay t is a correction delay time corresponding to the current reconnection number t;

[0032] factor is a pre-set dynamic correction factor;

[0033] maxDelay is a pre-set maximum allowed delay time;

[0034] delay x is a pre-set initial reconnection delay time;

[0035] delay x is a pre-acquired delay time corresponding to the last reconnection number.

[0036] Preferably, in some embodiments of the present application, the S42 specifically comprises:

[0037] based on the correction delay time delay t corresponding to the current reconnection number t and a pre-set jitter factor jitter, a normal distribution probability density function represented 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 the distribution model;

[0038] The formula (2) is:

[0039]

[0040] represents the probability density when the delay time is x; x is the delay time variable of the current reconnection operation; delay t corresponding to the current reconnection number t; represents the standard deviation, and the value is × jitter; jitter is a jitter factor; exp is an exponential function;

[0041] Among them, from the normal distribution constructed with = delay t , = delay t × jitter as parameters, a delay time value x is generated in a random sampling manner, and the value of x is the delay time corresponding to the current reconnection number t.

[0042] 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;

[0043] The value of the preset jitter is a real value between 0.1 and 0.12.

[0044] Preferably, in some embodiments of the application, the initial reconnection delay time is obtained by:

[0045] The central server dynamically predicts the initial reconnection delay time based on a pre-trained machine learning model, combined with historical running data and current state feature data of the disconnected Internet of Things device, specifically including:

[0046] Collecting the historical running data and state feature data of the Internet of Things device, and performing feature engineering processing on the historical running data and current state feature data of the Internet of Things device to form a feature vector;

[0047] The historical running data and state feature data of the Internet of Things device include: historical average failure-free time, last failure time, recent failure times, historical availability rate, and priority of the Internet of Things device.

[0048] The historical average failure-free time refers to the average duration of continuous normal operation period of the Internet of Things device; the last failure time refers to the time point of the most recent abnormality of the device; the recent failure times refer to the cumulative failure times within a preset time window; the historical availability rate is the ratio of the cumulative duration of normal network connection with the central server to the total duration of the preset statistical period within the preset statistical period; and the priority of the Internet of Things device represents the relative importance level of the Internet of Things device.

[0049] The feature vector is input into the trained gradient boosting decision tree model, and the prediction result output by the trained gradient boosting decision tree model is used as the initial reconnection delay time of the Internet of Things device.

[0050] 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.

[0051] (Three) beneficial effects

[0052] The large-scale device cluster communication method provided by the embodiments of the present application can intelligently calculate an optimal reconnection interval according to the current network state, server load and historical reconnection records by introducing a dynamic delay adjustment mechanism in the reconnection strategy, thereby avoiding retry storm. By combining a jitter factor and a dynamic correction factor, the reconnection request is uniformly distributed in the time dimension, thereby effectively relieving the instantaneous pressure of the server. Meanwhile, by maintaining and managing the communication resource table, it is ensured that valid communication resources are used for each reconnection, thereby avoiding resource waste caused by invalid connection. In this way, even in the extreme case of large-area network fluctuation and collective disconnection of device clusters, stable, efficient and adaptive connection recovery can still be achieved, thereby guaranteeing the communication reliability and service stability of the entire highway Internet of Things system. BRIEF DESCRIPTION OF DRAWINGS

[0053] Figure 1 FIG. 1 is a flowchart of a large-scale device cluster communication method according to an embodiment of the present application;

[0054] Figure 2 FIG. 2 is a structural diagram of a highway system according to an embodiment of the present application;

[0055] Figure 3 FIG. 3 is a flowchart of a method for obtaining a delay time corresponding to a current reconnection number according to an embodiment of the present application. DETAILED DESCRIPTION

[0056] In order to better explain the present application and facilitate understanding, the present application is described in detail in the specific embodiments below with reference to the accompanying drawings.

[0057] In the related art, for the communication reconnection problem of large-scale Internet of Things devices after network interruption, the existing technologies can be mainly summarized as the following several types of solutions:

[0058] The first type is a communication recovery mechanism based on a fixed reconnection strategy. This type of method usually increases the waiting time after each reconnection failure according to a preset exponential backoff or linear increasing strategy after the Internet of Things terminal is disconnected. For example, after the system sets the initial delay time and the maximum number of retries, the reconnection interval is increased in turn 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 running state and communication resource occupation, and is prone to cause concentrated reconnection storm in large-area disconnection or system load peak, aggravate network congestion, and even cause the center server to crash. In addition, the fixed strategy cannot adapt to the differences in device priority, fault frequency, etc., and has low reconnection efficiency, long recovery time and poor communication reliability.

[0059] The second type is a reconnection control method based on task scheduling priority. This type of method adjusts the reconnection order or delay time by predefining the communication priority, response level or task level for the Internet of Things devices, and adjusting the reconnection order or delay time accordingly. Although this method alleviates the problem of excessive reconnection delay for critical devices to some extent, it relies on manual priority setting and lacks intelligent adjustment mechanism, making it difficult to dynamically adapt to device state changes. At the same time, its reconnection strategy usually does not consider historical running stability and network connection quality data, resulting in weak strategy generalization ability and insufficient control ability when facing sudden network anomalies.

[0060] The third type is a reconnection throttling mechanism based on central server unified scheduling and time window control. This type of method maintains a connection state table and resource pool on the central server side, and uses flow limiting or time slicing strategy to control device reconnection behavior in batches, avoiding centralized peak. However, when facing tens of thousands of concurrent disconnected devices, this type of mechanism has fixed limitations in scheduling granularity, resource matching and delay strategy, lacks individual modeling of single device state and historical connection performance, and the reconnection scheduling is still rough, making it difficult to guarantee system recovery speed and overall robustness.

[0061] Therefore, the communication method for large-scale device clusters provided by the embodiments of the present application innovatively introduces a machine learning model based on historical running data and state characteristics, dynamically predicts the optimal initial reconnection delay time for each disconnected device, and combines the communication resource state and reconnection times on the central server side to generate a personalized reconnection strategy with adaptability in real time. At the same time, a jitter factor introduction method based on normal perturbation mechanism is designed, so that the actual delay of each reconnection is randomly disturbed based on the theoretical value, further reducing the risk of resource competition and communication congestion caused by large-scale simultaneous reconnection. This scheme combines distributed intelligent decision-making ability and central unified control ability, not only significantly improves the recovery speed after large-scale disconnection, but also has good scalability and deployment adaptability, especially suitable for scenarios such as highway Internet of Things, traffic monitoring, industrial edge devices, etc. with large device scale, complex operating environment and high communication stability requirements. The reconnection strategy is accurate and efficient, which can effectively improve the overall robustness and stability of the system.

[0062] In order to better understand the above technical solutions, the exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present application are shown in the 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. On the contrary, these embodiments are provided to enable a clearer, more thorough understanding of the present application and to convey the complete scope of the present application to those skilled in the art.

[0063] Figure 1Figure 1 is a flowchart of a communication method for a large-scale device cluster according to an embodiment of the present application. The communication method for a large-scale device cluster according to an embodiment of the present application is applied to a highway system, as shown in Figure 2, which includes a center server and a plurality of Internet of Things (IoT) devices connected to the center server. Figure 2 As shown in Figure 1, the communication method for a large-scale device cluster includes the following steps. Figure 1

[0064] S1, when a network interruption occurs between the center server and any IoT device or the result of a reconnection operation is failure, the center server acquires a retry flag value and determines whether to continue initiating connection retry according to the retry flag value.

[0065] 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 retry times, and if the number of retry times exceeds a pre-set maximum reconnection times threshold, then the retry is prohibited; or, detecting the duration of the network interruption between the center server and the IoT device, and if the duration exceeds a timeout threshold, then the retry is prohibited.

[0066] In this embodiment, when the center server detects a network interruption or a reconnection failure with an IoT device, the center server generates a retry flag value according to a pre-set retry strategy and determines whether to continue initiating connection retry according to the retry flag value. The retry strategy includes counting the number of reconnection attempts and detecting whether the duration of the network interruption exceeds a threshold, thereby effectively avoiding resource waste and invalid attempts and enhancing the rationality of system scheduling and the efficiency of reconnection.

[0067] S2, if the retry flag value allows retry, the center server queries a pre-stored communication resource table to determine whether there is an effective communication resource corresponding to the IoT device.

[0068] The effective communication resource includes at least one of the following: a connection handle, a protocol adapter instance, or a communication agent object, and is generated and recorded when the center server and the IoT device are first successfully connected.

[0069] ​In step S2, the present application sets a communication resource validity judgment mechanism, i.e., the center server further queries the pre-stored communication resource table to determine whether there is an effective communication resource corresponding to the current Internet of Things device under the premise of judging to allow retry. The resource includes but is not limited to: connection handle, protocol adapter instance or communication agent object, and these resources are generated and recorded when the center server and the Internet of Things device are first successfully connected. This mechanism has significant technical advantages. First, this judgment mechanism effectively avoids resource waste and conflict. In a large-scale device cluster environment, the communication resource states of different devices may be in different stages, such as part of the connection has been released, part of the connection is still in a semi-closed or suspended state. If the resource state is not judged, the reconnection operation is launched recklessly, which may cause communication interface exception, thread conflict or repeated connection, and may even cause system-level exception. By confirming in advance whether the resource is valid, it is ensured that the subsequent operation is established on the basis of available resources, which fundamentally improves the success rate of the reconnection operation and the system stability. Secondly, this mechanism realizes the efficient reuse of communication resources. In the partial disconnection scenario, the communication resources have not been completely released and can still be reused, avoiding repeated creation of connection instances or protocol adapters, thereby reducing system overhead, speeding up the reconnection speed, and improving the highway system response capability. Especially in the scenario of large-scale device disconnection, effective resource reuse will greatly improve the overall reconnection efficiency. In addition, the pre-set communication resource table as the state cache maintained by the center server also provides a basic condition for the system to introduce connection state tracking, resource pool dynamic management, load balancing scheduling and other capabilities in the future, so that the highway system has good scalability and adaptability. Therefore, by setting the communication resource validity judgment mechanism in S2, the recovery capability and connection efficiency of the highway system in the large-scale disconnection scenario are improved, and the fine control ability of resource management is also enhanced.

[0070] S3、 If there is an effective communication resource corresponding to the Internet of Things device, increment the count variable recording the reconnection times of the Internet of Things device to update the current reconnection times;

[0071] The reconnection count variable serves as a core control parameter and provides basic support for dynamically calculating the delay time. The subsequent step S4 of the present application introduces a dynamic backoff mechanism based on the number of reconnections. The more the number of reconnections, the longer the corresponding delay time, thereby forming an adaptive exponential backoff effect. If the count variable is lacking, the delay rhythm cannot be adjusted according to the actual retry situation, and the highway system backoff mechanism loses its dynamic regulation ability. Therefore, step S3 is a key prerequisite for the accurate execution of the subsequent delay algorithm. Secondly, the count mechanism has the ability of state perception and behavior feedback. In a large-scale device cluster, a single device may frequently attempt to reconnect due to poor network quality, resource conflicts, or frequent faults. By recording the number of reconnections, it can assist in determining whether the device is in an abnormal state, thereby providing important input signals for the subsequent introduction of abnormal device identification, strategy adjustment, or alarm modules by the highway system. For example, when the number of reconnections of a certain Internet of Things device is much higher than the average level, the highway system can actively limit its continued attempts or transfer it to the observation queue, thereby improving the overall resource allocation efficiency. In addition, the record of the number of reconnections also has operation and maintenance value and data statistical value. In the later analysis and maintenance, this data can be used to generate key operation and maintenance indicators such as connection success rate, average number of reconnections, and abnormal retry rate, which can assist the highway system in optimizing and iterating the communication strategy, and also help to find network bottlenecks or hidden device faults.

[0072] S4, if the current number of reconnections does not exceed the preset maximum number of reconnection threshold, obtaining the delay time corresponding to the current number of reconnections according to the pre-set dynamic correction factor, the pre-set maximum allowed delay time, the pre-set initial reconnection delay time, or the delay time corresponding to the pre-acquired last number of reconnections;

[0073] Optionally, in some embodiments of the present application, referring to Figure 3 , the S4 specifically comprises:

[0074] S41, if the current number of reconnections does not exceed the preset maximum number of reconnection threshold, obtaining the corrected delay time corresponding to the current number of reconnections according to the pre-set dynamic correction factor, the pre-set maximum allowed delay time, and the pre-set initial reconnection delay time or the delay time corresponding to the pre-acquired last number of reconnections; preferably, in some embodiments of the present application, the S41 specifically comprises: if the current number of reconnections does not exceed the preset maximum number of reconnection threshold, the corrected delay time corresponding to the current number of reconnections is calculated and obtained according to the pre-set dynamic correction factor, the pre-set maximum allowed delay time, and the pre-set initial reconnection delay time or the delay time corresponding to the pre-acquired last number of reconnections by using formula (1); the formula (1) is: delay t =min(delay x= delay

[0075] t is the current reconnection times; delay t is the modified delay time corresponding to the current reconnection times; factor is the pre-set dynamic correction factor; maxDelay is the pre-set maximum allowed delay time; when t = 1, delay x is the pre-set initial reconnection delay time; when t > 1, delay x is the delay time corresponding to the last reconnection times obtained in advance.

[0076] S42, based on the modified delay time corresponding to the current reconnection times and the pre-set jitter factor, obtaining the delay time corresponding to the current reconnection times.

[0077] Preferably, in some embodiments of the application, the S42 specifically comprises: based on the modified delay time delay t corresponding to the current reconnection times and the pre-set jitter factor jitter, using the normal distribution probability density function represented by formula (2) to construct a delay time distribution model, and calculating the actual delay time corresponding to the current reconnection times t through the distribution model.

[0078] The formula (2) is:

[0079]

[0080] , which represents the probability density when the delay time is x; x is the delay time variable of this reconnection operation; , which represents the modified delay time delay t corresponding to the current reconnection times t; , which represents the standard deviation, and the value is × jitter; jitter is the jitter factor; exp is the exponential function; wherein, from = delay t , = delay t × jitter is the parameter constructed by the normal distribution, a delay time value x is generated by using random sampling method, and the value of x is the delay time corresponding to the current reconnection times t.

[0081] Based on the current reconnection times, the dynamic correction factor, the maximum allowed delay time, the jitter factor, the initial reconnection delay time and other parameters, the application dynamically calculates the reconnection delay time corresponding to the current reconnection times. Compared with the traditional fixed delay strategy or simple linear backoff mechanism, this mechanism has significant advantages in scheduling efficiency, system stability and large-scale control ability.

[0082] Firstly, step S4 realizes adaptive adjustment of the reconnection rhythm by introducing a dynamic delay control strategy. As the number of reconnections of the Internet of Things device increases, the waiting time is gradually extended, forming a gradual retreat reconnection mechanism, thereby avoiding multiple devices from frequently initiating connection requests at the same time in a short period of time, effectively reducing network resource competition and server-side load pressure, preventing the occurrence of communication storm and system avalanche phenomenon, and significantly improving the stability and robustness in large-scale scenarios.

[0083] Specifically, in step S41, the present application introduces a dynamic correction factor and a maximum delay time limit, and combines the historical delay time of the device or sets an initial delay to construct a mathematical model delay t = min(delay x × factor, maxDelay), which is used to obtain the corrected delay time corresponding to the current reconnection number. This method has the following technical advantages:

[0084] Firstly, the introduction of the correction factor (factor) makes the delay time grow exponentially, forming an exponential backoff mechanism, which can more quickly reduce the interference of failed reconnections on the system; secondly, the introduction of the maximum delay upper limit (maxDelay) prevents the delay time from growing indefinitely, ensuring the timeliness of the reconnection behavior; thirdly, the recursive reference of the delay value of the last reconnection result in the correction logic makes the mechanism have memory and self-adjusting ability, which can better cope with complex network fluctuations.

[0085] In step S42, the present application further combines the jitter factor jitter on the basis of the corrected delay time, calculates the actual reconnection delay time used for execution by constructing a normal distribution probability model and using a random sampling method. This design has important engineering significance: firstly, it introduces a normal perturbation mechanism to generate waiting times with slight differences for each device without destroying the overall delay trend, which can significantly reduce 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 specific correction time point of the device, ensuring the fairness and rationality of reconnection scheduling; finally, the mechanism has strong adaptability to deployment environments and is suitable for dynamic networks, non-stationary connection environments, and actual application scenarios with uneven device load, and has good universality and flexibility.

[0086] In step S42, the normal distribution probability model is constructed with the corrected delay time delay t as the mean , and delay t × jitter as the standard deviation a normal distribution function, and a random sampling method is used to generate the delay time x actually used to perform the reconnection operation. This mechanism not only combines statistical methods and engineering scheduling strategies, but also significantly improves the scheduling balance and robustness of the system in a high-concurrency disconnection recovery scenario. First, the deterministic defect of the traditional exponential backoff or linear backoff strategy is broken by the normal distribution disturbance method. In the traditional backoff strategy, all Internet of Things devices have the same or very close delay time at the same reconnection number, which can easily cause the reconnection time to overlap and trigger the reconnection operation, resulting in a transient load peak in the system. The normal distribution disturbance mechanism constructed in the present application generates subtle and unpredictable random differences based on the same modified delay, effectively reducing the probability of a large number of devices reconnecting at the same time, thereby achieving load discretization and concurrent impact mitigation in the reconnection process. Second, the mechanism has high adaptability and adjustability. By adjusting the jitter parameter (i.e., the standard deviation factor), the dispersion degree of the sampled delay can be flexibly controlled. For example, increasing the jitter value when the system load is high can expand the time distribution range of the reconnection delay, thereby further dispersing the request load; when the network state is stable or the number of devices is small, the jitter can be reduced to make the reconnection more concentrated and faster. This adjustment mechanism not only meets the scheduling needs of different scenarios, but also enables the scheme to have dynamic optimization and intelligent control capabilities. Third, the mechanism has a good theoretical basis and realizability. 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, the present application can quickly generate disturbance values through simple mathematical transformations or lookup tables, with the advantages of low complexity and high efficiency.

[0087] S5. After the delay time corresponding to the current reconnection number arrives, initiate a reconnection operation to the Internet of Things device through the effective communication resource, and obtain a reconnection operation result.

[0088] In this embodiment, the method further includes: S6. If the reconnection operation result is a failure, then repeat steps S1-S5 until the reconnection operation result is a success.

[0089] In step S5, the present application proposes initiating a reconnection operation to the disconnected Internet of Things device based on the previously confirmed effective communication resource after the delay time corresponding to the current reconnection number arrives. This mechanism has clear timing control logic and resource management pre-mechanism, and has significant engineering advantages and scheduling value in the communication reconstruction scenario of large-scale device clusters.

[0090] Firstly, by waiting for the end of the delay time window before initiating reconnection, it can be ensured that the device attempts to connect in an orderly manner at a reasonable pace calculated in advance, avoiding the congestion of communication channels or resource competition conflicts caused by multiple devices attempting to connect at the same time, greatly improving the concurrent access capability and service stability. At the same time, through the synchronization of the delay control mechanism and the communication resource state, it is ensured that the execution of the reconnection operation is carried out on the premise that the resources are ready and have 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 reconnection, which means that the system avoids blind reuse of resources whose state is unknown or has been released, reduces the connection failure rate, and lays a technical foundation for introducing subsequent resource recycling mechanisms, connection state identification mechanisms, and connection pool management mechanisms, further improving resource management accuracy and controllability.

[0091] In step S6, the present application further proposes that when the result of a certain reconnection operation is failure, the system will automatically re-execute steps S1 to S5 until the connection is successful, building a complete and closed-loop communication recovery mechanism. This design has good fault tolerance and recovery stability. In the actual scene of complex deployment environment of Internet of Things devices and unstable communication link, a single reconnection cannot guarantee success. By setting this automatic loop mechanism, it can continuously attempt to connect until success, significantly enhancing the robustness and reliability of the system in the face of sudden events such as transient channel interference and network fluctuations. More importantly, steps S6 and S1 form a logical closed loop, and it is not a blind retry, but each cycle is based on dynamic update of 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 resource blocking, server overload and other problems caused by traditional "dead loop" reconnection, ensuring the overall recovery efficiency and stable operation of large-scale device clusters in communication abnormal scenarios. In summary, S5 and S6 constitute the core execution mechanism and fault tolerance recovery mechanism of the communication method of the present application. Through orderly delay control and automatic closed-loop retry, the connection success rate is guaranteed while significantly reducing the risk of concurrent conflict, communication congestion and resource waste, ensuring that the device cluster can complete communication reconstruction smoothly, efficiently and safely even in the extreme case of large-scale simultaneous disconnection.

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

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

[0094] In a specific application of the present embodiment, the initial reconnection delay time is obtained by the following method:

[0095] The central server dynamically predicts the initial reconnection delay time based on a pre-trained machine learning model, in combination with historical running data and current state feature data of the disconnected Internet of Things device, specifically including:

[0096] The historical running data and state feature data of the Internet of Things device are collected, and the historical running data and current state feature data of the Internet of Things device are processed by feature engineering to form a feature vector;

[0097] The historical running data and state feature data of the Internet of Things device include: historical average failure-free time, last failure time, recent failure times, historical availability rate, and priority of the Internet of Things device.

[0098] The historical average failure-free time refers to the average duration of continuous normal operation period of the Internet of Things device; the last failure time refers to the time point of the most recent abnormality of the device; the recent failure times refer to the cumulative failure times within a preset time window; the historical availability rate is the ratio of the cumulative duration of normal network connection with the central server to the total duration of the preset statistical period within the preset statistical period; and the priority of the Internet of Things device represents the relative importance level of the Internet of Things device.

[0099] The feature vector is input into the trained gradient boosting decision tree model, and the prediction result output by the trained gradient boosting decision tree model is used as the initial reconnection delay time of the Internet of Things device.

[0100] 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.

[0101] In this embodiment, the machine learning model generates a device-specific "initial reconnection delay time" that is more tailored to the device's actual performance and health status than a traditional fixed value (such as 5 seconds). For example, devices that frequently drop connections can be assigned a longer initial waiting time to avoid affecting server resources; devices with stable status and high priority can obtain a shorter initial delay to quickly restore communication.

[0102] In the description of the present application, it should be understood that the terms "first", "second" are used only for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more of the features. In the description of the present application, the meaning of "multiple" is two or more, unless otherwise explicitly specified and limited.

[0103] In this application, unless otherwise explicitly specified and limited, the terms "mounting", "connecting", "connecting", "fixing" and the like should be understood broadly, for example, it can be fixed connection, or detachable connection, or integrated; it can be mechanical connection, or electrical connection; it can be directly connected, or indirectly connected through intermediate medium; it can be the internal communication of two elements or the interaction relationship between two elements. For those skilled in the art, the specific meaning of the above terms in this application can be understood according to the specific circumstances.

[0104] In this application, unless otherwise explicitly specified and limited, the first feature is "on" or "under" the second feature, which can be direct contact between the first and second features, or indirect contact between the first and second features through an intermediate medium. Moreover, the first feature is "above", "over" and "on" the second feature, which can be directly above or obliquely above the first feature, or only indicates that the horizontal height of the first feature is higher than that of the second feature. The first feature is "below", "under" and "under" the second feature, which can be directly below or obliquely below the first feature, or only indicates that the horizontal height of the first feature is lower than that of the second feature.

[0105] In the description of the specification, the description of the terms "one embodiment", "some embodiments", "an embodiment", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are contained in at least one embodiment or example of the present application. In the specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the person skilled in the art can combine and combine the different embodiments or examples described in the specification and the features of the different embodiments or examples without contradiction within the scope of the present application.

[0106] Although the embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and are not to be construed as limiting the present application, and the person skilled in the art can modify, 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, the highway system comprising a central server and multiple Internet of Things (IoT) devices network-connected to the central server, characterized in that, The method includes: S1. When a network interruption occurs between the central server and any IoT device, or when the reconnection operation fails, 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 is allowed to retry, the central server queries the pre-stored communication resource table to determine whether there is a valid communication resource corresponding to the IoT device. S3. If there are valid communication resources corresponding to the IoT device, the counter variable recording the number of reconnections of the IoT device will be incremented to update the current number of reconnections. S4. If the current number of reconnections does not exceed the preset maximum number of reconnections threshold, then the delay time corresponding to the current number of reconnections is obtained according to the preset dynamic correction factor, the preset maximum allowable delay time, the preset jitter factor, and the preset initial reconnection delay time or the delay time corresponding to the previous number of reconnections obtained in advance. S5. After the delay time corresponding to the current number of reconnections is reached, initiate a reconnection operation to the IoT device through the effective communication resources and obtain the reconnection operation result.

2. The large-scale device cluster communication method according to claim 1, characterized in that, The method further includes: S6. If the reconnection operation fails, repeat steps S1-S5 until the reconnection operation succeeds.

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 retries if the number exceeds a preset maximum reconnection threshold; or, detecting the duration of the network interruption between the central server and the IoT device, and prohibiting retries if the duration exceeds a timeout threshold.

4. The large-scale device cluster communication method according to claim 3, characterized in that, in, The effective communication resources include at least one of the following: connection handle, protocol adapter instance, or communication proxy object, and are generated and recorded when the central server and the IoT device successfully connect 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, S4 specifically includes: S41. If the current number of reconnections does not exceed the preset maximum number of reconnections threshold, then the corrected delay time corresponding to the current number of reconnections is obtained 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. S42. Based on the corrected delay time corresponding to the current number of reconnections and the preset jitter factor, obtain the delay time corresponding to the current number of reconnections.

7. The large-scale device cluster communication method according to claim 6, characterized in that, S41 specifically includes: If the current number of reconnections does not exceed the preset maximum number of reconnections 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 previous number of reconnections obtained in advance. The formula (1) is: delay t =min(delay x ×factor,maxDelay); t represents the current reconnection count; delay t This is the corrected delay time corresponding to the current number of reconnections; factor is a pre-defined dynamic correction factor; maxDelay is the preset maximum allowed delay time; When t=1, delay x The initial reconnection delay time is preset. When t > 1, delay x The delay time corresponding to the number of reconnections obtained in advance.

8. The large-scale device cluster communication method according to claim 7, characterized in that, S42 specifically includes: The delay time is adjusted based on the current number of reconnections. t With the pre-set jitter factor, the delay time distribution model is constructed using the normal distribution probability density function represented by formula (2), and the actual delay time corresponding to the current reconnection number t is calculated through this distribution model; The formula (2) is: ； This represents the probability density when the delay time is x; x is the delay time variable for this reconnection operation. This represents the corrected delay time (delay) corresponding to the current reconnection count (t). t ; This represents the standard deviation, with values ​​ranging from 1 to 2. ×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 a parameter is used to generate a delay time value x by random sampling. The value of x is the delay time corresponding to the current reconnection count 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 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 in the following way: Collect historical operating data and status feature data of the IoT device, and perform feature engineering processing on the historical operating data and status feature data of the IoT device to form a feature vector; The feature vector is input into the trained gradient boosting decision tree model, and the trained gradient boosting decision tree model outputs the prediction result as the initial reconnection delay time of the IoT device.

Images