A link state self-recovery system based on server nodes

Abstract

This invention discloses a link state self-recovery system based on server nodes, relating to the field of link recovery technology. Each server node locally measures the initial packet loss rate p0 of the directly connected link, obtains the packet loss rate vector through continuous detection, and calculates the degradation depth vector D and peak degradation dmax. A topology degradation matrix M is constructed through peer-to-peer broadcasting and versioned aggregation. The matrix M is mapped to a directed graph of remaining capacity. Distributed parallel execution of minimum cut-maximum flow analysis is performed, and restricted hop paths are enumerated. Bottleneck capacity is determined along the path, and recoverable bandwidth is calculated according to the service level coefficient. A greedy minimum node selection strategy is used to lock the subset of paths that meet the service bandwidth threshold β, generating a path remapping rule set C. Link self-recovery is completed through transactional atomic distribution and hot replacement of local forwarding tables. This invention does not require a central controller or additional monitoring hardware and can achieve millisecond-level, verifiable, and rollback-capable link recovery in a distributed environment.

Description

Technical Field

[0001] This invention relates to the field of link recovery technology, and more specifically to a link state self-recovery system based on server nodes. Background Technology

[0002] Existing large-scale internet services typically employ a centralized network controller to uniformly schedule links between data centers and edge server nodes. When link jitter or single-point failures occur, the central controller needs to perform a three-stage operation of collection, calculation, and distribution to complete the path switching, a process that often takes tens of seconds to several minutes. For small-scale private networks with extremely high latency sensitivity and a limited number of links, such as those used in high-frequency financial trading, vehicle-road cooperative control, and disaster emergency rescue command, if the main link cannot be restored within 10 ms, it will lead to transaction matching failures, vehicle loss of control, or loss of rescue information, resulting in extremely high economic and security costs.

[0003] For the above scenarios, existing technologies use solutions based on SDN hot standby controllers, external link monitors, or redundant fiber optic ring networks. However:

[0004] (1) Hot standby controllers rely on dedicated hardware, which is costly and complex to deploy;

[0005] (2) Out-of-band monitoring requires additional monitoring links and cannot be applied to emergency scenarios with limited space or power.

[0006] (3) Redundant fiber optic ring networks are only suitable for fixed fiber optics and cannot cover temporary 5G MEC small stations and UAV relay links.

[0007] Therefore, how to achieve millisecond-level self-recovery of link status and ensure business continuity solely through the collaboration of server nodes without relying on a central controller or additional monitoring hardware has become an urgent problem to be solved. Summary of the Invention

[0008] The purpose of this invention is to provide a link state self-recovery system based on server nodes to address the shortcomings of the prior art.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a link state self-recovery system based on server nodes, comprising:

[0010] Link health detection module: Locally obtain the initial packet loss rate p0 of the current directly connected link on each server node and write p0 into the node status table T1;

[0011] Degradation depth calculation module: In the subsequent k health check cycles, the packet loss rate vector P of the link is measured respectively, the link degradation depth vector D is calculated based on P, and D is appended and stored in the node status table T1.

[0012] Topology Coordination Module: Each server node collaboratively constructs a topology degradation matrix M based on the node status table T1 through peer-to-peer broadcasting, where M(j,h) is the maximum degradation depth of the link from node j to node h.

[0013] Distributed path calculation module: Performs minimum cut-maximum flow analysis on the topology degradation matrix M to determine the set of candidate backup forwarding paths R={r1,r2,…,rj,…,rm} that meet the service bandwidth threshold β, and calculates the recoverable bandwidth bj for each path rj;

[0014] Rule generation module: Selects the path subset with the smallest number of nodes based on bj sorted from largest to smallest, and generates path remapping rule set C;

[0015] Update module: Each involved node synchronously executes its corresponding path remapping rule set C in its local forwarding table to complete the link state self-recovery.

[0016] Preferably, the link health detection module includes:

[0017] Within the network interface controller of the server node, sequential User Datagram Protocol (UDP) heartbeat packets are sent to directly connected neighbors according to a preset detection cycle, and the transmission count Ns is recorded.

[0018] Meanwhile, within the network interface controller, heartbeat feedback packets are received to obtain the reception count Nr, and the initial packet loss rate p0 is calculated according to the formula p0=(Ns-Nr) / Ns;

[0019] Write the initial packet loss rate p0 and the corresponding timestamp into the link entry of node status table T1 in key-value pair form.

[0020] Preferably, the degradation depth calculation module includes:

[0021] Start the period counter and read the current packet loss rate pi of the same link entry from the node status table T1 within k consecutive health check periods;

[0022] For each detection cycle, the corresponding initial packet loss rate p0 is read, and the absolute value of the difference between the current packet loss rate pi and p0 is divided by p0 to obtain the single-cycle degradation depth di;

[0023] The k degradation depths di are written into the link degradation depth vector D in the order of detection, and the maximum element value dmax of the vector is calculated to characterize the peak degradation degree of the link within the observation window.

[0024] The link degradation depth vector D and the maximum element value dmax are stored in the node state table T1 through an atomic append operation, and the state synchronization thread is triggered.

[0025] Preferably, the process of storing the link degradation depth vector D and the maximum element value dmax into the node state table T1 through atomic append operations includes the following steps:

[0026] The link degradation depth vector D to be written is serialized with the maximum element value dmax into a fixed-length record R, and the record integrity check hash H is calculated.

[0027] Read the tail offset offprev of the target link entry in T1, and simultaneously call a 128-bit compare and swap instruction to atomically compare and update the offset with offprev+|S|+|H|. If the update is successful, lock the write window. The write window is a predetermined continuous address range in the persistent storage of the node state table T1 for an atomic append write operation.

[0028] Write record R and its check hash H sequentially at the starting address of offprev to complete the atomic append persistence of the link degradation depth vector D and the maximum element value dmax;

[0029] After the write is complete, a status append success signal is generated and pushed to the status synchronization thread.

[0030] Preferably, the topology collaboration module includes:

[0031] After receiving the state append success signal pushed by the state synchronization thread, the peer broadcast thread serializes the link degradation depth vector D and the maximum element value dmax through the protocol buffer and adds a 32-bit cyclic redundancy check code to form an incremental synchronization data frame F.

