Cross-border game acceleration stabilization method and device based on real-time network state prediction

Abstract

The invention provides a cross-border game acceleration stabilization method and device based on real-time network state prediction. The method comprises the following steps: periodically sending a detection data packet to at least two candidate proxy nodes; inputting the time sequence data into a pre-trained time sequence prediction model to obtain a predicted packet loss rate in at least one future monitoring period; determining a forward error correction coding parameter group according to the predicted packet loss rate; grouping game data packets to be sent based on the forward error correction coding parameter group; calculating a comprehensive score of each candidate proxy node according to the network state index and the predicted packet loss rate, and selecting a target proxy node with the highest score to establish a data transmission tunnel; at the target agent node, when the number of the received fragments reaches the original fragment number, forward error correction decoding and sequence rearrangement are executed, and a reconstructed game data packet sequence is obtained. According to the method, the link state can be matched in real time, the reliability and the bandwidth are considered, the data flow is continuously kept, the packet loss rate is remarkably reduced, and the delay jitter is inhibited.

Description

Technical Field

[0001] The present application relates to the field of game acceleration technology, and in particular to a cross-border game acceleration stabilization method and device based on real-time network status prediction. Background Art

[0002] With the global popularity of online gaming, Chinese players need to frequently access data centers located overseas. Long-distance, cross-border links typically involve multiple carrier backbone networks, relay nodes, and submarine cables, making them prone to packet loss, latency jitter, and bandwidth fluctuations. To reduce latency and improve connectivity, game accelerators based on UDP tunneling or multipath TCP have emerged. These accelerators essentially deploy relay proxy nodes between users and game servers to forward game data.

[0003] Most existing game accelerators use static or semi-static node selection strategies, supplemented by simple retransmission mechanisms or fixed-parameter forward error correction (FEC) algorithms to offset the impact of packet loss. On the one hand, node selection often relies on passive decisions based on real-time monitoring of indicators such as the current packet loss rate and round-trip latency, lacking the ability to predict evolving network status trends. On the other hand, FEC redundancy ratios are often preset constants or coarse-grained tiers, making them incapable of timely adjustment when network quality rapidly deteriorates or recovers unexpectedly. This results in either insufficient redundancy leading to data loss, or excessive redundancy leading to wasted bandwidth. Furthermore, existing solutions often require disconnecting the old link before establishing a new one during tunnel switching, a process that can easily trigger a game connection reset.

[0004] In summary, existing technologies have the following prominent problems in the process of cross-border game data transmission: First, there is a lack of network status prediction for future time periods, and node scheduling and redundancy configuration lag behind actual network changes; second, forward error correction redundancy is difficult to match with real-time network conditions, making it difficult to simultaneously take into account reliability and bandwidth overhead; third, the tunnel switching process has a slow response and insufficient mechanism for uninterrupted transmission, which may still lead to an increase in packet loss rate during peak periods. Summary of the Invention

[0005] In view of this, the embodiments of the present application provide a cross-border game acceleration and stabilization method and device based on real-time network status prediction to solve the problems of high cross-border game transmission packet loss rate and large delay jitter caused by node selection lag, error correction redundancy rigidity and tunnel switching interruption in the existing technology.

[0006] The first aspect of the embodiment of the present application provides a cross-border game acceleration and stabilization method based on real-time network status prediction, including: using a client accelerator to periodically send a detection data packet to at least two candidate proxy nodes, collecting network status indicators corresponding to each candidate proxy node, and generating time series data based on the network status indicators; inputting the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of the target proxy node in at least one future monitoring cycle; determining a forward error correction coding parameter group based on the predicted packet loss rate, the forward error correction coding parameter group including at least the number of original fragments and the number of redundant fragments; based on the forward error correction coding parameter group The game data packets to be sent are grouped to generate original fragments and corresponding redundant fragments carrying group identifiers and sequence number identifiers; the comprehensive score of each candidate proxy node is calculated based on the network status indicators and the predicted packet loss rate, and the target proxy node with the highest score is selected to establish a data transmission tunnel, and the original fragments and redundant fragments are sent to the target proxy node via the data transmission tunnel; at the target proxy node, when the number of received fragments reaches the number of original fragments, forward error correction decoding and sequence reordering are performed to obtain a reconstructed game data packet sequence, and the game data packet sequence is forwarded to the target game server or target game client to complete the cross-border game data transmission.

[0007] The second aspect of the embodiment of the present application provides a cross-border game acceleration and stabilization device based on real-time network status prediction, including: an acquisition module for using a client accelerator to periodically send detection data packets to at least two candidate proxy nodes, collect network status indicators corresponding to each candidate proxy node, and generate time series data based on the network status indicators; a prediction module for inputting the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of the target proxy node in at least one future monitoring cycle; a determination module for determining a forward error correction coding parameter group based on the predicted packet loss rate, the forward error correction coding parameter group including at least the number of original fragments and the number of redundant fragments; a grouping module for The error correction coding parameter group groups the game data packets to be sent, and generates original fragments and corresponding redundant fragments carrying group identifiers and sequence number identifiers; the calculation module is used to calculate the comprehensive score of each candidate proxy node based on network status indicators and predicted packet loss rate, select the target proxy node with the highest score to establish a data transmission tunnel, and send the original fragments and redundant fragments to the target proxy node via the data transmission tunnel; the reconstruction module is used to perform forward error correction decoding and sequence reordering at the target proxy node when the number of received fragments reaches the original number of fragments, obtain a reconstructed game data packet sequence, and forward the game data packet sequence to the target game server or target game client to complete the cross-border game data transmission.

