A dual-channel cloud connection switch self-healing control method, system, device and storage medium
Patent Information
- Application Number
- CN202610994500.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-06
- Publication Date
- 2026-09-11
AI Technical Summary
然而,在实际部署中,设备与云端之间的连接常因网络抖动、DNS变更、认证凭证过期或云端服务异常等原因发生中断
本申请通过加载云端接入参数及身份认证参数并初始化状态变量、定时器与失败计数器,为双通道连接与事件处理建立控制基础;通过基于云端接入参数及身份认证参数建立认证通道并完成身份校验后进入凭证有效态,使得认证凭证在逻辑上保持有效而物理连接关闭;通过基于业务通道建立参数建立业务通道并启动基于定时器的连接维护机制,实现业务数据的独立传输与维护;通过采集由连接维护机制及网络环境产生的运行事件,为自愈动作提供输入;通过将运行事件输入有限状态机模型并根据状态变量及事件类型驱动执行自愈动作,包括根据失败类型、失败计数器计数值及通道状态执行分级恢复,优先尝试轻恢复并在必要时触发重恢复,同时按资源依赖逆序回收资源并释放定时器,实现了对异常事件的差异化处理与资源管理;最后通过恢复后重置状态变量及失败计数器回归稳态。由于认证通道在完成身份校验后进入凭证有效态,在业务通道发生临时性异常时,可直接复用已缓存凭证仅重建业务通道,无需重新执行完整的身份校验流程,因此减少了恢复过程中的交互步骤与等待时间;由于采用有限状态机模型根据当前状态及事件类型统一驱动自愈动作,避免了分散处理导致的逻辑冲突,提高了恢复动作的确定性;由于按失败类型、失败次数及通道状态综合判定恢复级别,优先执行轻恢复,仅在轻恢复失败或认证根本异常时执行重恢复,因此减少了不必要的全量重建操作,降低了平均恢复时间;由于按资源依赖逆序回收相关资源并释放定时器,避免了旧连接残留与定时器叠加,能够确保重建环境干净,提高恢复效率。
Smart Images