[0032] The peer-to-peer broadcast thread uses a vector clock-based progressive hash comparison rule to generate an eight-byte incrementing version number for data frame F and sends it to all neighboring nodes through the multicast user datagram protocol port. After sending, it starts a wait timer Twait.

[0033] The broadcast receiving thread performs checksum verification and version number comparison on each received data frame within the Twait time window. Only when the version number is greater than the local cache version number is the local candidate maximum degradation value updated with dmax and the source node identifier recorded.

[0034] When the number of source nodes of the verified data frame reaches the preset statutory number Q or the Twait timeout occurs, the corresponding element M(j,h) of the topology degradation matrix M is filled according to the latest candidate maximum degradation value.

[0035] Preferably, the peer-to-peer broadcast thread employs a progressive hash comparison rule based on a vector clock, including:

[0036] Before generating incremental synchronization frames, the peer broadcast thread appends a 32-bit cyclic redundancy check code to the link identifier.

[0037] After the peer-to-peer broadcast thread uses a vector clock algorithm to write an eight-byte version number for the incremental synchronization frame, it sends it hop-by-hop to all neighboring nodes through a reliable multicast protocol.

[0038] The broadcast receiving thread rearranges the received incremental synchronization frames in ascending order of version number in the verification buffer, checks the integrity identifier within the frame, and writes the degraded data into the local candidate degradation table after the verification is passed.

[0039] When the version number of the same link in the candidate degradation table increases consecutively to a preset threshold three times, the matrix construction thread updates the corresponding element of the topology degradation matrix accordingly.

[0040] Preferably, the distributed path calculation module includes:

[0041] Within each server node, the topology degradation matrix M is converted into a directed graph with remaining capacity;

[0042] A parallel push-remark algorithm based on vertex partitioning is used to perform minimum cut-maximum flow calculation on the directed graph with remaining capacity to obtain a set of all feasible source-destination paths that satisfy the service bandwidth threshold β;

[0043] For each feasible path, calculate its recoverable bandwidth value, and write the path number and bandwidth value into the candidate path table in descending order of recoverable bandwidth.

[0044] When the cumulative recoverable bandwidth of the paths in the candidate path table reaches or exceeds the threshold β for the first time, the current path sequence in the table is locked as the candidate backup forwarding path set R.

[0045] Preferably, calculating the recoverable bandwidth value for each feasible path includes the following steps:

[0046] Search each edge in the directed graph with remaining capacity segment by segment along the candidate path, extract the edge capacity value and generate an edge capacity sequence;

[0047] Perform a point-by-point comparison operation on the edge capacity sequence, and determine the minimum edge capacity in the sequence as the bottleneck capacity of the path;

[0048] Set the service level coefficient γ, and the recoverable bandwidth value is equal to the bottleneck capacity multiplied by the service level coefficient.

[0049] Preferably, the rule generation module includes:

[0050] The priority queue is invoked to search the candidate path table, and the recoverable bandwidth bj of each path is sorted from high to low and output as an ordered sequence.

[0051] The ordered sequence is read sequentially, and each path is added one by one according to the greedy accumulation algorithm. The process stops when the cumulative recoverable bandwidth first reaches or exceeds the service bandwidth threshold β, thus obtaining a subset of paths that satisfy Σbi≥β and have the smallest number of nodes.

[0052] Convert the path subset into a list of node identifier-input port-output port triples, and use the rule template compiler to generate the corresponding path remapping rule set C;

[0053] The path remapping rule set C is distributed to all server nodes involved in the path subset at once, triggering hot replacement of the forwarding table on each node.

[0054] Preferably, the step of adding each path sequentially using a greedy cumulative algorithm includes:

[0055] Initialize the recoverable bandwidth accumulator B to 0 and set the candidate backup forwarding path set R to empty;

[0056] Pop the first path record rj from the bandwidth sorting priority queue in sequence, add its recoverable bandwidth value bj to the accumulator B using a 64-bit atomic addition instruction, and write it back;

[0057] If the updated accumulator B is less than the service bandwidth threshold β, then write path rj into the path subset and continue to pop the next record;

[0058] If the updated accumulator B is greater than or equal to the threshold β, then popping stops and the current path subset is locked.

[0059] The technical effects and advantages provided by the present invention in the above technical solution are as follows:

[0060] 1. This invention continuously collects the initial packet loss rate p0 of the link locally on each server node, and uses the degradation depth vector D and peak degradation dmax as observation units. A topology degradation matrix M is generated through peer-to-peer broadcasting and versioned aggregation, enabling rapid consensus on the actual network degradation state among distributed nodes. Based on the directed graph of remaining capacity obtained by mapping M, this invention performs minimum cut-maximum flow calculation in parallel on each node and enumerates paths with limited hop counts. The recoverable bandwidth is calculated based on bottleneck capacity, and a greedy minimum node selection strategy is used to lock the path set R. Finally, a rule set C is generated through transactions and atomically distributed, and hot-replaced in the local forwarding table. Overall, this achieves an end-to-end millisecond-level link self-recovery closed loop from observation, coordination, calculation to distribution.

[0061] 2. This invention has significant engineering advantages: on the one hand, it does not require a central controller or additional monitoring hardware, significantly reducing deployment costs and single-point failure risks, while ensuring real-time performance and scalability through parallel computing and message batch processing; on the other hand, it adopts fixed-point representation, atomic operations, two-stage commit and rollback strategies to ensure numerical consistency, operational atomicity and auditability, supports business priority conversion and secure and reliable seamless switching, thereby improving business availability and robustness in high real-time, resource-constrained or temporary networking scenarios. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0063] Figure 1 This is a flowchart of the system modules of the present invention. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0065] For examples, please refer to Figure 1 As shown in this embodiment, a link state self-recovery system based on a server node includes:

[0066] Link health detection module: Locally obtain the initial packet loss rate p0 of the current directly connected link on each server node and write p0 into the node status table T1;

