Server dead time management methods, devices, equipment, and storage media

Abstract

This application discloses a server dead time management method, apparatus, device, and storage medium, relating to the field of server resource management technology. The server dead time management method includes: if it is determined that the target server has failed, determining whether the global status identifier of the target server is "running"; if it is determined that the global status identifier is "running", setting the global status identifier to "down", and initializing the global reference count of the target server through an active port usage table, wherein the initial value is the number of ports using the target server when the failure occurred; when the port successfully completes the failover from the target server, decrementing the global reference count by one to obtain an updated global reference count; when the updated global reference count decreases to zero, setting the global status identifier to "running", and the target server resumes use. This application can shorten the server failure recovery time.

Description

Technical Field

[0001] This application relates to the field of server resource management technology, and in particular to a server dead time management method, apparatus, device and storage medium. Background Technology

[0002] In actual network deployments, network access devices typically open multiple ports simultaneously, with each port independently authenticating and interacting with the server.

[0003] To address server failure risks and ensure the reliability of authentication services, current practices typically rely on fixed "dead time" timers maintained independently by each port. This forces a fixed wait time after a server failure before recovery, meaning that even if the server recovers ahead of schedule, it cannot be used in a timely manner. Furthermore, the lack of state synchronization between multiple ports leads to asynchronous failure recovery, wasted service windows, and overall recovery delays.

[0004] Therefore, how to shorten server failure recovery time and avoid delayed recovery response is an urgent problem that needs to be solved.

[0005] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a server dead time management method, apparatus, device and storage medium, which aims to solve the technical problem of shortening server failure recovery time and avoiding recovery response lag.

[0007] To achieve the above objectives, this application proposes a server dead time management method, the method comprising: Based on the result of sending the authentication request to the target server, it is determined whether the target server has malfunctioned; If it is determined that the target server has failed, determine whether the global status identifier of the target server is "running". If the global status identifier is determined to be running, the global status identifier is set to down, and the global reference count of the target server is initialized through the active port table, wherein the initial value is the number of ports of the target server used when the failure occurs; When the port successfully completes the failover from the target server, the global reference count is decremented by one to obtain the updated global reference count; When the updated global reference count decreases to zero, the global status flag is set to running, and the target server resumes operation.

[0008] In one embodiment, the step of initializing the global reference count of the target server using a table via an active port includes: When it is detected that the global status identifier is set to down, the active port usage table corresponding to the target server is queried. The active port usage table is used to record in real time the port identifiers that are currently using the target server and whose authentication requests have not yet received a response or have not yet completed failover. The number of records in the active port usage table is counted, and this number is assigned as an initial value to the global reference count to complete the initialization of the global reference count.

[0009] In one embodiment, the method further includes: When a port sends an authentication request to the target server, the port identifier of the port and the binding relationship with the target server are registered in the active port usage table; When the last authentication request for the target server on the port has received a response or was abandoned due to timeout, the corresponding binding relationship is deleted from the active port usage table.

[0010] In one embodiment, after initializing the global reference count of the target server using a table via an active port, the method further includes: Generate a broadcast notification of the downtime status of the target server; The downtime status broadcast notification is sent to all ports, so that the ports, based on the downtime status broadcast notification, delete the cache of pending requests for the target server and stop sending authentication requests to the target server.

[0011] In one embodiment, after the step of setting the global state flag to running and the target server resuming use when the updated global reference count decreases to zero, the method further includes: Generate a live status broadcast notification for the target server; The running status broadcast notification is sent to all ports so that the ports, based on the running status broadcast notification, send subsequent authentication requests to the target server.

[0012] In one embodiment, the step of decrementing the global reference count by one to obtain an updated global reference count when the port successfully completes a failover from the target server includes: Monitor the request processing status of the port for the target server; If it is detected that the port has sent the request to the backup server, or the port has exhausted its retransmission count for the target server, it is determined that the port will no longer use the target server. Receive a handover completion notification sent by the port, wherein the handover completion notification includes the port identifier of the port; Based on the port identifier, query the active port usage table and unbind the port from the target server. After confirming successful unbinding, decrement the global reference count by one.

[0013] In one embodiment, the method further includes: When the global status flag is set to down, a global fallback protection timer is started; When the global fallback protection timer expires and the global reference count is not zero, the global status flag is reset to running and the global reference count is reset to zero.