[0008] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: By utilizing a client accelerator to periodically send probe data packets to at least two candidate proxy nodes, network status indicators corresponding to each candidate proxy node are collected, and time series data is generated based on the network status indicators; the time series data is input into a pre-trained time series prediction model to obtain a predicted packet loss rate of the target proxy node in at least one future monitoring period; a forward error correction coding parameter group is determined based on the predicted packet loss rate, and the forward error correction coding parameter group includes at least the number of original fragments and the number of redundant fragments; the game data packets to be sent are grouped based on the forward error correction coding parameter group to generate original fragments carrying group identifiers and sequence identifiers and corresponding redundant fragments; a comprehensive score of each candidate proxy node is calculated based on the network status indicators and the predicted packet loss rate, and the target proxy node with the highest score is selected to establish a data transmission tunnel, and the original fragments and redundant fragments are sent to the target proxy node via the data transmission tunnel; at the target proxy node, when the number of received fragments reaches the original number of fragments, forward error correction decoding and reordering are performed to obtain a reconstructed game data packet sequence, and the game data packet sequence is forwarded to a target game server or target game client to complete the cross-border game data transmission. This application can adapt to the link status in real time, take into account both reliability and bandwidth, maintain data flow continuously, and significantly reduce packet loss rate and suppress delay jitter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0010] Figure 1 This is a flow chart of a cross-border game acceleration and stabilization method based on real-time network status prediction provided by an embodiment of the present application; Figure 2 This is a structural diagram of a cross-border game acceleration and stabilization device based on real-time network status prediction provided by an embodiment of the present application; Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0011] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0012] Existing game accelerators typically forward domestic users' gaming traffic to overseas servers via UDP tunnels or multipath TCP. Node selection relies on real-time, instantaneous metrics like packet loss rate and latency. Error correction uses fixed or coarse-scale FEC parameters, and tunnel reselection is often a passive, "disconnect-then-reconnect" process. This system struggles to proactively address rapid link deterioration or sudden recovery, resulting in significant packet loss and jitter on highly volatile cross-border links.

[0013] To address the above shortcomings, this application proposes a cross-border game acceleration and stabilization method based on real-time network status prediction. This solution builds a "monitoring-prediction-scheduling-error correction-recovery" closed loop between the client accelerator and the central platform. The main contents include: Periodically send detection data packets to collect indicators such as packet loss rate, round-trip delay, jitter, and bandwidth utilization of candidate proxy nodes and generate time series; Input the time series into a pre-trained time series prediction model (such as a two-layer LSTM) and output the predicted packet loss rate for the future monitoring period; Adaptively determine the number of original fragments k and the number of redundant fragments nk based on the predicted packet loss rate and bandwidth utilization, and dynamically adjust the FEC redundancy; Adopting information entropy adaptive weighting to weight the multi-dimensional indicators of each node and calculate a comprehensive score; when the score difference exceeds the switching threshold, seamless migration is achieved through the pre-built backup tunnel; On the proxy node side, when the number of valid shards reaches k, they are decoded in parallel and reordered to complete data forwarding, and the decoding results are fed back for model correction.

[0014] Through the above technical solution, node switching and redundancy improvement can be completed before the link quality deteriorates, and redundancy can be recovered and bandwidth released in time after the link is restored, achieving continuous, low-packet loss, and low-jitter cross-border game data transmission; at the same time, tunnel seamless switching avoids connection interruption, significantly improving user-side gaming continuity and network resource utilization.

[0015] The contents of the technical solution of this application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] Figure 1 This is a flow chart of a cross-border game acceleration and stabilization method based on real-time network status prediction provided by an embodiment of the present application. Figure 1 As shown, the cross-border game acceleration and stabilization method based on real-time network status prediction may specifically include: S101, using a client accelerator to periodically send a detection data packet to at least two candidate proxy nodes, collect network status indicators corresponding to each candidate proxy node, and generate time series data based on the network status indicators; S102, inputting the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of the target proxy node in at least one future monitoring cycle; S103, determining a forward error correction coding parameter set according to the predicted packet loss rate, where the forward error correction coding parameter set includes at least the number of original fragments and the number of redundant fragments; S104, grouping the game data packets to be sent based on the forward error correction coding parameter group, generating original fragments carrying group identifiers and sequence number identifiers and corresponding redundant fragments; S105, calculating a comprehensive score for each candidate proxy node based on the network status indicator and the predicted packet loss rate, selecting the target proxy node with the highest score to establish a data transmission tunnel, and sending the original fragment and the redundant fragment to the target proxy node via the data transmission tunnel; S106: At the target proxy node, when the number of received fragments reaches the original number of fragments, forward error correction decoding and sequence reordering are performed to obtain a reconstructed game data packet sequence, and the game data packet sequence is forwarded to the target game server or target game client to complete the cross-border game data transmission.

[0017] In some embodiments, collecting network status indicators corresponding to each candidate proxy node and generating time series data based on the network status indicators includes: Periodically send a preset number of probe packets to each candidate proxy node, and record the packet loss rate, round-trip delay, jitter, and available bandwidth as network status indicators based on the response of the probe packets during each monitoring period; Add timestamps and node identifiers corresponding to the monitoring period to the network status indicators to form indicator entries sorted by time; The continuous indicator entries are spliced into time series data for the candidate agent nodes in chronological order and stored in the data buffer for calling the time series prediction model.

[0018] Specifically, the following example uses a client accelerator instance located in Beijing, working in conjunction with three candidate proxy nodes: Tokyo-1, Seattle-2, and LA-3. It details the entire process of collecting network status indicators and generating time series data. Those skilled in the art should understand that this example is merely illustrative of the technical implementation and does not limit the scope of protection of this application.

[0019] After the client accelerator starts, the monitoring unit first reads the local configuration file and determines the monitoring period to be 100ms and the number of probe packets to be 100. Then, at the beginning of each monitoring period, the monitoring unit sends 100 fixed-length UDP probe packets to each of the three candidate proxy nodes via parallel non-blocking sockets. The probe packets carry a 16-byte probe sequence number and a 4-byte send timestamp to facilitate reply message backtracking.

[0020] When the probe packet response comes back, the monitoring unit compares the response order according to the probe sequence number and records the "successful", "timeout" or "lost" status. For each candidate proxy node, the monitoring unit completes the following calculations before the end of the current monitoring cycle: first, the success rate is obtained by dividing the number of successful probe entries by the total number of sent entries, and then the packet loss rate is obtained by subtracting the success rate from 1; secondly, the round-trip delay is obtained by averaging the time difference between sending and receiving all successful probe entries; then the jitter is obtained by dividing the absolute value of the difference between the maximum and minimum round-trip delays by the average delay; finally, the available bandwidth is estimated by combining the payload size of the probe packet and the total effective time in the receiving window. The monitoring unit packages the above four indicators into a single network status indicator in sequence, and appends the start timestamp of the current monitoring cycle and the candidate proxy node identifier at the end.

[0021] To ensure orderly writing of metric entries across threads, the monitoring unit uses an atomically incremented ring buffer index and appends a 32-bit incrementing sequence number to each metric entry before writing. Once written, the metric entry is immediately placed in the lock-free queue. Upon completion of the write operation, an asynchronous callback is triggered, and the data aggregation subthread performs a two-way merge sort on the newly written entries based on their timestamps, ensuring the correct overall timing of metric entries across different nodes in the same cycle.