[0067] A heartbeat sending thread is deployed within the network interface controller of the server node. The detection period Δt is set via a configuration file, with a default value of 100 milliseconds, which can be adjusted between 10 milliseconds and 1 second according to business real-time requirements. Within each detection period, the heartbeat sending thread sends one User Datagram Protocol (UDP) data packet to the peer node directly connected to this node; the first byte of this data packet carries a 32-bit monotonically increasing sequence number in the payload for unique identification. For each successfully sent frame, the sending counter Ns increments by 1 for subsequent packet loss statistics.

[0068] A heartbeat receiving thread is deployed within the same network interface controller, continuously listening to a predefined heartbeat port. When an echo data packet carrying a sequence number is received, the receiving thread confirms the transmission record based on the sequence number and increments the receive counter Nr by 1. At the end of each detection cycle, the packet loss rate calculation algorithm is called: first, the number of lost frames is obtained by subtracting the receive counter Nr from the transmit counter Ns; then, this number of lost frames is divided by the transmit counter Ns, and the resulting ratio is the initial packet loss rate p0. If the transmit counter Ns is 0, the algorithm returns 0 to avoid division by zero. This algorithm is defined as follows: within a detection cycle, the initial packet loss rate is equal to the ratio of the difference between the total number of transmitted frames and the total number of received frames to the total number of transmitted frames. Its output is a decimal between 0 and 1, accurate to four decimal places.

[0069] The node status table T1 is constructed using a key-value storage model. The key field consists of a "link identifier + timestamp," where the link identifier is a string of "local port number - neighboring port number," and the timestamp is in Unix milliseconds. The value field stores the corresponding initial packet loss rate p0. The write thread calls the atomic write interface to generate table entries after calculation.<linkid,timestamp,p0> It is then persisted to a local key-value database; upon successful writing, a "data ready" event is simultaneously published to the degradation depth calculation thread to ensure continuous computation of subsequent degradation vectors.

[0070] It should be noted that the above steps achieve parameter consistency through a unified detection period Δt and the same pair of counters Ns and Nr, ensuring the completeness and reproducibility of the link health detection module.

[0071] Degradation depth calculation module: In the subsequent k health check cycles, the packet loss rate vector P of the link is measured respectively, the link degradation depth vector D is calculated based on P, and D is appended and stored in the node status table T1.

[0072] The period counter is driven by the detection period Δt, which is configured to be 100 milliseconds by default and can be configured in the range of 10 milliseconds to 1000 milliseconds; the parameter k defaults to 8 and can be configured in the range of 4 to 64.

[0073] At the arrival of each detection cycle, the degradation depth calculation module reads the latest packet loss rate entry corresponding to the target link through the atomic read interface of the node status table T1. The read fields are "link identifier, timestamp, and current packet loss rate pi".

[0074] If the read fails (e.g., read timeout or miss), perform up to 3 retries, with a 10-millisecond interval between each retrieval; if the retries still fail, mark the current packet loss rate as a missing value and assign a placeholder value of 1.000000 (representing 100% packet loss) to ensure that the calculation window is not blocked.

[0075] After collecting k valid or placeholder pi values ​​in chronological order, proceed to the next step of calculation.

[0076] For each read current packet loss rate pi, the atomic read interface of the node status table T1 is called to read the initial packet loss rate p0 and its timestamp stored in the same link entry; if p0 does not exist, the degradation depth calculation module uses the placeholder value 0.000100 as the minimum divisible value according to the startup initialization strategy.

[0077] The calculation algorithm is as follows: First, calculate the absolute value of the difference between the current packet loss rate and the initial packet loss rate. Then, divide this absolute difference by the initial packet loss rate. The resulting ratio is the single-cycle degradation depth di. To avoid numerical divergence caused by dividing by zero or having an excessively small denominator, if p0 is less than 0.000100, then 0.000100 is used as the divisor. Each di is rounded to 6 decimal places to ensure numerical consistency, and the value is stored as a 32-bit unsigned integer multiplied by 1,000,000 (i.e., fixed-point representation) to eliminate floating-point portability issues.

[0078] The degradation depth calculation module allocates a vector Dbuffer of length k in memory, and writes each di represented by a fixed point into the corresponding index position of Dbuffer in the sampling order.

[0079] During the writing process, a local maximum value variable curmax is maintained, which is initially 0; each time di is written, it is compared with curmax and curmax is updated if necessary.

[0080] After the vector is written, the value of curmax is assigned to dmax, which is also represented as a 32-bit unsigned integer multiplied by 1,000,000 for subsequent fast retrieval.

[0081] The vectors Dbuffer and dmax are prepared in memory to be written to persistent records according to serialization conventions.

[0082] Serialization format definition (fixed-length record): Link identifier: 16 bytes, fixed as 8 bytes of binary encoding for the local port number and the neighboring port number;

[0083] Sampling window timestamp: 8 bytes, Unix milliseconds;

[0084] Vector length k: 2 bytes, unsigned integer;

[0085] Vector sample: k×4 bytes, each item is a 32-bit unsigned fixed-point number as described above;

[0086] Maximum element value dmax: 4 bytes, 32-bit unsigned fixed-point number;

[0087] Total record length |S| = 16 + 8 + 2 + 4 × k + 4 bytes.

[0088] Calculation of check hash H: Perform SHA-256 operation on record R, and take its first 16 bytes as 128-bit check hash H, which is used for subsequent atomicity verification and tamper detection.

[0089] Read the tail offset offprev: Obtain the 64-bit tail offset offprev by performing an atomic read on the tail pointer metadata item of the node state table T1. It represents the file offset that can be appended and written at the moment.

[0090] Implementation details of updating the tail offset of atoms: Construct a 128-bit atomic field for alignment and swap operations, the field content of which is a binary tuple.<offprev,version> The `version` directive is a 64-bit version number. The platform atomic instruction is invoked to perform a comparison and swap (e.g., using `CMPXCHG16B` on x86 platforms or a 128-bit atomic `compareexchange` operation in supported programming languages), transferring the tuple...<offprev,version> and<offprev+|S|+|H|,version+1> Perform an atomic comparison and update. If the update is successful, lock the write window, which is a predefined contiguous address range in the persistent storage of the node state table T1 for a single atomic append write operation;