[0014] Furthermore, to achieve the above objectives, this application also proposes a server dead time management device, which includes: The fault determination module is used to determine whether the target server has failed based on the result of sending an authentication request to the target server; The status determination module is used to determine whether the global status identifier of the target server is "running" if it is determined that the target server has failed. The counting initialization module is used to set the global status identifier to down if it is determined that the global status identifier is running, and to initialize the global reference count of the target server through the active port usage table, wherein the initial value is the number of ports of the target server used when the fault occurs; The counting update module is used to decrement the global reference count by one when the port successfully completes the failover from the target server, so as to obtain the updated global reference count. The counting detection module is used to set the global status flag to running when the updated global reference count decreases to zero, and the target server resumes use.

[0015] In addition, to achieve the above objectives, this application also proposes a server dead time management device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the server dead time management method described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the server dead time management method described above.

[0017] This application provides a server dead time management method. First, based on the result of sending an authentication request to the target server, it determines whether a failure has occurred. If a failure is confirmed and its global status flag is still "running," the flag is immediately set to "down." The global reference count of the target server is initialized using an active port usage table—its initial value corresponding to the number of ports using the server at the time of the failure. Subsequently, when a port successfully completes a failover, the global reference count is decremented by one. Only when the count reaches zero is the global status flag finally reset to "running," thus completing the server's recovery.

[0018] In summary, this application, by combining a global reference counting mechanism with dynamic state collaborative judgment logic, can automatically and dynamically perceive the progress of fault handling without relying on external timers or manual intervention. This not only ensures that the server only resumes service after all relevant ports have completed switching, effectively avoiding service conflicts caused by premature recovery, but also eliminates the blind waiting caused by traditional fixed timeout mechanisms. It solves the technical problems of delayed fault recovery and inconsistent responses in existing technologies, shortens server fault recovery time, and avoids delayed recovery responses. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating an embodiment of the server dead time management method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the server dead time management method of this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the server dead time management method of this application; Figure 4 This is a schematic diagram of the module structure of the server dead time management device in an embodiment of this application; Figure 5 This is a schematic diagram of the hardware operating environment involved in the server dead time management method in this application embodiment.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] The main solution of this application is as follows: Based on the result of sending an authentication request to the target server, determine whether the target server has failed; if the target server has failed, determine whether the global status identifier of the target server is running; if the global status identifier is running, set the global status identifier to down, and initialize the global reference count of the target server through the active port usage table, wherein the initial value is the number of ports using the target server when the failure occurred; when the port successfully completes the failover from the target server, decrement the global reference count by one to obtain the updated global reference count; when the updated global reference count decreases to zero, set the global status identifier to running, and the target server resumes use.

[0026] Currently, the common approach relies on a fixed "dead time" timer mechanism maintained independently by each port. This forces a fixed wait time after a server failure before recovery, meaning that even if the server recovers ahead of schedule, it cannot be utilized in a timely manner. Furthermore, the lack of state synchronization between multiple ports leads to asynchronous fault recovery, wasted service windows, and overall recovery delays.

[0027] This application, by combining a global reference counting mechanism with dynamic state collaborative judgment logic, can automatically and dynamically perceive the progress of fault handling without relying on external timers or manual intervention. It not only ensures that the server only resumes service after all relevant ports have completed the switchover, effectively avoiding service conflicts caused by premature recovery, but also eliminates the blind waiting caused by traditional fixed timeout mechanisms. It solves the technical problems of delayed fault recovery and inconsistent responses in existing technologies, shortens server fault recovery time, and avoids delayed recovery responses.

[0028] It should be noted that the executing entity in this embodiment can be a server dead time management system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or server dead time management device capable of the above functions. This embodiment does not specifically limit it in this regard. The following uses a server dead time management system as an example to describe this embodiment and the following embodiments.

[0029] Based on this, the embodiments of this application provide a server dead time management method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the server dead time management method of this application.

[0030] In this embodiment, the server dead time management method includes steps S10~S50: Step S10: Based on the result of sending the authentication request to the target server, determine whether the target server has malfunctioned; It should be noted that the target server refers to the backend server device in a Network Access Server (NAS) architecture used for user authentication, authorization, and accounting. In a specific scenario of this embodiment, the target server may be a Remote Authentication Dial-Up User Service (RADIUS) server or a Terminal Access Controller Access Control System (TACACS+) server. These servers store and process authentication requests from network access devices and return authentication pass or fail instructions. An authentication request is a data packet generated by a port on the NAS device and sent to the target server when the NAS device detects a user terminal attempting to access the network. This request encapsulates the user's identity information and relevant parameters of the NAS device. By sending this authentication request to the target server, the NAS device initiates the authentication process and waits for the target server to return a corresponding response message.