[0022] The data aggregation subthread then concatenates the consecutive metric entries belonging to the same candidate agent node in chronological order based on the sorting results into a time series data set and appends it to the time series buffer corresponding to that node. To reduce memory jitter, the time series buffer uses a fixed segmentation and page alignment structure. Batch persistence is triggered every time the length threshold is reached. The full segment sequence data is exposed to the prediction service process's read interface via zero-copy shared memory.

[0023] After running for twenty monitoring cycles, for example, the candidate proxy node "Tokyo-1" will have twenty metric entries stored in its time series buffer. These entries include packet loss rate, round-trip latency, jitter, available bandwidth, timestamp, and node ID. The prediction service process can directly read this time series data from shared memory and generate prediction input tensors for future monitoring cycles.

[0024] Through the above-mentioned embodiments, the present application completes the efficient collection and standardized time series processing of multi-node network status indicators at the millisecond-level monitoring granularity, providing a real-time and structured data input basis for the time series prediction model.

[0025] In some embodiments, inputting the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of a target proxy node in at least one future monitoring period includes: The time series data is segmented according to the preset window length and step size, and normalization, missing value filling and node identifier embedding are performed on each segment to construct a standardized input tensor; The input tensors are sequentially fed into the time series prediction model based on the long short-term memory network to generate a predicted packet loss rate sequence corresponding to the target proxy node; A target predicted packet loss rate covering at least one future monitoring period is extracted from the predicted packet loss rate sequence.

[0026] Specifically, this embodiment aims to use a time series prediction model to estimate the future packet loss rate of candidate proxy nodes. The core links include time series segmentation, data preprocessing, node identifier embedding, input tensor construction, model reasoning and result extraction.

[0027] Time series segmentation involves sliding slices of the network status indicator sequence within a continuous monitoring cycle, using a preset window length W and step size S. The window length determines the historical range covered by a single model input, while the step size determines the temporal overlap of the segments. The resulting indicator subsequences undergo data preprocessing, which includes three steps: normalization, missing value imputation, and node identifier embedding. Normalization utilizes the mean μ and standard deviation σ maintained by the model microservice. A z-score transformation is performed on each of the four indicators: packet loss rate, round-trip delay, jitter, and available bandwidth. Missing value imputation follows the principle of "most recent available value first, mean degradation": if a metric is missing in the current monitoring cycle, it is first imputed using the value from the previous monitoring cycle. If consecutive missing values exceed a threshold, the historical mean μ is used. Node identifier embedding converts character-based node identifiers into dense vectors of fixed dimension d_e using a hash map and concatenates them into the tensor feature dimension to provide node-specific information.

[0028] After completing the above processing, a standardized input tensor of dimension (W, d_f + d_e) is constructed for each indicator subsequence, where d_f is the dimension of the four indicators. This input tensor is fed into a two-layer long short-term memory (LSTM) network that has been pre-trained offline. The number of hidden units h and the output step size H of the model are determined before deployment based on system requirements and hardware capabilities. Model inference generates a sequence of predicted packet loss rates p_t+1…p_t+H. From this sequence, a target predicted packet loss rate p_t+1 covering at least one future monitoring cycle is extracted, which serves as the basis for subsequent redundancy configuration and node scoring.

[0029] The following describes the implementation process in more detail using a specific scenario. Assume that the client accelerator has accumulated the most recent twenty network status indicators in the Tokyo-1 node buffer and set the parameters W=12, S=3, d_e=8, h=64, and H=3. The system then executes the following steps: In the first step, based on the window length W and step size S, three indicator subsequences are generated, starting at the current time t: Segment1 = [t-11…t], Segment2 = [t-8…t-3], and Segment3 = [t-5…t-!]. In the second step, the four indicators in each indicator subsequence are normalized using the locally cached mean μ and standard deviation σ. If the available bandwidth measurement at time t-8 in Segment1 is missing, the value of the same indicator at time t-9 is first searched to fill it in. If it is still missing, it is replaced with the historical mean μ. In the third step, the index of the node identifier "Tokyo-1" in the hash map is retrieved to obtain an 8-dimensional embedding vector E_tokyo. This is then concatenated with the normalized indicators in the feature dimension to construct a 12×12 input tensor T_tokyo. In the fourth step, T_tokyo is loaded into the GPU memory and LSTM inference is performed with a batch size of 1. The inference output is Sequence = [p_t+1, p_t+2, p_t+3]. Step 5: Select the first item in the Sequence, p_t+1, as the target predicted packet loss rate, write it to the shared cache, and append the timestamp t.

[0030] Through the method of the above embodiment, the system completes the prediction of the future packet loss trend of the candidate proxy node at the millisecond level, providing a real-time basis for subsequent adaptive forward error correction and seamless tunnel switching, and ensuring that the cross-border game acceleration link takes optimal adjustment measures before network fluctuations.

[0031] In some embodiments, determining a forward error correction coding parameter set based on a predicted packet loss rate includes: Read the predicted packet loss rate corresponding to the target proxy node, and retrieve the basic original shard number and basic redundant shard number that match the predicted packet loss rate from the preset multi-threshold mapping table; Based on the bandwidth utilization of the target proxy node in the current monitoring period, the bandwidth correction coefficient is calculated, and the number of basic original shards and the number of basic redundant shards are incrementally adjusted according to the bandwidth correction coefficient to obtain the corrected number of original shards and the corrected number of redundant shards; The corrected number of original fragments and the corrected number of redundant fragments are combined to form a forward error correction coding parameter group, and written into the coding control table.

[0032] Specifically, this embodiment focuses on the process of "determining the forward error correction coding parameter group according to the predicted packet loss rate". First, the key technical features and their lower-level implementation methods are systematically elaborated, and then the parameter generation process is illustrated with specific numerical scenarios.

[0033] Multi-threshold mapping table: The multi-threshold mapping table is stored in the read-only shared memory area of the client accelerator. The entries are arranged in ascending order of the upper bound of the packet loss rate. Each entry contains three items: the upper bound of the interval, the basic original shard quantity k_base, and the basic redundant shard quantity r_base. When the system starts, the default mapping relationship {1% → 0 / 0, 30% → 4 / 4, 100% → 20 / 20} is loaded from the configuration file; during operation, if the central control platform pushes an update, the monitoring unit completes the hot replacement through an atomic pointer switch to avoid lock blocking.

[0034] Reading the predicted packet loss rate: At the end of each monitoring period, the node scheduling unit pulls the predicted packet loss rate p̂ of the target proxy node from the Redis-like cache through a fixed key name. The cached value is a sixteen-bit unsigned fixed-point number with a quantization accuracy of 0.01%. If the pull fails, it falls back to the predicted value of the previous period.