[0091] If the comparison and swap fails, the latest tail offset is reread and the process is retried, with a maximum of 8 retries. If the platform does not support 128-bit atomic instructions, a local file descriptor-level exclusive lock is used to achieve mutual exclusion. After acquiring the lock, the tail offset is updated.

[0092] Write record R and check hash H: After obtaining the writable starting offset offprev, write record S at that offset in byte order, followed by writing the check hash H. This completes the disk buffer write and calls the file synchronization interface to persist the data (using fdatasync or an equivalent interface). After the write is complete, update the in-memory tail offset cache to speed up subsequent operations.

[0093] Triggering the state synchronization thread: Upon successful write, a "state append successful" event message is constructed. The message fields include the link identifier, write start offset offprev, new tail offset offprev+|S|+|H|, sampling timestamp, dmax, and checksum hash H. This message is sent to the state synchronization thread via a local Unix domain socket with a message length prefix frame. Upon receiving the message, the state synchronization thread performs message verification (verifying that H matches the S read from persistence) and updates the node state table T1 interface of the peer node.

[0094] Exception handling and rollback strategy: If write or synchronization fails, the record can be retried up to 3 times, with an interval of 50 milliseconds between each retry; if it still fails after retry, the write operation returns an error code and triggers a local alarm record for manual intervention, while state synchronization will not be triggered to avoid propagating incomplete data.

[0095] The above implementation steps ensure that: from periodically reading pi, reading p0 and calculating di item by item, constructing vector D in memory in an ordered manner and obtaining dmax, to atomically appending the serialized record S and check hash H to the node state table T1, and finally notifying the state synchronization thread with a reliable message, a continuous, verifiable and atomically guaranteed data stream is formed, providing usable and consistent observation data for the subsequent construction of the topology degradation matrix.

[0096] Topology Coordination Module: Each server node collaboratively constructs a topology degradation matrix M based on the node status table T1 through peer-to-peer broadcasting, where M(j,h) is the maximum degradation depth of the link from node j to node h.

[0097] Upon receiving the "state append successful" signal from the state synchronization thread, the peer broadcast thread reads the link identifier, sampling window start timestamp, link degradation depth vector D, and maximum element value dmax from the node state table T1. The peer broadcast thread constructs frame F according to the following byte serialization payload (fixed-length field order):

[0098] Link identifier: 16 bytes, binary encoded, formatted as 8 bytes of local port number + 8 bytes of neighboring port number;

[0099] Sampling window start timestamp: 8 bytes, in milliseconds on Unix;

[0100] Vector length k: 2 bytes, unsigned integer;

[0101] Vector sample D: k×4 bytes, each item is a 32-bit unsigned fixed-point number, representing the degradation depth multiplied by 1,000,000;

[0102] Maximum element value dmax: 4 bytes, 32-bit unsigned fixed-point number;

[0103] Sending node identifier: 16 bytes;

[0104] Vector clock carrier: n×8 bytes, where n is the number of known neighbors of this node in the vector clock entries.

[0105] A 32-bit cyclic redundancy check code is calculated for the load using the ISO / IEC 3309 standard polynomial. The resulting 4 bytes are appended to the end of the frame to form the integrity identifier of frame F.

[0106] The peer broadcast thread performs the following operations before sending:

[0107] Increment the local node entry of the local node vector clock by 1; input the updated vector clock and serialized payload into the SHA-256 hash function, take the first 8 bytes of the hash value and XOR it with the local monotonic counter to generate an 8-byte version number; this version number satisfies strict growth requirements in terms of causality and monotonicity.

[0108] Hop-by-hop reliable multicast transmission employs a hop-by-hop acknowledgment and selective retransmission strategy based on the User Datagram Protocol (UDP): the transmitting direction sends frame F to each neighbor. Upon receiving the frame, the neighbor immediately sends a one-byte acknowledgment message upstream, carrying an eight-byte version number. If the upstream does not receive an acknowledgment within 50 milliseconds, it retransmits the frame, with a maximum of three retransmissions. The retransmission interval uses an exponential backoff sequence of 50 milliseconds, 100 milliseconds, and 200 milliseconds. After transmission is complete, the peer broadcast thread starts a wait timer Twait, with a default value of 200 milliseconds, which can be adjusted according to network size.

[0109] The broadcast receiving thread performs the following processing on each received frame F:

[0110] Perform a 32-bit cyclic redundancy check (CRC) verification; log and discard frames that fail the verification.

[0111] Frames that pass verification are inserted into the verification buffer in ascending order according to their eight-byte version numbers; if a version sequence is missing, a selective retransmission request is immediately sent to the next hop, and selective retransmission can be retried a maximum of 2 times;

[0112] For frames with version numbers greater than the locally cached version number, the dmax value within the frame is extracted and written into the corresponding link entry of the candidate degradation table along with the source node identifier. The candidate degradation table is implemented using a hash mapping, and each entry contains the most recent 8 version number histories, the corresponding dmax sequence, and the set of source nodes.

[0113] To prevent replay attacks, the receiver also verifies the intra-frame vector clock: it requires that at least one of the locally stored peer version of the intra-frame vector clock is strictly incremented; if this condition is not met, the frame is marked as abnormal and an audit log is recorded.

[0114] The value of the legal quantity Q is calculated according to the majority principle of the number of neighbors: if the total number of neighbors of this node is Nneighbors, then Q = floor(Nneighbors / 2) + 1.

[0115] Within the waiting timer Twait window, the broadcast receiving thread counts the number of unique source nodes for the same link in the candidate degradation table. When this count reaches Q, or when the waiting timer Twait times out, the matrix construction thread selects the maximum dmax value from the candidate degradation table as the final aggregation result. If all candidate records are missing, a placeholder value of 1000000 (representing a 100% packet loss rate) is written in a fixed-point representation, and a timestamp is recorded for subsequent diagnosis. The matrix construction thread writes the final dmax value in a fixed-point format to the corresponding element M(j,h) of the topology degradation matrix M, and simultaneously writes the source node set and the sampling timestamp.