[0031] Additionally, it should be noted that the result of sending an authentication request to the target server specifically refers to the type of feedback message received by the NAS device after sending the request, or the timeout status when no feedback is received. This result is mainly divided into two categories: 1. Valid response result: This includes an "authentication successful" message or an "authentication rejected" message returned by the target server. Both results indicate that the target server is functioning normally and is able to receive and process requests.

[0032] 2. Invalid or no response result: This includes the NAS device not receiving any messages (timeout) or receiving an unreachable error at the network layer.

[0033] Furthermore, it should be noted that a failure refers to the target server failing to respond effectively to the authentication request sent by the NAS device within a preset time window, or returning an error message indicating that the service is unavailable. Specifically, according to the determination logic of this embodiment, when the port authentication monitoring module of the NAS device sends an authentication request to the target server, if no response is received within the configured timeout period, and still no response is received after a preset number of retransmissions, or the number of consecutive no responses reaches a preset fault threshold, then the target server is determined to be in a fault state on the current port. This fault state indicates that the target server is currently unable to perform its authentication function, which may be caused by server crashes, network link interruptions, or service process hangs. The timeout period is configured through the NAS device's system configuration commands or graphical management interface (e.g., set to 3 to 10 seconds); the preset number of retransmissions is an integer value preset based on network environment stability (e.g., set to 3 or 5 times).

[0034] Understandably, existing server status detection mechanisms often rely on fixed timeouts or periodic health checks. This can lead to NAS devices continuing to send authentication requests to a failed server even when it has actually crashed but hasn't reached the timeout threshold. This results in user access requests being suspended or dropped for extended periods, increasing user access latency. Therefore, step S10, which uses real-time monitoring of authentication request interaction results (e.g., timeout, retransmission failure) to determine if the target server has failed, avoids the continued ineffective use of network port resources and user waiting time when the server has already failed. This improves the real-time nature of server fault detection and the overall reliability of network access services, laying the foundation for quickly triggering the switching of global status identifiers and the initialization of reference counting.

[0035] Step S20: If it is determined that the target server has failed, determine whether the global status identifier of the target server is "running". It's important to note that the global status flag is a status variable or flag used to characterize whether a target server is available globally within the NAS device system. This flag is typically stored in the memory of the server status management module and is used to broadcast the server's current operating status to all ports and modules within the system. When the global status flag is "Running" (e.g., global_dead_flag is False), it indicates that the system considers the server to be in a normal working state, allowing new authentication requests to be distributed to the server. When the flag is set to "Down" (e.g., global_dead_flag is True), it indicates that the server is in a faulty state, and subsequent authentication request distribution modules will no longer select this server to process new services.

[0036] Understandably, since NAS devices typically have multiple ports open, these ports may send authentication requests to the same target server simultaneously or nearly simultaneously. Without a global status verification mechanism, when the target server fails, all ports currently using that server may simultaneously detect timeouts and attempt to modify the server's status or repeatedly report the fault, leading to contention for system resources and confusion in status management. Therefore, step S20, by determining whether the global status flag is "running," avoids multiple ports repeatedly processing the same fault event, improving the stability and processing efficiency of system status management in high-concurrency multi-port scenarios.

[0037] Step S30: If it is determined that the global status identifier is running, the global status identifier is set to down, and the global reference count of the target server is initialized through the active port usage table, wherein the initial value is the number of ports of the target server used when the fault occurs; It should be noted that the global reference count is a counter used to record the number of ports in the current management system that are waiting for a response from the target server or are using the target server for business processing. The value of this counter is associated with the status flag in the server status management module and is used to quantify the workload carried by the currently faulty server.

[0038] Additionally, it should be noted that initializing the global reference count for the target server involves obtaining the configuration information or operating status of all ports in the current NAS device, traversing each port to determine which ports currently have the authentication server selected as the target server, and finally assigning the total number of ports obtained to the global reference count. For example, if Port 1, Port 2, and Port 5 are all configured to use Server A, when Server A fails and its global status is set to down, the global reference count will be initialized to 3.