[0035] Monitoring the bandwidth utilization rate: The available bandwidth B_avail is deduced from the aforementioned probe packets, and the sending rate B_send is obtained by accumulating the data link layer counters. Both are updated at a 100ms period. The bandwidth utilization rate B_util = B_send ÷ B_avail, and the result is rounded to two decimal places. To suppress instantaneous spikes, a moving average is introduced, and the average of the last three periods is calculated and then used in the calculation of the correction coefficient.

[0036] Calculating the bandwidth correction coefficient: The exponential decay function C_bw = exp(-α·B_util) is adopted, where α is the sensitivity coefficient, with a default value of 1.2. The value range of C_bw is (0, 1]. When the link is saturated, it approaches 0, and when the link is idle, it approaches 1. To prevent excessive redundancy increase, the system sets a lower limit of 0.2 for C_bw.

[0037] Fine-tuning the redundant increment: The corrected values k_corr and r_corr are obtained by rounding k_base and r_base after weighting by C_bw. If k_corr < k_base + 1, it is forced to be incremented by 1 to ensure effective error correction; if k_corr > k_base + 8, it is truncated to avoid excessive expansion. The same is done for r_corr. Finally, it is ensured that k_corr and r_corr always increase in pairs.

[0038] Writing to the Encoding Control Table: The Encoding Control Table is located in a ring buffer in process shared memory. Each record structure contains a group identifier (gid), k_corr, r_corr, and expiration_time. The redundant control unit is written using a lockless ring pointer, and the FEC encoder is queried using the gid index. The expiration time is set to two monitoring cycles, and the table is automatically invalidated and recycled when the gid rolls over or the parameters are refreshed.

[0039] For example, in a specific scenario example, the client accelerator performs the following steps on the target proxy node "Seattle-2" in the t0 period: Step 1: Read p=25.7% from the cache, look up the mapping table and locate it in the interval 1%-30%, and get k_base=4, r_base=4.

[0040] Step 2: The monitoring module records B_send = 95 Mbps, the detection module measures B_avail = 150 Mbps, and calculates B_util = 0.63. After a three-cycle sliding average, B_util_avg = 0.60.

[0041] Step 3: Substitute α = 1.2 to calculate C_bw = exp(-1.2 × 0.60) = exp(-0.72) ≈ 0.486. Since the high bandwidth utilization reaches the lower limit, take C_bw = 0.486.

[0042] Step 4. Perform incremental fine-tuning, k_corr = round(k_base + C_bw) = round(4 + 0.486) = 5, r_corr = round(r_base + C_bw) = 5; both values are legal after comparison with the threshold range.

[0043] Step 5: Generate a new group ID gid = t0 timestamp and compress it with CRC8, construct a record {gid, k_corr = 5, r_corr = 5, expire_time = t0 + 200ms} and write it into the encoding control table.

[0044] Step 6: When the FEC encoder starts processing the game data packet to be sent in cycle t0+1, it first reads (k_corr, r_corr) = 5 / 5 corresponding to gid and performs RaptorQ encoding on each group of ten packets (5 original + 5 redundant) until the next round of parameter refresh.

[0045] Through the above detailed implementation, the system completes prediction-driven fine-grained redundancy adjustment at the millisecond level, so that forward error correction will not cause additional congestion when bandwidth is tight, and can also provide sufficient fault tolerance before the link deteriorates, ensuring stable and reliable cross-border game transmission.

[0046] In some embodiments, the game data packets to be transmitted are grouped based on the forward error correction coding parameter group, and original fragments carrying group identifiers and sequence number identifiers and corresponding redundant fragments are generated, including: According to the maximum transmission unit length of the current data transmission tunnel, the game data packet is byte-aligned and split into a number of original fragments that meet the corrected number of original fragments; All original fragments generated within the same monitoring period are assigned a group identifier based on a combination of a timestamp and an increasing random number, and consecutive serial numbers are written to each original fragment in sequence; After determining the corrected number of redundant slices, the polynomial matrix encoding module is called to perform systematic forward error correction encoding on the original slices using a cyclic shift generator polynomial to obtain redundant slices that correspond one-to-one to the original slices, and write a group identifier consistent with the corresponding original slice and an independently incremented serial number identifier into the redundant slice header.

[0047] Specifically, this embodiment will explain how to group game data packets to be sent and perform systematic forward error correction encoding on the client accelerator side based on a determined forward error correction coding parameter group. The core technical features include "MTU alignment and segmentation", "group identifier and sequence number identifier generation", and "cyclic shift generator polynomial encoding".

[0048] MTU alignment and segmentation: The current data transmission tunnel is carried by the QUIC protocol, and the maximum transmission unit length is 1200 bytes. In order to ensure that each fragment is not fragmented again at the link layer, the client accelerator first reads the game data packet length L_pkt and compares it with the MTU: if L_pkt ≤ MTU and the remaining group capacity is sufficient, it is directly placed in the current original fragment list; if L_pkt> MTU or the current group capacity is insufficient, byte alignment and segmentation are performed. A fixed-length fragment strategy is used for segmentation, and the length of each segment is L_seg = MTU - fixed header length. When the last segment is less than L_seg, zero padding alignment is used to ensure consistent fragment length and simplify the size of the subsequent FEC matrix.

[0049] Group and sequence number generation: Within the monitoring period t, the redundant control unit pregenerates a 16-bit group identifier (gid). The gid consists of two parts: the upper ten bits are the millisecond timestamp of the period start, compressed by CRC10, and the lower six bits are a random seed incremented by a linear congruential algorithm. The gid is incremented by one when a new group is created, and the random seed is reset during wraparound to prevent conflicts. A continuous sequence number, seq_id, is used for fragments within a group. It starts at 0 and is incremented by both the original fragment and the redundant fragment to ensure uniqueness during reordering.

[0050] Circular shift generator polynomial encoding: The polynomial matrix encoding module implements systematic forward error correction using the generator polynomial g(x)=x^m+αx^(m-1)+…+β, where α and β are constants in the Galois field GF(256). The module first constructs a k×k identity matrix I and horizontally concatenates it with the (k×(nk)) cyclic shift matrix C to generate a k×n generator matrix G=[I / C]. The encoding process is divided into two stages: matrix multiplication and byte-level domain operations. Matrix multiplication is accelerated using the CPU's advanced vector instruction AVX2, with a single batch latency of no more than 85µs for k=5 and n=10. The first k slices of the systematic encoding output are the original slices themselves, and the last nk slices are redundant slices. The module writes the gid and corresponding seq_id to the header of each redundant slice to maintain a consistent group view with the original slice.