[0116] To suppress frequent flash updates, the matrix construction thread adopts a minimum hold time of 500 milliseconds for writing to the same matrix element: if a larger dmax appears within 500 milliseconds after writing, only the candidate degenerate table is updated but the matrix M is not immediately overwritten until the minimum hold time expires before a merge decision is made.

[0117] In scenarios where communication fails, the sender's retransmission mechanism and the receiver's selective retransmission ensure that frames can be recovered under normal network disturbances. If retransmission fails, the broadcast receiver thread records an alarm and handles missing data according to a placeholder strategy to ensure the progress of matrix construction. To prevent data forgery or replay, the frame incorporates a vector clock consistency check and a 32-bit cyclic redundancy check code to provide integrity and causality checks. The receiver marks frames that do not meet the conditions as abnormal and records audit information.

[0118] Distributed path calculation module: Performs minimum cut-maximum flow analysis on the topology degradation matrix M to determine the set of candidate backup forwarding paths R={r1,r2,…,rj,…,rm} that meet the service bandwidth threshold β, and calculates the recoverable bandwidth bj for each path rj.

[0119] The distributed path calculation module obtains the physical link bandwidth MB and the corresponding maximum degradation depth dmax by reading each link entry in the topology degradation matrix M. For each directed edge e, the capacity CM of each edge in the graph is defined as: CM = MB × (1 - dmax). To ensure cross-platform consistency, the edge capacity is represented using fixed-point notation, where the floating-point product is multiplied by 1,000,000 and rounded to a 32-bit unsigned integer for storage. This edge capacity is used as the initial residual capacity of Gres, and Gres is constructed in memory using an adjacency list data structure. The edge entry contains the fields: target vertex identifier, initial capacity, current residual capacity, and edge unique identifier.

[0120] To parallelize computation, the graph vertices are divided into P vertex partitions based on the hash value of their vertex identifiers modulo the number of available computation cores P. Each partition is computed by an independent thread. Each thread maintains a local active vertex queue, a local height label array, and a local parallel work queue. The implementation details of the parallel push-relabel algorithm are as follows:

[0121] Initialization: Perform a pre-flow injection operation on the source vertex, subtract the injected flow from the residual capacity of the corresponding edge and update the corresponding residual field; set the source vertex height to the total number of vertices, and initialize the height of other vertices to 0.

[0122] Local push and relabeling: The thread retrieves active vertices from the local active queue and attempts to push them along their outgoing edges. During the push, the remaining capacity of the target edge is updated using an atomic comparison and swap operation. If all outgoing edges cannot be pushed locally, a local relabeling operation is performed to update the height label.

[0123] Cross-partition interaction: When pushing edges that cross partitions, the thread packages the changes into a cross-partition message and sends it to the target partition. Cross-partition messages use a batching and backpressure strategy, with a default batch size of 64 messages to reduce synchronization overhead. After receiving the batch message, the target partition sets the corresponding vertex to active and applies the changes to its local remaining capacity.

[0124] Termination condition: Parallel computation terminates when all active vertex queues in all partitions are empty and the cross-partition message queues are empty, or when the maximum iteration limit of 1,000 is reached. To avoid infinite loops, the algorithm returns the current approximate maximum flow result and logs a warning after reaching the iteration limit.

[0125] After obtaining the residual capacity graph, for each source-destination pair requiring guaranteed bandwidth, path enumeration is performed under the following constraints: a breadth-first search with a limited number of hops is used, with the upper limit L set to 15 to avoid latency and resource consumption caused by excessively long paths; an improved variant of the Yen algorithm is used to enumerate a maximum of Npath=16 simple paths. For each enumerated path, the path analysis unit reads the current residual capacity (represented by fixed vertices) of each edge in path order, writes these capacities into the path's local cache in path order, forming an edge capacity sequence for subsequent reduction operations.

[0126] A point-by-point comparison operation is performed on the edge capacity sequence of the path, and the minimum value in the sequence is taken as the bottleneck capacity of the path. The bottleneck capacity is represented by a fixed point. The service level coefficient γ is determined by the service policy table, with a value range of 0.50 to 1.00 and a default value of 0.90. In the default case, when no service policy record is found, the default γ=0.90 is used; for urgent or critical services, operations and maintenance can cover γ online up to the upper limit of 1.00, and for background or low-priority services, it can be lowered to the lower limit of 0.50; the policy table supports automatic rollback over time and dynamic adjustment based on runtime congestion indicators, but any dynamic adjustment must record the reason for the change and the timestamp for auditing and traceability.

[0127] Calculate the recoverable bandwidth value: The recoverable bandwidth value equals the bottleneck capacity multiplied by the service level factor γ. The calculation result is represented in fixed-point format and submitted to the candidate path table in key-value pair form.

[0128] The candidate path table is implemented using a concurrency-safe data structure. Write operations employ atomic append and atomic accumulation: whenever a path and its recoverable bandwidth value are written, the write unit performs an atomic accumulation operation on the table's global accumulator and reads the current accumulated sum. If this accumulated sum is greater than or equal to the service bandwidth threshold β (β is represented by a fixed point and provided by the service request), the current path sequence in the candidate path table, sorted in descending order of recoverable bandwidth, is atomically marked as the candidate backup forwarding path set R using a write lock, and the write lock is released. Subsequently, the write unit sends a "path set ready" event to the path optimization unit to trigger subsequent path optimization and rule generation steps. To ensure idempotency, the path set locking operation includes a timestamp and a unique transaction identifier.

[0129] To eliminate floating-point discrepancies, all capacity and bandwidth values ​​are represented using fixed-point notation with a multiplier of 1,000,000. Concurrent modifications across threads and nodes employ atomic operations or message batching to ensure consistency. If read-write conflicts occur during candidate path enumeration or writing, the write unit should retry a maximum of 8 times based on optimistic concurrency control, with an exponential backoff strategy for the retry interval. If parallel push-remarking fails to complete after reaching the maximum number of iterations, the system records the current result and uses it as an approximate input for path selection, while simultaneously triggering log recording for manual or upper-level strategy adjustments.