[0039] Furthermore, it should be noted that when step S20 determines that the global state identifier is down, it means that the target server has been previously marked as unavailable by other ports or management modules within the system. In this case, the current port does not need to modify the global state again, nor does it need to reinitialize the reference count. Instead, it directly performs a failover, assuming that the reference count has been correctly set by the first port that triggered the failure. This design avoids multiple ports competing to modify the same global variable due to simultaneously detecting server failures in high-concurrency multi-port scenarios, thus ensuring the consistency of server state management.

[0040] Understandably, in distributed or multi-port systems, multiple ports may simultaneously depend on the same target server. If the server status is simply marked as down while ignoring ongoing business processes, ports waiting for a response may become stuck in prolonged ineffective waiting or timeout blocking because they are unaware that the server is unavailable. Therefore, step S30, by setting the global status flag to down and synchronously recording the number of ports using the target server at the time of the failure, avoids deadlock problems caused by inconsistencies between the status flag and the number of active connections, thereby improving the accuracy of the system's management of the status of failed servers.

[0041] In one feasible implementation, step S30 may include steps A31-A32: Step A31: When it is detected that the global status identifier is set to down, query the active port usage table corresponding to the target server; It should be noted that the active port usage table is a dynamic table maintained by the server status management module. It records in real-time the port identifiers currently in use by the target server, where authentication requests have not yet received a response or failover has not yet been completed. Specifically, in this embodiment, this table can be a linear table or a hash set.

[0042] Additionally, it should be noted that the specific implementation of querying the active port usage table is as follows: using the server identifier of the target server as the index key, the active port usage table is searched to retrieve all port records associated with that target server identifier.

[0043] Step A32: Count the number of records in the active port usage table and assign the number of records as an initial value to the global reference count to complete the initialization of the global reference count; It should be noted that the number of records counted refers to the cumulative calculation of the number of port identifiers in the query results. This number directly reflects the active business volume that still relies on the target server when the fault occurs. Specifically, when Server A is determined to be faulty and the global reference count needs to be initialized, the fault determination and reference count management module directly queries the server status management module for Server A's active port usage table, and the number of records in the table is the initial reference count value.

[0044] Additionally, it should be noted that the initial value refers to the starting value set for the global reference count at the specific moment the system detects a target server crash. This value is not arbitrarily assigned, but is precisely equal to the number of all affected active ports at that moment, thus ensuring that the reference count accurately reflects the total number of failover tasks to be processed. Initialization refers to the operation process of assigning the aforementioned initial value to the global reference count in this fault handling process. The purpose of this process is to set the reference count from an undefined or old state to a definite starting state that can truly reflect the scope of the current fault's impact, providing a reliable benchmark for subsequent count decrement and fault recovery judgment.

[0045] Understandably, in distributed or multi-port systems, multiple ports may simultaneously depend on the same target server. If the server status is simply marked as down while ignoring ongoing business processes, ports waiting for a response may become stuck in prolonged ineffective waiting or timeout blocking because they are unaware that the server is unavailable. Therefore, this implementation method, by setting the global status flag to down and synchronously recording the number of ports using the target server when the failure occurs, avoids resource leakage or deadlock problems caused by inconsistencies between the status flag and the number of active connections, thereby improving the system's efficiency in recovering resources related to the failed server and the accuracy of status management.

[0046] In another feasible implementation, step S30 may include steps B31-B32: Step B31: When the port sends an authentication request to the target server, the binding relationship between the port identifier and the target server is registered in the active port usage table; It should be noted that registration refers to the process of writing the association between the port identifier and the target server identifier as a new record into the active port usage table. This operation is typically triggered when a port initiates an authentication request, marking that the port is currently relying on the target server for business processing. For example, when the "authentication request distribution module" of Port 1 sends an authentication request to Server A, it calls the server state management module to register the binding relationship (Port 1, Server A) into Server A's "active port usage table".

[0047] Additionally, it should be noted that a binding relationship refers to a temporary dependency relationship established between a port and a target server, indicating that the port is waiting for an authentication response from the target server.

[0048] Step B32: When the last authentication request for the target server on the port has received a response or has been abandoned due to timeout, delete the corresponding binding relationship from the active port usage table. It's important to note that deletion refers to removing the record associated with a specific port identifier and the target server identifier from the active port usage table. This operation is performed after confirming that the port is no longer waiting for any response from the target server, releasing the system's hold on the connection state and triggering a decrement of the global reference count. For example, when the last pending transaction for ServerA on that port terminates (either receiving a response or eventually timed out and aborted), the record for (Port 1, Server A) is deleted from the table.