[0051] Transmit Queue Arrangement: After grouping, the transmit scheduler pushes the ten fragments into the transmit ring queue in seq_id order, following a "original first, redundant interleaved" strategy. If multipath concurrency is enabled, fragments with odd seq_ids are assigned to the primary tunnel, while fragments with even seq_ids are assigned to the backup tunnel, achieving path separation.

[0052] For example, in a specific scenario example, assume that the forward error correction parameter group (k_corr=5, r_corr=5) has been determined in this cycle, and the client receives a frame of game status update packet with a length of L_pkt=3580 bytes.

[0053] Step 1: Calculate the number of original shards required (k_req = ceil(3580 ÷ 1200) = 3), which is less than k_corr = 5. Therefore, create a new group with gid = 0x2A3F.

[0054] Step 2: Split the original packet into three segments, P0, P1, and P2, with L_seg = 1200 bytes. P2 is padded to 1200 bytes with zeros. The remaining two original segments are filled with Padding0 and Padding1 as placeholders. The five original segments are written to seq_id 0-4, respectively.

[0055] Step 3: Call the polynomial matrix encoding module to multiply the original slice matrix R (5×1200) by the generator matrix G (5×10) to generate redundant slices E5-E9. The module fills in gid and seq_id5-9 for E5-E9.

[0056] Step 4: The sending scheduler pushes slices P0-E9 into the ring queue according to seq_id. If multi-path concurrency is enabled, the backup path routing flag is set when the slice seq_id is an odd number.

[0057] In step 5, after the fragments arrive at the proxy node, the decoding module detects that the GIDs are consistent and that the valid fragments have reached k_corr = 5. It then performs vectored decoding to recover the original data packets and reorder them. Successful decoding returns a success tag, providing feedback for error correction in the next cycle.

[0058] Through the above embodiments, the system ensures that each fragment does not trigger additional segmentation at the link layer, while achieving consistent identification, continuous sequence numbers and fast systematic encoding of original fragments and redundant fragments, providing robust data recovery capabilities for high packet loss scenarios in cross-border game acceleration links.

[0059] In some embodiments, a comprehensive score of each candidate proxy node is calculated based on the network status indicator and the predicted packet loss rate, and a target proxy node with the highest score is selected to establish a data transmission tunnel, including: Generate a multi-dimensional feature vector for each candidate proxy node, including the current packet loss rate, round-trip delay, jitter, available bandwidth, processing load, and predicted packet loss rate; The multi-dimensional feature vector is normalized and weighted using the weight vector adaptively updated based on information entropy to obtain the corresponding first-moment comprehensive score; Perform sliding window momentum smoothing on the first-moment comprehensive score to obtain the target comprehensive score for node ranking; When the target comprehensive score difference between the candidate proxy node with the highest target comprehensive score and the currently connected proxy node exceeds the preset switching threshold, the backup tunnel management module is called to activate the encrypted data transmission tunnel according to the preconfigured end-to-end key negotiation process, and set the encrypted data transmission tunnel as the new data transmission tunnel.

[0060] Specifically, this embodiment will focus on the technical solution of "calculating the comprehensive score of each candidate proxy node based on network status indicators and predicted packet loss rate and performing tunnel switching". It will first explain the core technical features and key implementation methods in detail, and then explain the complete operation process in combination with actual numerical scenarios.

[0061] Multidimensional feature vector construction: At the end of each monitoring cycle, the client accelerator obtains the current packet loss rate p_now, round-trip delay (RTT), jitter (J), available bandwidth (B_avail), processing load (C_load), and predicted packet loss rate (p_next) for each candidate proxy node. These six metrics are concatenated in a fixed order to form a feature vector F = [p_now, RTT, J, B_avail, C_load, p_next]. To avoid weight bias caused by dimensional differences, the system performs z-score normalization on F. The required μ and σ are updated and distributed in real time by the central platform through incremental learning.

[0062] Entropy adaptive weighting: For each metric in the node set N, the system calculates the distribution probability p_i(k) of each dimension over the most recent T monitoring cycles. Based on this probability, the information entropy H_k for that metric is calculated as -∑_i p_i(k)ln p_i(k). Higher entropy values increase metric dispersion and reduce discrimination. The weight vector W is determined by applying the inverse of entropy to a soft threshold: w_k=(1 / H_k)^γ. After normalization, it satisfies ∑w_k=1. The exponent γ controls entropy sensitivity, with the default value being 0.6. This weight vector is recalculated every ten monitoring cycles to ensure dynamic convergence of the scoring model with link fluctuations.

[0063] Comprehensive score calculation: The normalized feature vector F_norm is dot-producted with the weight vector W along its dimension, yielding the first-time comprehensive score S_raw. To smooth instantaneous spikes, the system applies a sliding window momentum smoothing to S_raw: S_smooth(t) = β·S_smooth(t-1)+(1-β)·S_raw(t), where β is 0.3 and the window length is three monitoring periods. This smoothed value becomes the target comprehensive score S_final, used for node ranking.

[0064] Tunnel switching decision: If the difference ΔS between the highest-scoring node S_final(max) and the currently active node S_final(curr) ≥ threshold δ, a switch is triggered. Threshold δ can be set to 0.15. Once triggered, the backup tunnel management module extracts the tunnel bound to the highest-scoring node from the pre-pooled idle UDP-QUIC tunnels and initiates TLS1.3-PSK pre-shared key negotiation. Upon completion, the tunnel enters the "Ready" state. The routing table is then hot-updated, with the new tunnel ID written to the forwarding table. The old tunnel enters the "Draining" state and closes after one RTT.

[0065] For example, in a specific scenario, assume that in the current monitoring period t0, there are three candidate proxy nodes: Tokyo-1, Seattle-2, and LA-3. The currently active node is Seattle-2. The system collects the following indicators: Tokyo-1: p_now=1.2%, RTT=145ms, J=18ms, B_avail=190Mbps, C_load=42%, p_next=1.5%; Seattle-2: p_now=4.8%, RTT=170ms, J=23ms, B_avail=150Mbps, C_load=55%, p_next=5.4%; LA-3: p_now=3.1%, RTT=180ms, J=27ms, B_avail=160Mbps, C_load=48%, p_next=3.6%.

[0066] In step 1, the system uses the indicators of the last twenty periods as samples, calculates the six-dimensional information entropy, and obtains {H1…H6}. Then, using γ=0.6, it obtains the weight vector W≈{0.18, 0.16, 0.14, 0.20, 0.12, 0.20}.