[0130] This embodiment directly maps topology degradation observations to residual capacity and performs maximum flow computation and restricted path enumeration in parallel in a distributed environment. Fixed-point representation, atomic operations, and majority-level aggregation ensure numerical consistency and operational atomicity. Bandwidth reduction using the service level coefficient γ further supports bandwidth reservation for different service priorities. The overall method guarantees both computational efficiency to meet millisecond-level self-recovery requirements and robustness and verifiability in a distributed environment.

[0131] Rule generation module: Selects the path subset with the smallest number of nodes based on bj sorted from largest to smallest, and generates path remapping rule set C.

[0132] The rule generation module implements a bandwidth-sorted priority queue using a binary heap. Each item in the priority queue contains the following fields: path identifier, list of path nodes, and path recoverable bandwidth bj (represented by a fixed point). The retrieval operation extracts candidate paths from the table in descending order of bj. This extraction process maintains the heap structure in memory with constant time complexity. To support concurrent access, the priority queue uses read-write locks, and a read-write separation strategy is employed to improve throughput when write concurrency is low.

[0133] The specific steps and concurrent implementation of the greedy accumulation algorithm include:

[0134] Initialization: Set the recoverable bandwidth accumulator B to 0; clear the candidate backup forwarding path set R. Accumulator B is stored as a fixed-point 64-bit unsigned integer.

[0135] Pop and Atomic Accumulation: Pop the first path record rj from the bandwidth-sorted priority queue in sequence. Perform an atomic addition operation on accumulator B using a 64-bit atomic addition instruction provided by hardware or runtime, adding the recoverable bandwidth bj of the path to accumulator B and writing it back; if the platform does not support atomic addition instructions, use a short critical section mutex lock to implement atomic updates.

[0136] Conditional judgment and path writing: Read the B value after atomic accumulation. If the value is still less than the business bandwidth threshold β, then write the path rj into the path subset in an append manner. The write operation uses the atomic append interface and records the path sequence number in the local transaction log to ensure idempotency, and then continues to pop the next record.

[0137] Threshold Triggering and Locking: When the updated B value reaches or exceeds the business bandwidth threshold β, stop popping paths from the priority queue; perform a write lock operation on the current path subset R and set the transaction identifier and timestamp in the table; mark the current path sequence sorted in descending order of recoverable bandwidth as a set to be committed, so as to ensure that subsequent steps read a stable and consistent view.

[0138] Path subset conversion to triple list and rule compilation includes:

[0139] Triple list generation: The rule template generator traverses each path in the path subset R and parses the path node sequence into several "node identifier-in port-out port" triples; each triple is serialized into a 24-byte record with fixed fields (node ​​identifier 16 bytes, in port 4 bytes, out port 4 bytes).

[0140] Template compilation: The rule template compiler compiles the triple list into deployable forwarding table entries according to predefined rule templates. Each entry contains a matching field, action (forwarding to the next hop or modifying the destination address), priority, and transaction version number. Templates support output in several data plane interface formats, such as match-action entry formats or programmable data plane interface call statements. The compilation process generates a rule set C with unique transaction identifiers and packages the rules into atomic transaction batches.

[0141] The atomic distribution and heat replacement of the rule set include:

[0142] Distribution Protocol: A two-phase commit protocol is used for one-time distribution. The first phase is the preparation phase: the issuer sends the records of rule set C, transaction identifiers, and check hashes to all server nodes involved in the path subset and requests a readiness confirmation; after the number of confirmations reaches the majority acknowledgment threshold (e.g., half the number of nodes plus one), the second phase begins.

[0143] Commit and Hot Replacement: The second phase is the commit phase: Each node writes the new rules to a temporary rule table locally, ensuring it coexists with the old table. Then, an atomic pointer swap is performed to point the active forwarding table to the new rule set, thus completing the hot replacement. Subsequently, each node asynchronously cleans up the old rules and records the transaction completion log. If any node returns an error during the preparation or commit phase, a rollback is performed: all nodes that have written temporary rules revert the temporary entries and release write locks, the transaction is marked as failed, and written to the fault log.

[0144] Idempotency and Timeout: All sent messages include a transaction identifier, timestamp, and checksum hash. The receiving end performs idempotent processing on duplicate messages. The default timeout threshold is 5,000 milliseconds. After the timeout, a rollback is initiated and an upper-layer alarm is reported.

[0145] To prevent inconsistencies caused by partial node success and partial node failure, write locks and two-phase commit ensure that they only take effect when a majority of nodes reach consensus. For extreme network partitions, the rule generation module provides a manual rollback entry and retains the 16 most recent transaction logs locally for auditing purposes. All data fields use fixed-point representation to ensure cross-platform numerical consistency.

[0146] The above implementation details ensure that: from the priority queue output sorted by recoverable bandwidth, through atomic greedy accumulation and path subset locking, until the path subset is compiled into a deployable rule set and distributed to the relevant servers in one go using a transactional, rollback-capable hot-swap method, the steps are tightly connected and the operation is verifiable.

[0147] Update module: Each involved node synchronously executes its corresponding path remapping rule set C in its local forwarding table to complete the link state self-recovery.

[0148] After receiving the rule set C and its transaction identifier from the rule generation module, the update module first performs a parsing operation on the rule set C. The rule records adopt a fixed binary format, and the field order and definition are as follows: transaction identifier (16 bytes, random or timestamp-derived unique identifier), version number (8 bytes), number of rules (4 bytes), each rule entry (variable length, including path identifier, matching field, action field, priority, expiration time), and check hash (16 bytes, taking the first 16 bytes of SHA-256).

[0149] The parser verifies the consistency of the transaction identifier and performs integrity verification on the check hash; if the verification fails, it returns an error and writes it to the local persistent transaction log. Static syntax and semantic constraint checks are performed on each rule: matching fields cannot conflict with local protected table entries, action fields cannot create loops, and priority values ​​are within the allowed range. After the syntax and semantic checks pass, the process proceeds to the next stage.

[0150] A temporary rule table identifier, `temp_table_id`, is allocated locally for this transaction on this node, and the rule set entries are written to the local temporary rule table storage using fixed-point representation. The temporary rule table and the active forwarding table employ a double-buffered design in their data structures: two rule table structure pointers, `active_ptr` and `staging_ptr`. `active_ptr` points to the currently effective set of rules, while `staging_ptr` points to and operates on the temporary rule table during the preparation phase. The temporary rule table completes index construction and performs a consistency scan in memory, generating the estimated match set and forwarding next-hop list for each rule.