[0049] Additionally, it should be noted that the last authentication request refers to the final request currently in a waiting-for-response state during the interaction between the port and the target server. Once this request receives a response or is abandoned due to timeout, it signifies the end of the current business interaction cycle between the port and the target server, and there are no longer any pending transactions.

[0050] Understandably, due to the highly dynamic and sudden nature of business requests in the network environment, relying solely on static configuration or periodic polling to estimate the number of active connections often results in time lag, leading to discrepancies between statistical results and actual conditions. Therefore, this implementation method uses a real-time registration and deletion mechanism based on the request lifecycle (i.e., from request sending to request completion) to maintain the active port usage table. This avoids the problems of inflated or undercounted reference counts caused by untimely status updates in traditional methods, thereby improving the real-time performance and accuracy of the global reference count in failover decisions and ensuring that the fault recovery process is triggered only when there is truly no business dependency.

[0051] The above are only two feasible implementation methods of step S30 provided in this embodiment. This embodiment does not specifically limit the specific implementation method of step S30.

[0052] Step S40: When the port successfully completes the failover from the target server, decrement the global reference count by one to obtain the updated global reference count; It should be noted that a successful failover of a port from the target server means that after the current port (e.g., Port 1) detects a failure in the target server (e.g., Server A), it initiates a failover process and resends authentication requests originally destined for that target server to a backup server (e.g., Server B) for processing. Specifically, during the failover process, authentication requests sent on the port but not yet receiving a response are redistributed to the backup server; the failover is considered complete when all requests originally destined for the failed server have been switched over and the port no longer relies on the original target server for authentication.

[0053] Additionally, it should be noted that the operation of decrementing the global reference count is performed by the fault determination and counting management module. The specific process is as follows: when a port (e.g., Port 1) completes a failover, the port's authentication monitoring module sends a "failover completion notification" to the fault determination and counting management module. This notification contains the corresponding server identifier (Server A) and port identifier (Port 1). Upon receiving this notification, the fault determination and counting management module triggers a decrement operation of the reference count for that target server (reference_counter = reference_counter - 1).

[0054] Understandably, since the global reference count is used to record the number of ports currently in use on the target server, this count will only return to zero when all ports in use on the target server have completed their switchover. Therefore, step S40, by decrementing the reference count after each port switchover, avoids misjudging the system status when ports are still in use on the faulty server, thereby improving the accuracy of server status management and the reliability of fault handling procedures. For other ports currently using the target server, the reference count will also be decremented sequentially after each port completes its switchover, following the same mechanism.

[0055] In one feasible implementation, step S40 may include steps A41 to A44: Step A41: Monitor the request processing status of the port for the target server; It should be noted that the request processing status refers to the specific stage the port is in during its interaction with the target server, including statuses such as "waiting to send," "sent and awaiting response," "response timed out," "retransmitting," and "request completed." This status is a key indicator for determining whether the port is still using the faulty server.

[0056] Additionally, it should be noted that the specific implementation method for monitoring the request processing status is as follows: a status listener is set up in the protocol stack or business logic layer of the port to capture events such as sending authentication requests, receiving response messages, or triggering timeout retransmissions in real time, and these events are mapped to the corresponding request processing status for query by the server status management module.

[0057] Step A42: If it is detected that the port has sent the request to the backup server, or the port has exhausted the number of retransmissions for the target server, it is determined that the port will no longer use the target server. It should be noted that a backup server refers to an alternative authentication server assigned to a port by the system according to a preset load balancing strategy or failover rule after the target server is marked as down.

[0058] Step A43: Receive a handover completion notification sent by the port, wherein the handover completion notification includes the port identifier of the port; It should be noted that the failover completion notification is a signaling message proactively sent by the port to the server status management module after the port has completed the service migration to the backup server or confirmed that the connection with the target server has been completely broken. This notification is used to inform the system that the failover process for this port has ended.

[0059] Additionally, it's important to note that the port identifier is crucial information carried in the switchover completion notification, uniquely identifying the port from which the notification originated. The server status management module uses this identifier to accurately locate the corresponding record in the active port usage table, facilitating subsequent cleanup operations.