[0067] Step 2: Perform z-score normalization on the six-dimensional indicators of the three nodes according to μ and σ to obtain F_norm(Tokyo-1), F_norm(Seattle-2), and F_norm(LA-3).

[0068] Step 3: Dot-product the three F_norm values with W, yielding S_raw(Tokyo-1) = 0.82, S_raw(Seattle-2) = 0.57, and S_raw(LA-3) = 0.66. These three values are written into the sliding window and combined with the smoothed values from the previous two periods to yield S_final(Tokyo-1) = 0.79, S_final(Seattle-2) = 0.60, and S_final(LA-3) = 0.64.

[0069] In step 4, ΔS = S_final(Tokyo-1) - S_final(Seattle-2) = 0.19 > δ = 0.15, satisfying the switchover condition. The backup tunnel management module immediately invokes the tunnel context associated with Tokyo-1, triggering TLS 1.3-PSK negotiation; the negotiation completes in 17ms. The routing table completes the redirection before the next batch of packets arrives after the negotiation. The new tunnel is set as the primary tunnel, and the old Seattle-2 tunnel enters the draining phase and closes after 200ms.

[0070] Through the above-mentioned implementation, the system derives entropy adaptive weights based on multi-dimensional real-time metrics and predicted values, calculates comprehensive scores in milliseconds, and employs momentum smoothing to mitigate jitter. When the difference in scores between old and new nodes is significant, the system seamlessly switches to the optimal node, maintaining low packet loss and latency for cross-border gaming links.

[0071] In some embodiments, when the number of received fragments reaches the original number of fragments, forward error correction decoding and sequence reordering are performed to obtain a reconstructed game data packet sequence, including: Write the original fragment and the redundant fragment with the same group ID into the corresponding group buffer, and create an index table in the group buffer according to the sequence ID; When it is detected that the number of valid shards in the group buffer reaches the number of original shards, the parallel matrix inversion decoding module is called to perform vectorized forward error correction decoding on the valid shards based on the forward error correction coding parameter group, generating a decoded shard sequence that matches the number of original shards; The decoded shard sequence is reordered sequentially according to the sequence number identifier, merged into a reconstructed game data packet sequence, and the reconstructed game data packet sequence is written into the forwarding queue for subsequent data forwarding.

[0072] Specifically, in this embodiment, for the process of "performing forward error correction decoding and sequential rearrangement when the number of received shards reaches the number of original shards" on the proxy node side, the key technical features and their lower-level implementation methods will be described first, and then the decoding operation will be elaborated in combination with a specific scenario.

[0073] Group buffer and index table: The proxy node manages shard data using a circular buffer pool in the user state. The buffer pool is divided into slots according to the group identifier gid, and each slot corresponds to a continuous shared memory segment with a capacity of n×L_seg bytes. After a shard arrives, it locates the slot according to the gid, writes the data, and registers the <seq_id, address> key-value pair in the hash index table local to the slot. The index table uses open-addressing hashing to avoid linked list fragmentation, with a load factor upper limit of 0.7, and writing is closed after the segment is filled.

[0074] Valid shard counting and threshold detection: Each slot maintains an atomic counter cnt_valid. After a shard is written and the hash table registration is successful, an atomic increment is performed. If cnt_valid = k_corr triggers a soft interrupt callback, the gid is added to the "pending decoding linked list". The linked list is implemented as a lock-free queue, and the CPU core can poll the linked list to obtain the decoding task.

[0075] Parallel matrix inversion decoding module: The decoding module collaborates on a dual path of multi-core CPU and GPU. The CPU side is responsible for copying the k_corr valid shards into the page-aligned input matrix M(k_corr×L_seg) in ascending order of seq_id, and retrieving the generator matrix G(k_corr×n_corr) from the coding control table. The GPU side uses CUDA cores to perform parallel matrix inversion operations: first, perform Gaussian elimination on G in the GF(256) field to generate the inverse matrix G_inv, and then multiply the redundant part of M by G_inv to obtain the missing shards. To prevent GPU resource starvation, the module adopts a batch aggregation strategy and submits batches when the length of the pending decoding linked list is ≥8.

[0076] Reordering and Forwarding: The decoded fragments output by the GPU match the original fragment length. The CPU writes k_corr fragments and the newly generated (n_corr - k_corr) fragments into a linear array according to seq_id and performs a memcpy operation to merge them into a complete game data packet. The group buffer and index table are reset and returned to the buffer pool. The packet header is reconstructed, with the gid and full length, and the forwarding thread writes it to the DPDK zero-copy forwarding queue.

[0077] For example, in a specific scenario example, assuming the current FEC parameter group (k_corr=5, n_corr=10), the proxy node "Tokyo-1" receives the following fragment sequence at time t0: gid=0x2A3F, seq_id0, 2, 3, 5, 8, a total of 5 fragments, and the remaining seq_id1, 4, 6, 7, 9 are lost.

[0078] Step 1: Five pieces are written into the slot buffer with gid = 0x2A3F and registered in the index table. The callback is triggered when cnt_valid accumulates to 5.

[0079] Step 2: The CPU thread copies seq_id0, 2, 3, 5, and 8 into the input matrix M and reads the G matrix in the control table.

[0080] In step 3, even though the batch length is less than 8, a single task is still submitted. The GPU performs GF(256) Gaussian elimination to find G_inv and reconstruct the missing fragments seq_id 1, 4, 6, 7, and 9. The GPU core takes 57µs.

[0081] Step 4: The CPU retrieves the ten outputs, concatenates them into a continuous byte stream in ascending seq_id order, and writes them into the forwarding queue using memcpy.

[0082] Step 5: The forwarding thread detects the quintuple whose destination address is the target game server, performs NAT rewriting, and then sends it. The slot and index tables are cleared, cnt_valid is reset to zero, and the gid slot is reclaimed.

[0083] Through the above embodiment, the proxy node can immediately trigger parallel error correction decoding when receiving enough original fragments, quickly recover lost fragments and maintain sequential consistency, thereby ensuring that game data can still be delivered to the terminal intactly and accurately under high packet loss links.