[0151] For implementations on programmable hardware (e.g., based on programmable data plane interfaces): temporary rules are loaded into inactive table partitions by calling write operations through the corresponding data plane interface; for Linux kernel data plane implementations: rules are written to temporary tables in nftables by calling netlink replacement operations; for software data plane implementations (based on user-space fast paths such as DPDK): entries are allocated and populated for temporary tables in user-space memory. After the write operation is completed, rule consistency assertions and resource quota checks are performed locally; if the requirements are not met, the process is rolled back and written to the log.

[0152] After the temporary rule table is successfully loaded, the update module initiates a traffic purging and verification window to prevent packet loss or out-of-order delivery. To this end, a dual counter is created locally for each affected old rule: an old rule outflow counter and a new rule inflow counter. The update module verifies that the new rule matching and next-hop behavior are consistent with expectations by injecting a small number of probe packets (4 probe packets per path, 5 milliseconds apart) into the data plane. The probe packet payload contains a transaction identifier and sequence number for counter verification. The default probe timeout threshold is 500 milliseconds. If the probe verification passes, the atomic switch phase begins; if the probe fails, it attempts to retry twice, and if the retry fails, a rollback is triggered.

[0153] Atomic hot replacement is implemented using atomic pointer swapping or an equivalent transaction switch: On platforms supporting 64-bit atomic pointer swapping, a single-writer atomic swap operation atomically updates the active forwarding table pointer `active_ptr` to point to `staging_ptr`, instantly making the new rule active. For environments that do not support this atomic operation, a local short critical section write lock is used, and pointer replacement is performed after acquiring the write lock, followed by releasing the write lock to minimize pauses. For nftables environments, the entire table is replaced using nftables' atomic replacement command. For programmable ASIC environments, if the device supports transactional write functionality, the device transaction interface is called to commit; if the device does not support transactional writes, the switch is completed by first writing the standby table index and then atomically updating the control register. The completion of the switch is considered a local commit of the rule.

[0154] After the switch, the update module generates a commit confirmation message locally. This message includes a transaction identifier, node identifier, commit timestamp, and local checksum hash. The module then sends the confirmation message back to the rule generation module or coordinator according to the distributed commit protocol. The timeout threshold for commit confirmation is 5,000 milliseconds. If a majority of confirmations are received, the local temporary table is marked as committed, and an old rule recycling process is initiated in the background: old rules are moved to a garbage table and deleted one by one after a minimum retention time of 1,000 milliseconds. The deletion operations are also written to the local persistent transaction log for auditing. If a majority of confirmations are not received, compensation actions are performed (see below).

[0155] If an unrecoverable error occurs at any stage (including syntax check failure, repeated probe validation failures, switchover failure, or failure to obtain a majority commit confirmation), the update module executes the following rollback steps: Stop any new probe group injection; if an atomic switch has been performed, re-perform an atomic pointer swap to restore the original `active_ptr`; if the atomic swap is irreversible, trigger a manual intervention lock and record a complete transaction log; subsequently, delete the new rule in the temporary rule table and release related resources; report the failure reason and local error code to the rule generation module; the error log includes the transaction identifier, timestamp, failure step number, and relevant counter snapshots. The impact on external traffic during the rollback process is minimized through a priority strategy: sessions already on the forwarding path are prioritized.

[0156] To ensure idempotency, all delivery requests and acknowledgments include a transaction identifier, and idempotency is applied locally. If a duplicate delivery request is received, the transaction identifier is compared against the persistent transaction log, and the result of the last operation is returned directly. All operations record transaction steps in the local persistent log, and the most recent 32 transaction log entries are retained for backtracking. To prevent rule forgery, both delivery and acknowledgment messages carry a checksum hash. The receiving end verifies the checksum hash consistency before performing any write or switch; if the verification fails, execution is rejected and a security alert is reported.

[0157] This embodiment, through explicit preparation, verification, atomic switching, and rollback steps, combined with probe packet verification, a double-buffered table structure, and atomic pointer exchange, enables secure, fast, and reversible application of the path remapping rule set C locally on each involved node. This ensures service continuity and data plane consistency, thereby achieving a closed-loop function for link state self-recovery. The above implementation is applicable to various data plane implementation environments and provides explicit timeout and rollback strategies to handle abnormal network conditions.

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

Claims

1. A link state self-recovery system based on server nodes, characterized in that: include: Link health detection module: Locally obtain the initial packet loss rate p0 of the current directly connected link on each server node and write p0 into the node status table T1; Degradation depth calculation module: In the subsequent k health check cycles, the packet loss rate vector P of the link is measured respectively, the link degradation depth vector D is calculated based on P, and D is appended and stored in the node status table T1. Topology Coordination Module: Each server node collaboratively constructs a topology degradation matrix M based on the node status table T1 through peer-to-peer broadcasting, where M(j,h) is the maximum degradation depth of the link from node j to node h. Distributed path calculation module: Performs minimum cut-maximum flow analysis on the topology degradation matrix M to determine the set of candidate backup forwarding paths R={r1,r2,…,rj,…,rm} that meet the service bandwidth threshold β, and calculates the recoverable bandwidth bj for each path rj; Rule generation module: Selects the path subset with the smallest number of nodes based on bj sorted from largest to smallest, and generates path remapping rule set C; Update module: Each involved node synchronously executes its corresponding path remapping rule set C in its local forwarding table to complete the link state self-recovery.

2. The link state self-recovery system based on server nodes according to claim 1, characterized in that: The link health detection module includes: Within the network interface controller of the server node, sequential User Datagram Protocol (UDP) heartbeat packets are sent to directly connected neighbors according to a preset detection cycle, and the transmission count Ns is recorded. Meanwhile, within the network interface controller, heartbeat feedback packets are received to obtain the reception count Nr, and the initial packet loss rate p0 is calculated according to the formula p0=(Ns-Nr) / Ns; Write the initial packet loss rate p0 and the corresponding timestamp into the link entry of node status table T1 in key-value pair form.