[0060] Step A44: Based on the port identifier, query the active port usage table and unbind the port from the target server. After confirming successful unbinding, decrement the global reference count by one. It should be noted that unbinding means deleting the association record between the port identifier and the target server identifier from the active port usage table. This operation signifies that the port has completely broken free from its dependence on the faulty server.

[0061] Understandably, since the switching times of each port are not consistent during failover, using a uniform global timer or batch processing method to update the reference count may lead to delayed count updates or a disconnect from the actual business status. Therefore, this implementation method monitors the independent switching status of each port and decrements the global reference count in real time. This avoids resource reclamation delays or misjudgments of faulty servers caused by untimely count updates, thereby improving the granularity of the failover process and the real-time performance of system resource management.

[0062] In one feasible implementation, step S40 may include steps B41-B42: Step B41: When the global status flag is set to down, start the global fallback protection timer; It should be noted that the global fallback protection timer refers to a monitoring thread or software timer set by the server status management module for a faulty server. The duration of this timer is much longer than the normal switching time, for example, it is set to the minute level. Its purpose is not to replace the reference counting mechanism, but to ensure the system self-healing and avoid deadlock in extreme abnormal situations.

[0063] Additionally, it should be noted that the specific implementation of starting the global fallback protection timer is as follows: a countdown task is created based on the preset deadtime parameter. This task is bound to the server identifier of the target server and runs independently in the background to monitor the progress of the reference count returning to zero.

[0064] Step B42: When the global fallback protection timer expires and the global reference count is not zero, the global status flag is reset to running and the global reference count is reset to zero. It should be noted that resetting the global status flag to "Running" forcibly removes the target server's fault isolation state, allowing the authentication request distribution module to reinstate the server into the list of available servers for load balancing. Resetting the global reference count to zero forcibly clears the reference count for that server, thereby releasing system resources.

[0065] Understandably, in complex network environments or multi-threaded concurrent scenarios, there may be anomalies such as lost port status reporting or process suspension preventing the reference count from decrementing to zero. Without external intervention, the faulty server will remain permanently isolated and unable to automatically recover. Therefore, this implementation method, by introducing a global fallback timer to monitor and intervene in the fault isolation process, can avoid permanent locking of server resources or service recovery delays caused by abnormal status of individual ports, thereby improving the robustness of the server dead-time management mechanism and the overall fault tolerance of the system.

[0066] The above are only two feasible implementations of step S40 provided in this embodiment. This embodiment does not specifically limit the specific implementation of step S40.

[0067] Step S50: When the updated global reference count decreases to zero, the global status flag is set to running, and the target server is resumed to use. It should be noted that the updated global reference count decreasing to zero means that after the fault determination and counting management module continuously receives "switchover complete notifications" from each port (e.g., Port 1 to Port N) and performs a decrement operation one by one each time, the counted value becomes zero. This state indicates that all ports in the current NAS device that originally used the target server (e.g., Server A) have completed the fault switchover process and no longer rely on the target server for authentication services.

[0068] Additionally, it should be noted that setting the global status flag to "running" means that after the fault determination and counting management module determines that the reference count is zero, it changes the status flag of the target server in the server status management module from "down" to "running" (for example, setting global_dead_flag from True to False). At this time, the target server is re-identified as an available resource by the system, and subsequent authentication request distribution logic can select the target server again to process new business.

[0069] Understandably, since the global reference count accurately reflects the number of active ports affected by the fault, only when the count reaches zero does it mean that all old business requests have been processed or switched over. Therefore, performing step S50 can prevent premature restoration of the server state while ports are still processing old business or waiting for responses, thereby preventing the confusion between old and new business states or duplicate requests, thus improving the accuracy of server state restoration and the overall stability of the system.

[0070] This embodiment provides a server dead time management method. First, based on the result of sending an authentication request to the target server, it is determined whether a failure has occurred. If a failure is confirmed and its global status identifier is still "running," the identifier is immediately set to "down," and the global reference count of the target server is initialized through the active port usage table—its initial value corresponds to the number of ports using the server when the failure occurred. Subsequently, when a port successfully completes a failover, the global reference count is decremented by one; only when the count reaches zero is the global status identifier finally reset to "running," thereby completing the server's recovery.

[0071] In summary, this application, by combining a global reference counting mechanism with dynamic state collaborative judgment logic, can automatically and dynamically perceive the progress of fault handling without relying on external timers or manual intervention. This not only ensures that the server only resumes service after all relevant ports have completed switching, effectively avoiding service conflicts caused by premature recovery, but also eliminates the blind waiting caused by traditional fixed timeout mechanisms. It solves the technical problems of delayed fault recovery and inconsistent responses in existing technologies, shortens server fault recovery time, and avoids delayed recovery responses.