[0084] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0085] Figure 2 This is a schematic diagram of the structure of a cross-border game acceleration and stabilization device based on real-time network status prediction provided by an embodiment of the present application. Figure 2As shown, the cross-border game acceleration and stabilization device based on real-time network status prediction includes: The collection module 201 is used to use the client accelerator to periodically send detection data packets to at least two candidate proxy nodes, collect network status indicators corresponding to each candidate proxy node, and generate time series data based on the network status indicators; Prediction module 202, configured to input the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of the target proxy node within at least one future monitoring period; A determination module 203 is configured to determine a forward error correction coding parameter group according to the predicted packet loss rate, where the forward error correction coding parameter group includes at least the number of original fragments and the number of redundant fragments; A grouping module 204 is configured to group the game data packets to be sent based on the forward error correction coding parameter group, and generate original fragments carrying group identifiers and sequence number identifiers and corresponding redundant fragments; The calculation module 205 is used to calculate the comprehensive score of each candidate proxy node based on the network status indicator and the predicted packet loss rate, select the target proxy node with the highest score to establish a data transmission tunnel, and send the original fragment and the redundant fragment to the target proxy node via the data transmission tunnel; The reconstruction module 206 is used to perform forward error correction decoding and sequence reordering at the target proxy node when the number of received fragments reaches the original number of fragments, obtain a reconstructed game data packet sequence, and forward the game data packet sequence to the target game server or target game client to complete the cross-border game data transmission.

[0086] In some embodiments, Figure 2 The acquisition module 201 periodically sends a preset number of probe data packets to each candidate proxy node, and records the packet loss rate, round-trip delay, jitter and available bandwidth as network status indicators based on the response status of the probe data packets during each monitoring period; adds a timestamp and node identifier corresponding to the monitoring period to the network status indicators to form indicator entries sorted by time; splices continuous indicator entries into time series data for candidate proxy nodes in chronological order, and stores them in a data buffer for calling the time series prediction model.

[0087] In some embodiments, Figure 2 The prediction module 202 segments the time series data according to the preset window length and step size, and performs normalization, missing value completion and node identifier embedding processing on each segment to construct a standardized input tensor; the input tensor is sequentially input into the time series prediction model based on the long short-term memory network to generate a predicted packet loss rate sequence corresponding to the target proxy node; and the target predicted packet loss rate covering at least one future monitoring period is extracted from the predicted packet loss rate sequence.

[0088] In some embodiments, Figure 2 The determination module 203 reads the predicted packet loss rate corresponding to the target proxy node, and retrieves the basic original fragment number and the basic redundant fragment number that match the predicted packet loss rate from the preset multi-threshold mapping table; calculates the bandwidth correction coefficient based on the bandwidth utilization of the target proxy node in the current monitoring period, and performs incremental fine-tuning on the basic original fragment number and the basic redundant fragment number according to the bandwidth correction coefficient to obtain the corrected original fragment number and the corrected redundant fragment number; combines the corrected original fragment number and the corrected redundant fragment number to form a forward error correction coding parameter group, and writes the group into the coding control table.

[0089] In some embodiments, Figure 2 The grouping module 204 performs byte-aligned segmentation on the game data packet according to the maximum transmission unit length of the current data transmission tunnel to obtain a number of original fragments that meet the revised number of original fragments; assigns a group identifier generated based on a combination of a timestamp and an increasing random number to all original fragments generated in the same monitoring cycle, and writes a continuous serial number identifier to each original fragment in sequence; after determining the revised number of redundant fragments, calls the polynomial matrix encoding module, uses a cyclic shift generator polynomial to perform systematic forward error correction encoding on the original fragments, obtains redundant fragments that correspond one-to-one to the original fragments, and writes a group identifier consistent with the corresponding original fragment and an independently increasing serial number identifier in the redundant fragment header.

[0090] In some embodiments, Figure 2 The calculation module 205 generates a multi-dimensional feature vector for each candidate proxy node, which includes the current packet loss rate, round-trip delay, jitter, available bandwidth, processing load and predicted packet loss rate; uses a weight vector based on information entropy adaptive update to perform normalized weighted processing on the multi-dimensional feature vector to obtain the corresponding first-moment comprehensive score; performs sliding window momentum smoothing on the first-moment comprehensive score to obtain a target comprehensive score for node sorting; when the difference between the target comprehensive score of the candidate proxy node with the highest target comprehensive score and the target comprehensive score of the currently connected proxy node exceeds a preset switching threshold, the backup tunnel management module is called to activate the encrypted data transmission tunnel according to the pre-configured end-to-end key negotiation process, and set the encrypted data transmission tunnel to be the new data transmission tunnel.

[0091] In some embodiments, Figure 2The reconstruction module 206 writes the original slices and redundant slices carrying the same group identifier into the corresponding group buffer, and establishes an index table in the group buffer according to the serial number identifier; when it is detected that the number of valid slices in the group buffer reaches the number of original slices, the parallel matrix inversion decoding module is called to perform vectorized forward error correction decoding on the valid slices based on the forward error correction coding parameter group to generate a decoded slice sequence that matches the number of original slices; the decoded slice sequence is rearranged in order according to the serial number identifier, merged into a reconstructed game data packet sequence, and the reconstructed game data packet sequence is written into a forwarding queue for subsequent data forwarding.

[0092] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0093] Figure 3 Schematic diagram of the structure of the electronic device 3 provided in the embodiment of the present application. Figure 3 As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, the steps of the above-mentioned method embodiments are implemented. Alternatively, when the processor 301 executes the computer program 303, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0094] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to implement the present application. One or more modules / units may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of computer program 303 in electronic device 3.

[0095] The electronic device 3 may be a desktop computer, a notebook, a PDA, a cloud server or other electronic device. The electronic device 3 may include but is not limited to a processor 301 and a memory 302. Those skilled in the art will understand that Figure 3 It is only an example of electronic device 3 and does not constitute a limitation of electronic device 3. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0096] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0097] Memory 302 can be an internal storage unit of electronic device 3, such as a hard drive or memory of electronic device 3. Memory 302 can also be an external storage device of electronic device 3, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. Furthermore, memory 302 can include both an internal storage unit of electronic device 3 and an external storage device. Memory 302 is used to store computer programs and other programs and data required by the electronic device. Memory 302 can also be used to temporarily store data that has been output or is about to be output.

[0098] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0099] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0100] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0101] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer equipment and methods can be implemented in other ways. For example, the apparatus / computer equipment embodiments described above are merely schematic. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of the apparatus or unit, which may be electrical, mechanical or other forms.

[0102] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0103] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0104] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the processes in the above-mentioned embodiment method by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of each of the above-mentioned method embodiments. The computer program may include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. Computer-readable media may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium.