3. The link state self-recovery system based on server nodes according to claim 1, characterized in that: The degradation depth calculation module includes: Start the period counter and read the current packet loss rate pi of the same link entry from the node status table T1 within k consecutive health check periods; For each detection cycle, the corresponding initial packet loss rate p0 is read, and the absolute value of the difference between the current packet loss rate pi and p0 is divided by p0 to obtain the single-cycle degradation depth di; The k degradation depths di are written into the link degradation depth vector D in the order of detection, and the maximum element value dmax of the vector is calculated to characterize the peak degradation degree of the link within the observation window. The link degradation depth vector D and the maximum element value dmax are stored in the node state table T1 through an atomic append operation, and the state synchronization thread is triggered.

4. The link state self-recovery system based on server nodes according to claim 3, characterized in that: The process of storing the link degradation depth vector D and the maximum element value dmax into the node state table T1 through atomic append operations includes the following steps: The link degradation depth vector D to be written is serialized with the maximum element value dmax into a fixed-length record R, and the record integrity check hash H is calculated. Read the tail offset offprev of the target link entry in T1, and simultaneously call a 128-bit compare and swap instruction to atomically compare and update the offset with offprev+|S|+|H|. If the update is successful, lock the write window. The write window is a predetermined continuous address range in the persistent storage of the node state table T1 for an atomic append write operation. Write record R and its check hash H sequentially at the starting address of offprev to complete the atomic append persistence of the link degradation depth vector D and the maximum element value dmax; After the write is complete, a status append success signal is generated and pushed to the status synchronization thread.

5. A link state self-recovery system based on a server node according to claim 1, characterized in that: The topology collaboration module includes: After receiving the state append success signal pushed by the state synchronization thread, the peer broadcast thread serializes the link degradation depth vector D and the maximum element value dmax through the protocol buffer and adds a 32-bit cyclic redundancy check code to form an incremental synchronization data frame F. The peer-to-peer broadcast thread uses a vector clock-based progressive hash comparison rule to generate an eight-byte incrementing version number for data frame F and sends it to all neighboring nodes through the multicast user datagram protocol port. After sending, it starts a wait timer Twait. The broadcast receiving thread performs checksum verification and version number comparison on each received data frame within the Twait time window. Only when the version number is greater than the local cache version number is the local candidate maximum degradation value updated with dmax and the source node identifier recorded. When the number of source nodes of the verified data frame reaches the preset statutory number Q or the Twait timeout occurs, the corresponding element M(j,h) of the topology degradation matrix M is filled according to the latest candidate maximum degradation value.

6. The link state self-recovery system based on server nodes according to claim 5, characterized in that: The peer-to-peer broadcast thread employs a vector clock-based progressive hash comparison rule, including: Before generating incremental synchronization frames, the peer broadcast thread appends a 32-bit cyclic redundancy check code to the link identifier. After the peer-to-peer broadcast thread uses a vector clock algorithm to write an eight-byte version number for the incremental synchronization frame, it sends it hop-by-hop to all neighboring nodes through a reliable multicast protocol. The broadcast receiving thread rearranges the received incremental synchronization frames in ascending order of version number in the verification buffer, checks the integrity identifier within the frame, and writes the degraded data into the local candidate degradation table after the verification is passed. When the version number of the same link in the candidate degradation table increases consecutively to a preset threshold three times, the matrix construction thread updates the corresponding element of the topology degradation matrix accordingly.

7. The link state self-recovery system based on server nodes according to claim 1, characterized in that: The distributed path calculation module includes: Within each server node, the topology degradation matrix M is converted into a directed graph with remaining capacity; A parallel push-remark algorithm based on vertex partitioning is used to perform minimum cut-maximum flow calculation on the directed graph with remaining capacity to obtain a set of all feasible source-destination paths that satisfy the service bandwidth threshold β; For each feasible path, calculate its recoverable bandwidth value, and write the path number and bandwidth value into the candidate path table in descending order of recoverable bandwidth. When the cumulative recoverable bandwidth of the paths in the candidate path table reaches or exceeds the threshold β for the first time, the current path sequence in the table is locked as the candidate backup forwarding path set R.

8. A link state self-recovery system based on a server node according to claim 7, characterized in that: Calculating the recoverable bandwidth value for each feasible path includes the following steps: Search each edge in the directed graph with remaining capacity segment by segment along the candidate path, extract the edge capacity value and generate an edge capacity sequence; Perform a point-by-point comparison operation on the edge capacity sequence, and determine the minimum edge capacity in the sequence as the bottleneck capacity of the path; Set the service level coefficient γ, and the recoverable bandwidth value is equal to the bottleneck capacity multiplied by the service level coefficient.

9. A link state self-recovery system based on a server node according to claim 1, characterized in that: The rule generation module includes: The priority queue is invoked to search the candidate path table, and the recoverable bandwidth bj of each path is sorted from high to low and output as an ordered sequence. The ordered sequence is read sequentially, and each path is added one by one according to the greedy accumulation algorithm. The process stops when the cumulative recoverable bandwidth first reaches or exceeds the service bandwidth threshold β, thus obtaining a subset of paths that satisfy Σbi≥β and have the smallest number of nodes. Convert the path subset into a list of node identifier-input port-output port triples, and use the rule template compiler to generate the corresponding path remapping rule set C; The path remapping rule set C is distributed to all server nodes involved in the path subset at once, triggering hot replacement of the forwarding table on each node.

10. A link state self-recovery system based on a server node according to claim 9, characterized in that: The step-by-step addition of paths using the greedy cumulative algorithm includes: Initialize the recoverable bandwidth accumulator B to 0 and set the candidate backup forwarding path set R to empty; Pop the first path record rj from the bandwidth sorting priority queue in sequence, add its recoverable bandwidth value bj to the accumulator B using a 64-bit atomic addition instruction, and write it back; If the updated accumulator B is less than the service bandwidth threshold β, then write path rj into the path subset and continue to pop the next record; If the updated accumulator B is greater than or equal to the threshold β, then popping stops and the current path subset is locked.

Images