[0072] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 After step S30, the server dead time management method further includes steps H31-H32: Step H31: Generate a downtime broadcast notification for the target server; It should be noted that a downtime broadcast notification is a system-level command message generated by the server status management module. This message explicitly identifies the target server that has experienced a failure (such as its IP address and port number) and carries a "status change" field to announce that the server has entered a global dead state.

[0073] Step H32: Send the downtime status broadcast notification to all ports so that the ports, based on the downtime status broadcast notification, delete the cache of pending requests for the target server and stop sending authentication requests to the target server. It should be noted that by broadcasting this notification to all active ports (e.g., Port 1 to Port N), fault information can be synchronized within seconds. Upon receiving the notification, each port will immediately execute local cleanup logic: first, clear all pending authentication / accounting messages pointing to the faulty server in the cache queue to prevent invalid data backlog; second, update the local server reachability list, actively blocking the faulty server to avoid continuing to distribute new requests to it before the dead timer expires, thereby effectively reducing network transmission loss and improving the processing efficiency of authentication requests.

[0074] In this embodiment, by immediately triggering a broadcast notification after the global dead state is established, the server state of each port is forced to be synchronized and the local cache is cleared, which solves the problem of resource waste and response delay caused by port cache backlog or asynchronous requests, thereby improving the real-time performance and resource utilization of the authentication system.

[0075] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 After step S50, the server dead time management method further includes steps H51~H52: Step H51: Generate a running status broadcast notification for the target server; It should be noted that the running status broadcast notification is a status synchronization message generated by the server management module. This message contains the target server's identification information and the "running" status code, and is used to inform other components in the system that the target server has been restored to availability.

[0076] Step H52: Send the running status broadcast notification to all ports so that the ports send subsequent authentication requests to the target server based on the running status broadcast notification; It should be noted that after receiving the broadcast notification, all ports will update their local server status mapping table, re-mark the target server as "available", and include it in the load balancer's scheduling scope. This ensures that subsequent authentication requests can be properly distributed to the recovered server, so as to make full use of server resources.

[0077] In this embodiment, by actively broadcasting status information to all ports after the server becomes available again, the server status is quickly synchronized and the load sharing takes effect immediately.

[0078] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the server dead time management method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0079] This application also provides a server dead time management device, please refer to... Figure 4 The device includes: The fault determination module 10 is used to determine whether the target server has failed based on the result of sending an authentication request to the target server; The status determination module 20 is used to determine whether the global status identifier of the target server is "running" if it is determined that the target server has failed. The counting initialization module 30 is used to set the global status identifier to down if it is determined that the global status identifier is running, and to initialize the global reference count of the target server through the active port usage table, wherein the initial value is the number of ports of the target server used when the fault occurs; The counting update module 40 is used to decrement the global reference count by one when the port successfully completes the failover from the target server, so as to obtain the updated global reference count. The counting detection module 50 is used to set the global status flag to running when the updated global reference count decreases to zero, and the target server resumes use.

[0080] The server dead time management device provided in this application, employing the server dead time management method in the above embodiments, can solve the technical problem of how to shorten server fault recovery time and avoid delayed recovery response. Compared with the prior art, the beneficial effects of the server dead time management device provided in this application are the same as those of the server dead time management method provided in the above embodiments, and other technical features in the server dead time management device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0081] This application provides a server dead time management device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the server dead time management method in the first embodiment described above.

[0082] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a server dead time management device suitable for implementing embodiments of this application. The server dead time management device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The server dead time management device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0083] like Figure 5As shown, the server dead time management device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the server dead time management device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the server dead time management device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows server dead time management devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0084] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0085] The server dead time management device provided in this application, employing the server dead time management method in the above embodiments, can solve the technical problem of how to shorten server fault recovery time and avoid delayed recovery response. Compared with the prior art, the beneficial effects of the server dead time management device provided in this application are the same as those of the server dead time management method provided in the above embodiments, and other technical features in this server dead time management device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0086] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0087] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0088] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the server dead time management method in the above embodiments.

[0089] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0090] The aforementioned computer-readable storage medium may be included in the server dead time management device; or it may exist independently and not assembled into the server dead time management device.