Figure CN122741186A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network communication and cloud management equipment technology, and in particular to a self-healing control method, system, device and storage medium for a dual-channel cloud-connected switch. Background Technology
[0002] As enterprise networks expand and cloud transformation deepens, network access devices commonly adopt a cloud-managed model. This means devices connect to a cloud management platform via persistent connections for unified configuration, monitoring, and maintenance. However, in actual deployments, the connection between devices and the cloud is frequently interrupted due to network jitter, DNS changes, expired authentication credentials, or cloud service anomalies. Existing reconnection mechanisms often employ simple fixed-interval retries or a single full reconnection strategy. Even minor network jitter can trigger a full reconnection, including re-authentication, leading to excessively long recovery times and large service interruption windows. In other words, current technology cannot distinguish between temporary service channel anomalies and fundamental authentication anomalies, resulting in low recovery efficiency. Summary of the Invention
[0003] This application provides a self-healing control method, system, device, and storage medium for dual-channel cloud-connected switches, which can distinguish between temporary service channel anomalies and fundamental authentication anomalies, thereby improving recovery efficiency.
[0004] To achieve the above objectives, this application adopts the following technical solution: Firstly, this application provides a self-healing control method for a dual-channel cloud-connected switch, including: Load cloud access parameters and authentication parameters, and initialize state variables, timers, and failure counters; An authentication channel is established based on the cloud access parameters and the identity authentication parameters. Identity verification is performed with the cloud and business channel establishment parameters are obtained. The authentication channel is controlled to enter the credential validity state after identity verification is completed. A service channel is established based on the service channel establishment parameters, device registration is completed, and a connection maintenance mechanism based on the timer is started. Collect operational events generated by the connection maintenance mechanism and the network environment; The running event is input into a finite state machine model, which is then controlled to drive corresponding self-healing actions based on the current state indicated by the state variables and the type of the running event. The self-healing actions include performing tiered recovery based on the failure type, the failure counter value, and the channel status. When the running event indicates an anomaly, a light recovery attempt is made to rebuild only the service channel. When the light recovery fails consecutively to a preset threshold, or when authentication credentials are detected to be invalid or the authentication server address has changed, a re-recovery attempt is triggered to rebuild both the authentication channel and the service channel. Furthermore, when a connection is lost, the relevant resources of the authentication channel and the service channel are reclaimed in reverse order of resource dependency, and the timer is released. Once the light recovery or the heavy recovery is successfully executed, the state variables and the failure counter are reset and the system returns to a steady state.
[0005] Optionally, controlling the authentication channel to enter the credential validity state after completing identity verification includes: Close the physical connection of the authentication channel, cache the credentials obtained from identity verification locally, and retain the logical validity of the credentials; When the credential is valid, the cached credential can be reused directly when the business channel is rebuilt, without the need for identity verification.
[0006] Optionally, the control of the finite state machine model, based on the current state indicated by the state variables and the type of the running event, drives the execution of corresponding self-healing actions, including: When the authentication channel is in a valid credential state and the business channel is online, if the management server address changes, the business channel will only be disconnected and rebuilt. If the connection maintenance mechanism or registration of the service channel times out, the service channel will be disconnected and rebuilt. If the authentication server address changes or the authentication credential becomes invalid, the authentication channel and the business channel will be disconnected and rebuilt completely. If DNS resolution is complete but the server address has changed, refresh the corresponding server address and rebuild the corresponding channel. If a cloud-based collaborative backoff instruction is received, the connection will be disconnected after a specified delay and then reconnected at a set time.
[0007] Optionally, the step of performing tiered recovery based on the failure type, the failure counter value, and the channel status includes: Based on the failure type of the current abnormal event, the number of consecutive failures of the light recovery or the heavy recovery, and the current status of the authentication channel and the service channel, a comprehensive determination is made to execute the light recovery or the heavy recovery. The decision priority is as follows: first, determine whether the heavy recovery must be performed; then, determine whether the light recovery can be performed; and finally, enter the backoff waiting state.
[0008] Optionally, when the runtime event indicates an anomaly, prioritizing a light recovery that only rebuilds the service channel includes: When the connection maintenance mechanism of the service channel times out and the authentication channel is in a valid credential state, or when the registration response of the service channel times out and the authentication channel is in a valid credential state, or when the management server address changes and the authentication channel is in a valid credential state, or when the service channel connection is lost and the authentication channel is in a valid credential state, the service channel is simply disconnected and rebuilt, the valid credential state of the authentication channel is retained, and the service channel is directly re-registered using the establishment parameters of the service channel.
[0009] Optionally, triggering the reconstruction of the authentication channel and the recovery of the service channel includes: Disconnect the authentication channel from the service channel, release all timers and encryption contexts, and re-execute the steps of establishing the authentication channel and establishing the service channel.
[0010] Optionally, the step of reclaiming relevant resources in reverse order of resource dependency and releasing the timer includes: Disconnect and destroy the connection of the service channel, stop and release the registration timeout timer, heartbeat sending timer, heartbeat timeout timer and data reporting timer, release the encryption context of the authentication channel, and clear the session cache.
[0011] Secondly, this application provides a self-healing control system for a dual-channel cloud-connected switch, comprising: The parameter loading module is used to load cloud access parameters and authentication parameters, and initialize state variables, timers and failure counters; The authentication channel establishment module is used to establish an authentication channel based on the cloud access parameters and the identity authentication parameters, perform identity verification with the cloud and obtain business channel establishment parameters, and control the authentication channel to enter the credential validity state after completing the identity verification. The service channel establishment module is used to establish a service channel based on the service channel establishment parameters, complete device registration, and start the connection maintenance mechanism based on the timer. The event collection module is used to collect runtime events generated by the connection maintenance mechanism and the network environment. The self-healing module is used to input the running event into a finite state machine model, and control the finite state machine model to drive the execution of corresponding self-healing actions according to the current state indicated by the state variables and the type of the running event. The self-healing actions include performing graded recovery according to the failure type, the count value of the failure counter, and the channel status. When the running event indicates an anomaly, it prioritizes attempting a light recovery that only rebuilds the service channel. When the light recovery fails consecutively to a preset threshold, or when authentication credentials are detected to be invalid or the authentication server address is changed, it triggers a re-recovery of the authentication channel and the service channel. When a connection is disconnected, it reclaims the relevant resources of the authentication channel and the service channel in reverse order of resource dependency and releases the timer. The reset module is used to reset the state variables and the failure counter and return to a steady state after the light recovery or the heavy recovery is successfully executed.
[0012] Thirdly, this application provides a computing device, including a memory and a processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of the first aspects.
[0013] Fourthly, this application provides a computer-readable storage medium for storing a computer program for performing the method as described in any one of the first aspects.
[0014] As can be seen from the above technical solution, this application has at least the following beneficial effects: This application establishes a control foundation for dual-channel connection and event handling by loading cloud access parameters and authentication parameters and initializing state variables, timers, and failure counters. It establishes an authentication channel based on cloud access parameters and authentication parameters, and after identity verification, enters a credential validity state, ensuring the authentication credential remains logically valid while the physical connection is closed. It establishes a business channel based on business channel establishment parameters and initiates a timer-based connection maintenance mechanism, enabling independent transmission and maintenance of business data. It collects runtime events generated by the connection maintenance mechanism and network environment to provide input for self-healing actions. By inputting runtime events into a finite state machine model and driving self-healing actions based on state variables and event types, including performing tiered recovery based on failure type, failure counter count, and channel status, prioritizing light recovery and triggering heavy recovery when necessary, while simultaneously reclaiming resources in reverse order of resource dependency and releasing timers, it achieves differentiated processing and resource management of abnormal events. Finally, it resets state variables and failure counters after recovery to return to a steady state. Since the authentication channel enters the credential validity state after completing identity verification, when a temporary anomaly occurs in the business channel, the cached credentials can be directly reused to rebuild only the business channel without re-executing the complete identity verification process, thus reducing the interaction steps and waiting time in the recovery process. Because a finite state machine model is used to uniformly drive self-healing actions based on the current state and event type, logical conflicts caused by decentralized processing are avoided, improving the determinism of recovery actions. Since the recovery level is comprehensively determined based on failure type, number of failures, and channel state, prioritizing light recovery and only performing heavy recovery when light recovery fails or authentication is fundamentally abnormal, unnecessary full reconstruction operations are reduced, lowering the average recovery time. Because relevant resources are reclaimed and timers are released in reverse order of resource dependencies, the accumulation of old connection remnants and timers is avoided, ensuring a clean reconstruction environment and improving recovery efficiency.
[0015] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description
[0016] Figure 1A schematic flowchart of a self-healing control method for a dual-channel cloud connection switch is provided in an embodiment of this application. Figure 2 A schematic diagram of a self-healing control system structure for a dual-channel cloud connection switch is provided in this application embodiment; Figure 3 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation
[0017] The terms "first," "second," and "third," etc., used in this application specification and accompanying drawings are used to distinguish different objects, not to limit a specific order.
[0018] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0019] This application provides a self-healing control method for a dual-channel cloud-connected switch, which can be executed by the switch itself or a processing device. The processing device can be a terminal or a server. Terminals include, but are not limited to, smartphones, tablets, laptops, personal digital assistants, or smart wearable devices. The server can be a cloud server, such as a central server in a central cloud computing cluster or an edge server in an edge cloud computing cluster. Alternatively, the server can be a server in a local data center. A local data center refers to a data center directly controlled by the user.
[0020] To make the technical solution of this application clearer and easier to understand, the following description, in conjunction with the accompanying drawings, introduces a self-healing control method for a dual-channel cloud connection switch provided in an embodiment of this application. Figure 1 As shown in the figure, this is a schematic flowchart of a self-healing control method for a dual-channel cloud connection switch provided in an embodiment of this application. The method includes: S101 loads cloud access parameters and authentication parameters, and initializes state variables, timers, and failure counters.
[0021] Specifically, cloud access parameters include the cloud server's address, port, and communication protocol configuration information, while authentication parameters include device identifier, key, and certificate information. State variables record the current status of the authentication and service channels, such as online, offline, or credential valid status. Timers include a registration timeout timer, a heartbeat sending timer, a heartbeat timeout timer, and a data reporting timer, used for timeout detection and periodic triggering during connection maintenance. A failure counter records the number of consecutive failures during light or heavy recovery, providing a numerical basis for tiered recovery determination. During initialization, state variables are set to their initial steady-state values, all timers are set to an inactive state, and the failure counter is cleared to zero, thus preparing control resources for subsequent dual-channel establishment and event handling, avoiding state chaos and resource leaks.
[0022] S102 establishes an authentication channel based on cloud access parameters and identity authentication parameters, verifies identity with the cloud and obtains business channel establishment parameters, and controls the authentication channel to enter the credential validity state after completing identity verification.
[0023] Specifically, the device initiates an authentication connection request based on the authentication server address and port recorded in the cloud access parameters, and performs an identity verification process with the cloud via the HTTPS protocol. During the identity verification process, the device sends identity authentication parameters to the cloud. After successful verification by the cloud, it returns business channel establishment parameters, which include Token, connCode, business server IP address, and port number. It's important to note that the authentication channel is only responsible for identity verification and parameter distribution. After identity verification is complete, the device closes the physical connection of the authentication channel, i.e., disconnects the TCP connection and releases Socket resources, caches the credentials obtained from identity verification locally, and retains the logical validity of the credentials, thus putting the authentication channel into a credential valid state. In this credential valid state, the physical connection of the authentication channel is closed, but the cached credentials remain logically valid. When rebuilding the business channel, the cached credentials are directly reused without re-verifying the identity. By physically separating the authentication channel and the business channel, closing the authentication channel does not affect the cached credentials or the rebuilding of the business channel, thereby avoiding the authentication process blocking business recovery and providing a logical basis for lightweight recovery.
[0024] S103: Establish a service channel based on service channel establishment parameters, complete device registration, and start a timer-based connection maintenance mechanism.
[0025] Specifically, the device utilizes the service channel establishment parameters obtained from the authentication channel to establish an independent service communication channel. The transport layer uses TCP or TCP+TLS protocols, and the application layer uses the MQTT protocol. The device subscribes to configured topics using a token or account identity and maintains a long connection through the KeepAlive Topic. After completing device registration, the device sends a registration request to the cloud management server and initiates a connection maintenance mechanism based on the aforementioned timers. This includes starting a heartbeat sending timer to periodically send heartbeat messages, starting a heartbeat timeout timer to detect if the heartbeat response has timed out, starting a registration timeout timer to detect if the registration response has timed out, and starting a data reporting timer to periodically report device data. Data interaction is performed through an independent service channel, forming a dual-channel decoupled architecture with the authentication channel to ensure the independence of service data transmission.
[0026] S104 collects runtime events generated by the connection maintenance mechanism and network environment.
[0027] Specifically, the system continuously monitors runtime events at the network and application layers. These runtime events are generated by connection maintenance mechanisms and the network environment, including but not limited to heartbeat timeout events, registration timeout events, DNS resolution completion events, network address change events, link interruption events, MQTT connection loss events, management server address change events, authentication server address change events, and cloud-based collaborative backoff instructions. These runtime events serve as input to the finite state machine model, triggering corresponding self-healing actions. This provides complete input to the finite state machine model, ensuring timely anomaly detection and accurate triggering of self-healing actions.
[0028] S105 inputs the running event into the finite state machine model, and controls the finite state machine model to drive the execution of the corresponding self-healing action according to the current state indicated by the state variable and the type of running event.
[0029] It's important to note that the finite state machine model is not simply an enumeration of connection states, but rather executes differentiated actions based on event types. When the authentication channel is in a valid credential state and the business channel is online, if the management server address changes, only the business channel is disconnected and rebuilt; if the connection maintenance mechanism or registration timeout of the business channel occurs, only the business channel is disconnected and rebuilt; if the authentication server address changes or the authentication credentials expire, both the authentication channel and the business channel are disconnected and fully rebuilt; if DNS resolution is complete and the server address changes, the corresponding server address is refreshed and the corresponding channel is rebuilt; if a cloud-based collaborative backoff instruction is received, the connection is disconnected after a specified delay and then reconnected periodically. Through unified event-driven state management, differentiated actions are executed based on the current state and event type, avoiding logical conflicts and resource leaks caused by each module handling exceptions independently.
[0030] It should be further explained that the self-healing action includes performing tiered recovery based on the failure type, the failure counter value, and the channel status. Specifically, based on the failure type of the current abnormal event, the number of consecutive failures of the light recovery or the heavy recovery, and the current status of the authentication channel and the service channel, a comprehensive determination is made to execute either the light recovery or the heavy recovery. The determination priority is as follows: first, determine whether the heavy recovery must be executed; then, determine whether the light recovery can be executed; and finally, enter a backoff waiting state.
[0031] Specifically, a comprehensive judgment can be made based on three dimensions: failure type, number of failures, and channel status. First, it is determined whether a full recovery is necessary. If not, it is then determined whether a light recovery is feasible. If still not feasible, a backoff waiting state is entered. Through this three-dimensional comprehensive judgment, temporary anomalies and fundamental anomalies are distinguished, and light recovery is prioritized to reduce unnecessary full reconstruction operations, thereby shortening the average recovery time and reducing resource consumption.
[0032] When the runtime event indicates an anomaly, a light recovery attempt is made to rebuild only the service channel. Light recovery is suitable for temporary service channel anomalies. When the service channel's connection maintenance mechanism times out and the authentication channel is in a valid credential state, or when the service channel's registration response times out and the authentication channel is in a valid credential state, or when the management server address changes and the authentication channel is in a valid credential state, or when the service channel connection is lost and the authentication channel is in a valid credential state, only the service channel is disconnected and rebuilt, retaining the valid credential state of the authentication channel, and directly re-registering with the service channel establishment parameters. Because the authentication channel is in a valid credential state and the credentials are cached, there is no need to re-initiate the HTTPS authentication handshake, thus shortening the recovery time from tens of seconds for a full reconnection to a few seconds for service channel reconstruction. Specifically, when the authentication channel is in a valid credential state and the service channel is online, if the management server address changes, only the service channel is disconnected and rebuilt, achieving a smooth switchover.
[0033] Furthermore, when the continuous failures of the light recovery reach a preset threshold, or when authentication credentials expire or the authentication server address changes, a re-recovery of the authentication channel and the service channel is triggered. Specifically, when the continuous failures of the light recovery reach a preset threshold, or when authentication credentials expire or the cloud returns an authentication error, or when the authentication server address or domain name changes, or when the authentication server IP changes after DNS resolution, the authentication channel and the service channel are disconnected, all timers and encryption contexts are released, and the steps to establish the authentication channel and the service channel are re-executed. Re-recovery is applicable to fundamental authentication or network anomalies, ensuring the reliability of connection recovery through a full reconstruction.
[0034] As an optional implementation, when a connection is lost, the resources related to the authentication channel and the service channel are reclaimed in reverse order of resource dependency, and the timers are released. Specifically, when a connection is lost, cleanup is performed in reverse order of resource dependency: first, the connection of the service channel is disconnected and destroyed to prevent old connection remnants from causing new connection establishment failures; then, the registration timeout timer is stopped and released to prevent accidental connection loss leading to a reconnection shortly after recovery; next, the heartbeat sending timer is stopped and released to prevent sending heartbeats to disconnected connections and wasting processor resources; then, the heartbeat timeout timer is stopped and released to prevent the superposition of old and new timers from causing frequent chain misjudgments; then, the data reporting timer is stopped and released to prevent continuous reporting during offline periods and wasting bandwidth; finally, the encryption context of the authentication channel is released to prevent memory leaks after multiple reconnections, and the session cache is cleaned up. Through strict reverse-order resource reclamation, a clean reconstruction environment is ensured, eliminating chain misjudgments and memory leaks caused by timer superposition.
[0035] As an optional implementation, when a backoff waiting state is determined, the backoff time interval is dynamically adjusted based on historical recovery results and network quality feedback. Specifically, the backoff time interval is tied to the current dual-channel status and recovery level, with different channel factors used for the light recovery path and the heavy recovery path, and dynamically adjusted in conjunction with historical network quality data. The backoff interval calculation formula is as follows:
[0036] in, This is the retreat interval; This is the maximum retreat limit; Basic retreat interval; This is the retreat coefficient; This represents the number of consecutive failures at the current recovery level. This is the channel factor, set to 1.0 for light recovery paths and 2.0 for heavy recovery paths; This is a network quality factor, calculated based on the time taken for the most recent connections and DNS resolution. The longer the time taken... The larger.
[0037] Upon receiving a cloud-based collaborative backoff command, the cloud-specified delay is prioritized to achieve cloud-based collaborative backoff and suppress reconnection storms. After a successful light recovery... Clear to zero This feature allows for automatic shortening of the first retry interval after network recovery; after successful recovery... and Everything reset, back to zero. The difference between this backoff strategy and the general index backoff is that the general backoff is based only on the number of failures, while this application adjusts the backoff based on which channel failed and the network quality history, so as to avoid using excessively long backoff intervals for abnormal business channels when the authentication channel is still valid.
[0038] S106: After a light recovery or heavy recovery is successfully executed, the state variables and failure counter are reset and the system returns to a steady state.
[0039] Specifically, after the connection is successfully restored, the system updates the status variables to the normal online state, clears the failure counter to zero, and restores the relevant timeout timers to the normal cycle, thereby returning to the steady state of normal cloud management message interaction and maintaining the initial judgment conditions for the next exception handling.
[0040] Based on the above description, this application has the following beneficial effects: By loading cloud access parameters and authentication parameters and initializing state variables, timers, and failure counters, a control foundation is established for dual-channel connection and event handling. An authentication channel is established based on the cloud access parameters and authentication parameters, and after identity verification, the authentication credentials enter a valid state, ensuring the authentication credentials remain logically valid while the physical connection is closed. A business channel is established based on business channel establishment parameters, and a timer-based connection maintenance mechanism is initiated, enabling independent transmission and maintenance of business data. Operational events generated by the connection maintenance mechanism and network environment are collected to provide input for self-healing actions. By inputting operational events into a finite state machine model and driving self-healing actions based on state variables and event types, including tiered recovery based on failure type, failure counter value, and channel status, prioritizing light recovery and triggering heavy recovery when necessary, while simultaneously reclaiming resources in reverse order of resource dependency and releasing timers, differentiated processing and resource management of abnormal events are achieved. Finally, after recovery, state variables and failure counters are reset to return to a steady state. Since the authentication channel enters the credential validity state after completing identity verification, when a temporary anomaly occurs in the business channel, the cached credentials can be directly reused to rebuild only the business channel without re-executing the complete identity verification process, thus reducing the interaction steps and waiting time in the recovery process. Because a finite state machine model is used to uniformly drive self-healing actions based on the current state and event type, logical conflicts caused by decentralized processing are avoided, improving the determinism of recovery actions. Because the recovery level is comprehensively determined based on failure type, number of failures, and channel state, prioritizing light recovery and only performing heavy recovery when light recovery fails or authentication is fundamentally abnormal, unnecessary full reconstruction operations are reduced, lowering the average recovery time. Because relevant resources are reclaimed and timers are released in reverse order of resource dependencies, old connection remnants and timer accumulation are avoided, ensuring a clean reconstruction environment and improving the recovery success rate.
[0041] In summary, this application decouples the authentication channel from the business channel. After the authentication channel completes identity verification, it enters the credential validity state. This allows the business channel to be rebuilt without re-verifying identity when it is abnormal, thereby shortening the recovery time and reducing resource consumption.
[0042] The above text combined Figure 1 This application provides a detailed description of a self-healing control method for a dual-channel cloud connection switch, and the system and equipment provided in this application will be described below with reference to the accompanying drawings.
[0043] like Figure 2 As shown in the figure, this is a schematic diagram of a dual-channel cloud-connected switch self-healing control system structure provided in an embodiment of this application. The dual-channel cloud-connected switch self-healing control system 200 includes: The parameter loading module 210 is used to load cloud access parameters and authentication parameters, and initialize state variables, timers and failure counters. The authentication channel establishment module 220 is used to establish an authentication channel based on the cloud access parameters and the identity authentication parameters, perform identity verification with the cloud and obtain business channel establishment parameters, and control the authentication channel to enter the credential validity state after completing the identity verification. The service channel establishment module 230 is used to establish a service channel based on the service channel establishment parameters, complete device registration, and start the connection maintenance mechanism based on the timer. The event acquisition module 240 is used to collect runtime events generated by the connection maintenance mechanism and the network environment. The self-healing module 250 is used to input the running event into a finite state machine model, and control the finite state machine model to drive the execution of corresponding self-healing actions according to the current state indicated by the state variables and the type of the running event. The self-healing actions include performing graded recovery according to the failure type, the count value of the failure counter and the channel status. When the running event indicates an abnormality, it prioritizes attempting a light recovery that only rebuilds the service channel. When the light recovery fails consecutively to a preset threshold, or when authentication credentials are detected to be invalid or the authentication server address is changed, it triggers a re-recovery of the authentication channel and the service channel. When a connection is disconnected, it reclaims the relevant resources of the authentication channel and the service channel in reverse order of resource dependency and releases the timer. The reset module 260 is used to reset the state variables and the failure counter and return to a steady state after the light recovery or the heavy recovery is successfully executed.
[0044] Optional, the authentication channel establishment module 220 is specifically used for: Close the physical connection of the authentication channel, cache the credentials obtained from identity verification locally, and retain the logical validity of the credentials; When the credential is valid, the cached credential can be reused directly when the business channel is rebuilt, without the need for identity verification.
[0045] Optional, self-healing module 250, specifically used for: When the authentication channel is in a valid credential state and the business channel is online, if the management server address changes, the business channel will only be disconnected and rebuilt. If the connection maintenance mechanism or registration of the service channel times out, the service channel will be disconnected and rebuilt. If the authentication server address changes or the authentication credential becomes invalid, the authentication channel and the business channel will be disconnected and rebuilt completely. If DNS resolution is complete but the server address has changed, refresh the corresponding server address and rebuild the corresponding channel. If a cloud-based collaborative backoff instruction is received, the connection will be disconnected after a specified delay and then reconnected at a set time.
[0046] Optional, the self-healing module 250 is also specifically used for: Based on the failure type of the current abnormal event, the number of consecutive failures of the light recovery or the heavy recovery, and the current status of the authentication channel and the service channel, a comprehensive determination is made to execute the light recovery or the heavy recovery. The decision priority is as follows: first, determine whether the heavy recovery must be performed; then, determine whether the light recovery can be performed; and finally, enter the backoff waiting state.
[0047] Optional, the self-healing module 250 is also specifically used for: When the connection maintenance mechanism of the service channel times out and the authentication channel is in a valid credential state, or when the registration response of the service channel times out and the authentication channel is in a valid credential state, or when the management server address changes and the authentication channel is in a valid credential state, or when the service channel connection is lost and the authentication channel is in a valid credential state, the service channel is simply disconnected and rebuilt, the valid credential state of the authentication channel is retained, and the service channel is directly re-registered using the establishment parameters of the service channel.
[0048] Optional, the self-healing module 250 is also specifically used for: Disconnect the authentication channel from the service channel, release all timers and encryption contexts, and re-execute the steps of establishing the authentication channel and establishing the service channel.
[0049] Optional, the self-healing module 250 is also specifically used for: Disconnect and destroy the connection of the service channel, stop and release the registration timeout timer, heartbeat sending timer, heartbeat timeout timer and data reporting timer, release the encryption context of the authentication channel, and clear the session cache.
[0050] According to the embodiments of this application, a dual-channel cloud-connected switch self-healing control system can be implemented by correspondingly executing the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the dual-channel cloud-connected switch self-healing control system are respectively for implementing Figure 1 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.
[0051] This application also provides a computing device.
[0052] like Figure 3 As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 300 includes a bus 301, a processor 302, a communication interface 303, and a memory 304. The processor 302, the memory 304, and the communication interface 303 communicate with each other via the bus 301.
[0053] Bus 301 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0054] The processor 302 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).
[0055] Communication interface 303 is used for communication with external devices.
[0056] Memory 304 may include volatile memory, such as random access memory (RAM). Memory 304 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0057] The memory 304 stores executable code, and the processor 302 executes the executable code to perform the aforementioned dual-channel cloud connection switch self-healing control method.
[0058] Specifically, in achieving Figure 2 In the case of the illustrated embodiment, and Figure 2 In the embodiment, when the modules or units of a dual-channel cloud-connected switch self-healing control system are implemented in software, the following steps are performed: Figure 2 The software or program code required for the functions of each module / unit can be partially or entirely stored in memory 304. Processor 302 executes the program code corresponding to each unit stored in memory 304, and executes the aforementioned dual-channel cloud connection switch self-healing control method.
[0059] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned dual-channel cloud connection switch self-healing control method.
[0060] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.
[0061] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.
[0062] When the computer program product is executed by a computer, the computer executes any of the aforementioned dual-channel cloud connection switch self-healing control methods. The computer program product can be a software installation package; when any of the aforementioned dual-channel cloud connection switch self-healing control methods is required, the computer program product can be downloaded and executed on the computer.
[0063] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.
[0064] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.
Claims
1. A self-healing control method for a dual-channel cloud-connected switch, characterized in that, The method includes: Load cloud access parameters and authentication parameters, and initialize state variables, timers, and failure counters; An authentication channel is established based on the cloud access parameters and the identity authentication parameters. Identity verification is performed with the cloud and business channel establishment parameters are obtained. The authentication channel is controlled to enter the credential validity state after identity verification is completed. A service channel is established based on the service channel establishment parameters, device registration is completed, and a connection maintenance mechanism based on the timer is started. Collect operational events generated by the connection maintenance mechanism and the network environment; The running event is input into a finite state machine model, which is then controlled to drive corresponding self-healing actions based on the current state indicated by the state variables and the type of the running event. The self-healing actions include performing tiered recovery based on the failure type, the failure counter value, and the channel status. When the running event indicates an anomaly, a light recovery attempt is made to rebuild only the service channel. When the light recovery fails consecutively to a preset threshold, or when authentication credentials are detected to be invalid or the authentication server address has changed, a re-recovery attempt is triggered to rebuild both the authentication channel and the service channel. Furthermore, when a connection is lost, the relevant resources of the authentication channel and the service channel are reclaimed in reverse order of resource dependency, and the timer is released. Once the light recovery or the heavy recovery is successfully executed, the state variables and the failure counter are reset and the system returns to a steady state.
2. The method according to claim 1, characterized in that, The control of the authentication channel to enter the credential validity state after identity verification is completed includes: Close the physical connection of the authentication channel, cache the credentials obtained from identity verification locally, and retain the logical validity of the credentials; When the credential is valid, the cached credential can be reused directly when the business channel is rebuilt, without the need for identity verification.
3. The method according to claim 1, characterized in that, The control mechanism, based on the current state indicated by the state variables and the type of the running event, drives the execution of corresponding self-healing actions, including: When the authentication channel is in a valid credential state and the business channel is online, if the management server address changes, the business channel will only be disconnected and rebuilt. If the connection maintenance mechanism or registration of the service channel times out, the service channel will be disconnected and rebuilt. If the authentication server address changes or the authentication credential becomes invalid, the authentication channel and the business channel will be disconnected and rebuilt completely. If DNS resolution is complete but the server address has changed, refresh the corresponding server address and rebuild the corresponding channel. If a cloud-based collaborative backoff instruction is received, the connection will be disconnected after a specified delay and then reconnected at a set time.
4. The method according to claim 1, characterized in that, The step of performing tiered recovery based on the failure type, the failure counter value, and the channel status includes: Based on the failure type of the current abnormal event, the number of consecutive failures of the light recovery or the heavy recovery, and the current status of the authentication channel and the service channel, a comprehensive determination is made to execute the light recovery or the heavy recovery. The decision priority is as follows: first, determine whether the heavy recovery must be performed; then, determine whether the light recovery can be performed; and finally, enter the backoff waiting state.
5. The method according to claim 4, characterized in that, When the runtime event indicates an anomaly, the preferred approach is to attempt a light recovery that only rebuilds the service channel, including: When the connection maintenance mechanism of the service channel times out and the authentication channel is in a valid credential state, or when the registration response of the service channel times out and the authentication channel is in a valid credential state, or when the management server address changes and the authentication channel is in a valid credential state, or when the service channel connection is lost and the authentication channel is in a valid credential state, the service channel is simply disconnected and rebuilt, the valid credential state of the authentication channel is retained, and the service channel is directly re-registered using the establishment parameters of the service channel.
6. The method according to claim 4, characterized in that, The triggering of the reconstruction of the authentication channel and the recovery of the service channel includes: Disconnect the authentication channel from the service channel, release all timers and encryption contexts, and re-execute the steps of establishing the authentication channel and establishing the service channel.
7. The method according to claim 1, characterized in that, The step of reclaiming relevant resources in reverse order of resource dependence and releasing the timer includes: Disconnect and destroy the connection of the service channel, stop and release the registration timeout timer, heartbeat sending timer, heartbeat timeout timer and data reporting timer, release the encryption context of the authentication channel, and clear the session cache.
8. A self-healing control system for a dual-channel cloud-connected switch, characterized in that, The system includes: The parameter loading module is used to load cloud access parameters and authentication parameters, and initialize state variables, timers and failure counters; The authentication channel establishment module is used to establish an authentication channel based on the cloud access parameters and the identity authentication parameters, perform identity verification with the cloud and obtain business channel establishment parameters, and control the authentication channel to enter the credential validity state after completing the identity verification. The service channel establishment module is used to establish a service channel based on the service channel establishment parameters, complete device registration, and start the connection maintenance mechanism based on the timer. The event collection module is used to collect runtime events generated by the connection maintenance mechanism and the network environment. The self-healing module is used to input the running event into a finite state machine model, and control the finite state machine model to drive the execution of corresponding self-healing actions according to the current state indicated by the state variables and the type of the running event. The self-healing actions include performing graded recovery according to the failure type, the count value of the failure counter, and the channel status. When the running event indicates an anomaly, it prioritizes attempting a light recovery that only rebuilds the service channel. When the light recovery fails consecutively to a preset threshold, or when authentication credentials are detected to be invalid or the authentication server address is changed, it triggers a re-recovery of the authentication channel and the service channel. When a connection is disconnected, it reclaims the relevant resources of the authentication channel and the service channel in reverse order of resource dependency and releases the timer. The reset module is used to reset the state variables and the failure counter and return to a steady state after the light recovery or the heavy recovery is successfully executed.
9. A computing device, characterized in that, Including memory and processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method as described in any one of claims 1 to 7.