[0105] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the technical solutions of the present application are described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A cross-border game acceleration and stabilization method based on real-time network status prediction, characterized in that: include: Using a client accelerator to periodically send a probe data packet to at least two candidate proxy nodes, collect a network status indicator corresponding to each candidate proxy node, and generate time series data based on the network status indicator; Inputting the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of the target proxy node in at least one future monitoring period; Determining a forward error correction coding parameter group according to the predicted packet loss rate, wherein the forward error correction coding parameter group includes at least the number of original fragments and the number of redundant fragments; Grouping the game data packets to be sent based on the forward error correction coding parameter group, generating original fragments carrying group identifiers and sequence number identifiers and corresponding redundant fragments; Calculating a comprehensive score for each candidate proxy node based on the network status indicator and the predicted packet loss rate, selecting a target proxy node with the highest score to establish a data transmission tunnel, and sending the original fragment and the redundant fragment to the target proxy node via the data transmission tunnel; At the target proxy node, when the number of received fragments reaches the original number of fragments, forward error correction decoding and sequence reordering are performed to obtain a reconstructed game data packet sequence, and the game data packet sequence is forwarded to the target game server or target game client to complete the cross-border game data transmission.

2. The method according to claim 1, characterized in that The collecting of network status indicators corresponding to each candidate proxy node and generating time series data according to the network status indicators includes: Periodically send a preset number of probe packets to each candidate proxy node, and record the packet loss rate, round-trip delay, jitter, and available bandwidth as network status indicators based on the response of the probe packets during each monitoring period; Adding a timestamp and a node identifier corresponding to a monitoring period to the network status indicator to form an indicator entry sorted by time; The continuous indicator entries are spliced into time series data for the candidate agent node in chronological order, and stored in a data buffer for calling the time series prediction model.

3. The method according to claim 1, characterized in that Inputting the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of a target proxy node in at least one future monitoring period includes: The time series data is segmented according to a preset window length and step size, and normalization, missing value filling and node identifier embedding are performed on each segment to construct a standardized input tensor; The input tensors are sequentially input into a time series prediction model based on a long short-term memory network to generate a predicted packet loss rate sequence corresponding to the target proxy node; A target predicted packet loss rate covering at least one future monitoring period is extracted from the predicted packet loss rate sequence.

4. The method according to claim 1, wherein The determining of a forward error correction coding parameter group according to the predicted packet loss rate includes: Read the predicted packet loss rate corresponding to the target proxy node, and retrieve the basic original shard number and the basic redundant shard number that match the predicted packet loss rate from a preset multi-threshold mapping table; Calculating a bandwidth correction coefficient based on the bandwidth utilization of the target proxy node in the current monitoring period, and incrementally fine-tuning the basic number of original shards and the basic number of redundant shards according to the bandwidth correction coefficient to obtain a corrected number of original shards and a corrected number of redundant shards; The corrected number of original fragments and the corrected number of redundant fragments are combined to form a forward error correction coding parameter group, and written into a coding control table.

5. The method according to claim 4, characterized in that The step of grouping the game data packets to be sent based on the forward error correction coding parameter group and generating original fragments carrying group identifiers and sequence number identifiers and corresponding redundant fragments includes: Performing byte-aligned segmentation on the game data packet according to the maximum transmission unit length of the current data transmission tunnel to obtain a number of original segments that meet the revised number of original segments; All original fragments generated within the same monitoring period are assigned a group identifier based on a combination of a timestamp and an increasing random number, and consecutive serial numbers are written to each original fragment in sequence; After determining the corrected number of redundant slices, a polynomial matrix encoding module is called to perform systematic forward error correction encoding on the original slices using a cyclic shift generator polynomial to obtain redundant slices that correspond one-to-one to the original slices, and a group identifier and an independently incremented serial number identifier that are consistent with the corresponding original slice are written into the header of the redundant slice.

6. The method according to claim 1, characterized in that The step of calculating a comprehensive score of each candidate proxy node according to the network status indicator and the predicted packet loss rate, and selecting the target proxy node with the highest score to establish a data transmission tunnel, includes: Generate a multi-dimensional feature vector for each candidate proxy node, including the current packet loss rate, round-trip delay, jitter, available bandwidth, processing load, and the predicted packet loss rate; Performing normalized weighted processing on the multidimensional feature vector using a weight vector adaptively updated based on information entropy to obtain a corresponding first-moment comprehensive score; Performing sliding window momentum smoothing on the comprehensive score at the first moment to obtain a target comprehensive score for node ranking; When the target comprehensive score difference between the candidate proxy node with the highest target comprehensive score and the currently connected proxy node exceeds a preset switching threshold, the standby tunnel management module is called to activate the encrypted data transmission tunnel according to the preconfigured end-to-end key negotiation process, and set the encrypted data transmission tunnel as the new data transmission tunnel.

7. The method according to claim 1, characterized in that When the number of received fragments reaches the number of original fragments, forward error correction decoding and sequence rearrangement are performed to obtain a reconstructed game data packet sequence, including: Write the original fragment and the redundant fragment with the same group ID into the corresponding group buffer, and create an index table in the group buffer according to the sequence ID; When it is detected that the number of valid slices in the group buffer reaches the number of original slices, calling a parallel matrix inversion decoding module to perform vectorized forward error correction decoding on the valid slices based on the forward error correction coding parameter group to generate a decoded slice sequence that matches the number of original slices; The decoded fragment sequences are sequentially rearranged according to the sequence identifiers, merged into a reconstructed game data packet sequence, and the reconstructed game data packet sequence is written into a forwarding queue for subsequent data forwarding.

8. A cross-border game acceleration and stabilization device based on real-time network status prediction, characterized in that: include: a collection module, configured to periodically send detection data packets to at least two candidate proxy nodes using a client accelerator, collect network status indicators corresponding to each candidate proxy node, and generate time series data based on the network status indicators; A prediction module, configured to input the time series data into a pre-trained time series prediction model to obtain a predicted packet loss rate of a target proxy node within at least one future monitoring period; A determination module, configured to determine a forward error correction coding parameter group according to the predicted packet loss rate, wherein the forward error correction coding parameter group includes at least the number of original fragments and the number of redundant fragments; A grouping module, configured to group the game data packets to be sent based on the forward error correction coding parameter group, and generate original fragments carrying group identifiers and sequence number identifiers and corresponding redundant fragments; a calculation module, configured to calculate a comprehensive score of each candidate proxy node based on the network status indicator and the predicted packet loss rate, select a target proxy node with the highest score to establish a data transmission tunnel, and send the original fragment and the redundant fragment to the target proxy node via the data transmission tunnel; A reconstruction module is used to perform forward error correction decoding and sequence reordering at the target proxy node when the number of received fragments reaches the original number of fragments, obtain a reconstructed game data packet sequence, and forward the game data packet sequence to the target game server or target game client to complete the cross-border game data transmission.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images