[0091] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the server dead-time management device, the server dead-time management device: determines whether the target server has failed based on the result of sending an authentication request to the target server; if the target server has failed, it determines whether the global status identifier of the target server is running; if the global status identifier is running, it sets the global status identifier to down and initializes the global reference count of the target server through an active port usage table, wherein the initial value is the number of ports using the target server when the failure occurred; when a port successfully completes a failover from the target server, it decrements the global reference count by one to obtain an updated global reference count; when the updated global reference count decreases to zero, it sets the global status identifier to running, and the target server resumes use.

[0092] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0094] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0095] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described server dead-time management method. This solves the technical problem of how to shorten server fault recovery time and avoid delayed recovery response. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the server dead-time management method provided in the above embodiments, and will not be repeated here.

[0096] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for managing server dead time, characterized in that, The method includes: Based on the result of sending the authentication request to the target server, it is determined whether the target server has malfunctioned; If it is determined that the target server has failed, determine whether the global status identifier of the target server is "running". If the global status identifier is determined to be running, the global status identifier is set to down, and the global reference count of the target server is initialized through the active port table, wherein the initial value is the number of ports of the target server used when the failure occurs; When the port successfully completes the failover from the target server, the global reference count is decremented by one to obtain the updated global reference count; When the updated global reference count decreases to zero, the global status flag is set to running, and the target server resumes operation.

2. The method as described in claim 1, characterized in that, The steps described above include initializing the global reference count of the target server using a table via an active port: When it is detected that the global status identifier is set to down, the active port usage table corresponding to the target server is queried. The active port usage table is used to record in real time the port identifiers that are currently using the target server and whose authentication requests have not yet received a response or have not yet completed failover. The number of records in the active port usage table is counted, and this number is assigned as an initial value to the global reference count to complete the initialization of the global reference count.

3. The method as described in claim 2, characterized in that, The method further includes: When a port sends an authentication request to the target server, the port identifier of the port and the binding relationship with the target server are registered in the active port usage table; When the last authentication request for the target server on the port has received a response or was abandoned due to timeout, the corresponding binding relationship is deleted from the active port usage table.

4. The method as described in claim 1, characterized in that, After initializing the global reference count of the target server using a table via an active port, the method further includes: Generate a broadcast notification of the downtime status of the target server; The downtime status broadcast notification is sent to all ports, so that the ports, based on the downtime status broadcast notification, delete the cache of pending requests for the target server and stop sending authentication requests to the target server.

5. The method as described in claim 1, characterized in that, After the step of setting the global status flag to running and the target server resuming use when the updated global reference count decreases to zero, the method further includes: Generate a live status broadcast notification for the target server; The running status broadcast notification is sent to all ports so that the ports, based on the running status broadcast notification, send subsequent authentication requests to the target server.

6. The method as described in claim 1, characterized in that, The step of decrementing the global reference count by one when the port successfully completes the failover from the target server to obtain the updated global reference count includes: Monitor the request processing status of the port for the target server; If it is detected that the port has sent the request to the backup server, or the port has exhausted its retransmission count for the target server, it is determined that the port will no longer use the target server. Receive a handover completion notification sent by the port, wherein the handover completion notification includes the port identifier of the port; Based on the port identifier, query the active port usage table and unbind the port from the target server. After confirming successful unbinding, decrement the global reference count by one.

7. The method as described in claim 1, characterized in that, The method further includes: When the global status flag is set to down, a global fallback protection timer is started; When the global fallback protection timer expires and the global reference count is not zero, the global status flag is reset to running and the global reference count is reset to zero.

8. A server dead time management device, characterized in that, The device includes: The fault determination module is used to determine whether the target server has failed based on the result of sending an authentication request to the target server; The status determination module is used to determine whether the global status identifier of the target server is "running" if it is determined that the target server has failed. The counting initialization module is used to set the global status identifier to down if it is determined that the global status identifier is running, and to initialize the global reference count of the target server through the active port usage table, wherein the initial value is the number of ports of the target server used when the fault occurs; The counting update module is used to decrement the global reference count by one when the port successfully completes the failover from the target server, so as to obtain the updated global reference count. The counting detection module is used to set the global status flag to running when the updated global reference count decreases to zero, and the target server resumes use.

9. A server dead time management device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of a server dead time management method as claimed in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of a server dead time management method as described in any one of claims 1 to 7.

Images