A Method and Device for Optimizing Packet Loss in Game Accelerators Based on Traffic Priority Management

Abstract

This application provides a method and apparatus for optimizing packet loss in a game accelerator based on traffic priority management. The method includes: performing periodic link probing on at least one proxy node and generating corresponding link monitoring results; determining whether the packet loss rate for two consecutive monitoring periods exceeds a first threshold based on the link monitoring results; classifying the data stream to be sent in real time to obtain priority labels for different traffic categories; inputting the link monitoring results into a prediction algorithm to obtain a network quality prediction value for the next monitoring period, and adaptively adjusting the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value; and sending the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy nodes to achieve accelerated forwarding of game data. This application can improve the reliability, latency stability, and bandwidth utilization of game data transmission in cross-border high-packet-loss network environments.

Description

Technical Field

[0001] This application relates to the field of game acceleration technology, and in particular to a method and apparatus for optimizing packet loss in a game accelerator based on traffic priority management. Background Technology

[0002] With the increasing prevalence of cross-border network infrastructure, more and more domestic gamers are connecting to overseas game servers using accelerator tools. Cross-border links typically involve long transmission distances, multiple relay layers, and inconsistent congestion control strategies, leading to increased round-trip latency, significant jitter, and high packet loss rates. In competitive and massively multiplayer online games where real-time network requirements are extremely high, any momentary packet loss or latency fluctuation can disrupt the smoothness of user operations and game synchronization. Therefore, ensuring highly reliable delivery of game data in unpredictable cross-border network environments has become a key technical challenge for the industry.

[0003] To address these issues, common industry practices include: establishing dedicated proxy channels between the user end and overseas nodes to forward game traffic via TCP or UDP tunnels; enabling automatic reconnection or ARQ-based compensation mechanisms on the client side; configuring static forward error correction (FEC) parameters in proxy nodes to withstand medium to high packet loss scenarios; and manually or periodically switching transmission paths at the application layer. However, these fixed or coarse-grained solutions struggle to balance real-time performance and bandwidth utilization: over-reliance on retransmission introduces additional latency, static redundancy configurations continue to consume bandwidth after network recovery, and simple node switching strategies cannot cope with drastic fluctuations in link conditions. Furthermore, existing technologies typically treat all types of game-related traffic equally, lacking differentiation in the importance of different services such as control streams, voice streams, and video streams, which can easily lead to further loss of critical data during network congestion. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method and apparatus for optimizing packet loss in a game accelerator based on traffic priority management, in order to solve the problem that the existing technology cannot dynamically adjust redundancy compensation according to real-time network quality and implement priority management for different service flows, resulting in insufficient reliability and bandwidth utilization of game data transmission in cross-border high packet loss environments.

[0005] A first aspect of this application provides a method for optimizing packet loss in a game accelerator based on traffic priority management, comprising: performing periodic link probing on at least one proxy node, acquiring packet loss rate, latency, and jitter data for each monitoring period, and generating corresponding link monitoring results; determining whether the packet loss rate for two consecutive monitoring periods exceeds a first threshold based on the link monitoring results, and if so, issuing an enable command to a forward error correction encoder, selecting a corresponding redundancy ratio based on the packet loss rate range, performing forward error correction encoding on the game data packets to be sent, and generating redundant data packets corresponding to the source data packets; classifying the data stream to be sent in real time, obtaining priority labels for different traffic categories, and writing the source data packets and redundant data packets into a header field containing the priority labels; inputting the link monitoring results into a prediction algorithm to obtain a network quality prediction value for the next monitoring period, and adaptively adjusting the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value; and sending the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy nodes to achieve accelerated forwarding of game data.

[0006] A second aspect of this application provides a packet loss optimization device for a game accelerator based on traffic priority management, comprising: a detection module, configured to perform periodic link detection on at least one proxy node, acquire packet loss rate, latency, and jitter data for each monitoring period, and generate corresponding link monitoring results; an error correction module, configured to determine whether the packet loss rate of two consecutive monitoring periods exceeds a first threshold based on the link monitoring results, and if so, issue an enable command to the forward error correction encoder, select a corresponding redundancy ratio according to the packet loss rate range, perform forward error correction encoding on the game data packets to be sent, and generate redundant data packets corresponding to the source data packets; a classification module, configured to classify the data stream to be sent in real time, obtain priority labels for different traffic categories, and write the source data packets and redundant data packets into a header field containing priority labels; an adjustment module, configured to input a prediction algorithm based on the link monitoring results, obtain a network quality prediction value for the next monitoring period, and adaptively adjust the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value; and a sending module, configured to send the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy nodes, so as to achieve accelerated forwarding of game data.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0008] By performing periodic link probing on at least one proxy node, packet loss rate, latency, and jitter data for each monitoring period are obtained, and corresponding link monitoring results are generated. Based on the link monitoring results, it is determined whether the packet loss rate for two consecutive monitoring periods exceeds a first threshold. If it does, an activation command is issued to the forward error correction encoder, and a corresponding redundancy ratio is selected based on the packet loss rate range. Forward error correction encoding is performed on the game data packets to be sent, generating redundant data packets corresponding to the source data packets. The data stream to be sent is classified in real time to obtain priority labels for different traffic categories. The source data packets and redundant data packets are written into a header field containing the priority labels. Based on the link monitoring results, a prediction algorithm is input to obtain the network quality prediction value for the next monitoring period. The redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes are adaptively adjusted according to the network quality prediction value. The sorted source data packets and redundant data packets are sent to the target game server or game client according to the updated proxy nodes to achieve accelerated forwarding of game data. This application can improve the reliability, latency stability, and bandwidth utilization of game data transmission in cross-border high-packet-loss network environments. Attached Figure Description

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

[0010] Figure 1 This is a flowchart illustrating the packet loss optimization method for game accelerators based on traffic priority management provided in this application embodiment;

[0011] Figure 2 This is a schematic diagram of the structure of the game accelerator packet loss optimization device based on traffic priority management provided in the embodiments of this application;

[0012] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] Existing technologies generally establish dedicated tunnels between the client and overseas proxy nodes using accelerators, and employ fixed redundancy FEC, simple ARQ retransmission, or timed node switching to combat high packet loss on cross-border links. However, these methods lack fine-grained monitoring and prediction of link packet loss rate, latency, and jitter, cannot adjust redundancy as needed when network quality fluctuates drastically, and do not differentiate the importance of services such as control flow, voice flow, and video flow. This results in significant potential loss of critical game data and waste of considerable bandwidth during periods of low packet loss.

[0015] Therefore, a technical solution is needed that can dynamically sense network quality, distinguish traffic categories, and adjust compensation strategies in real time to solve the problems of insufficient reliability and low bandwidth utilization in game data transmission under cross-border high packet loss environments.

[0016] Therefore, this application proposes a method and apparatus for optimizing packet loss in game accelerators based on traffic priority management. The technical solution of this application mainly includes the following:

[0017] Periodically send probe packets to the proxy node to obtain packet loss rate, round-trip time and jitter, and generate network quality prediction values ​​for the next period through a prediction algorithm;

[0018] When the predicted or real-time monitored packet loss rate exceeds the set threshold, forward error correction encoding is performed on the game data packets in the data stream to be sent by selecting the redundancy ratio according to the range, and redundant data packets are generated.

[0019] Extract features from each data packet in the data stream to be sent, use a traffic classification model to determine the traffic category and write it into a priority label;

[0020] The scheduling module puts data packets into the corresponding sending queue based on priority labels, and adaptively adjusts the redundancy ratio, queue rate and proxy nodes in combination with token bucket bandwidth constraints and network quality prediction values.

[0021] When the packet loss rate recovers to below the cancellation threshold within multiple consecutive monitoring periods, redundant coding is automatically terminated, while priority and queue configuration are retained to achieve closed-loop control.

[0022] Through the above-described scheme, this application can promptly increase redundancy and prioritize critical service flows during packet loss outbreaks, and quickly reduce redundancy to release bandwidth after network recovery. Simultaneously, by combining node scoring and a fast switching mechanism, it further reduces the exposure time of high-packet-loss links. This significantly improves the reliability and latency stability of game data transmission in cross-border high-packet-loss network environments, and enhances overall bandwidth utilization.

[0023] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0024] Figure 1This is a flowchart illustrating the packet loss optimization method for game accelerators based on traffic priority management provided in this application embodiment. Figure 1 As shown, this method for optimizing packet loss in a game accelerator based on traffic priority management can specifically include:

[0025] S101, Perform periodic link probing on at least one proxy node, obtain packet loss rate, latency and jitter data for each monitoring period, and generate corresponding link monitoring results;

[0026] S102, based on the link monitoring results, determine whether the packet loss rate of two consecutive monitoring periods exceeds the first threshold. If it does, issue an enable command to the forward error correction encoder, select the corresponding redundancy ratio according to the packet loss rate range, perform forward error correction encoding on the game data packet to be sent, and generate a redundant data packet corresponding to the source data packet.

[0027] S103, classify the data stream to be sent in real time, obtain priority labels for different traffic categories, and write the source data packets and redundant data packets into the header field containing the priority labels;

[0028] S104: Based on the link monitoring results, input the prediction algorithm to obtain the network quality prediction value for the next monitoring period, and adaptively adjust the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value.

[0029] S105 sends the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy node, so as to accelerate the forwarding of game data.

[0030] In some embodiments, periodic link probing is performed on at least one proxy node to obtain packet loss rate, latency, and jitter data for each monitoring period, and corresponding link monitoring results are generated, including:

[0031] Within each monitoring period, a sequence of probe packets is sent to the target agent node at a preset probe packet sending rate. Each probe packet in the sequence carries a link identifier, a monitoring period identifier, an incrementing sequence number, and a sending timestamp.

[0032] After receiving the receipt corresponding to the probe packet sequence, the number of probe packets with receipts is compared with the number of probe packets sent based on the incrementing sequence number to calculate the packet loss rate for the current monitoring period.

[0033] The round-trip delay is calculated based on the sending timestamp and the receipt arrival time, and the delay difference of continuous probe packets is statistically analyzed through a sliding window to obtain the delay jitter corresponding to the current monitoring period.

[0034] Packet loss rate, round-trip time, and latency jitter are written into the link monitoring result entries associated with the monitoring period, and the link monitoring result entries are stored in the local monitoring cache and / or reported to the control platform.

[0035] Specifically, in this embodiment, the client is configured with a link detection module, a time synchronization module, and a monitoring result cache. The link detection module is responsible for performing link quality detection on at least one overseas proxy node according to a preset period. This embodiment uses 1 second as a monitoring period, but in actual applications, it can be adjusted to other durations such as 500ms or 2 seconds according to business needs.

[0036] First, at the start of each monitoring period, the link detection module preempts the sending right from the sending scheduling queue according to the detection packet sending rate, continuously generates a sequence of detection packets, and sends them to the target proxy node via the UDP protocol. The length of the detection packet sequence corresponds one-to-one with the sending rate. For example, in a 100pps configuration, one detection packet is generated and sent every 10,000µs until the end of the period. Each detection packet contains the following fields in sequence: link identifier, used to distinguish the current tunnel; monitoring period identifier, used to identify the period sequence number and correspond one-to-one with subsequent result entries; incrementing sequence number, used to determine packet loss; and sending timestamp, provided by a local monotonically increasing timer with granularity accurate to 10µs.

[0037] Secondly, upon receiving a probe packet, the proxy node immediately generates a receipt and returns it via the same path. When the link probe module receives the response, it first parses the link identifier and monitoring period identifier, processing only receipts matching the current period. It then compares the incrementing sequence number, counts the number of probe packets with received receipts, and compares this count with the number of probe packets sent in the current period to calculate the packet loss rate. For example, if 100 probe packets are sent in a period and only 92 receipts are received, the link probe module records the current packet loss rate as 8%.

[0038] Next, the link detection module calculates the round-trip delay based on the difference between the sending timestamp and the arrival time of the acknowledgment. For example, if the sending timestamp of a probe packet is t... s The arrival timestamp is t r Then the round-trip time delay Δt = t r -t s The link probing module uses a sliding window method to statistically analyze the round-trip delay difference of consecutive probe packets within the same period. The window length can be configured from 5 to 10 probe packets. In this embodiment, a window length of 6 probe packets is used, and Δt is calculated. i With Δt i-1 The absolute value of the difference is taken and averaged to obtain the time delay jitter value j.

[0039] Then, the link detection module generates a link monitoring result entry. This entry includes three core indicators: monitoring period identifier, packet loss rate, round-trip time, and latency jitter, as well as a generation timestamp and an optional prediction reference flag. The link monitoring result entry is first written to the local monitoring cache for subsequent prediction algorithm calls; if the client is currently in the active reporting phase, the entry is encapsulated into a Telemetry message when the sending scheduling thread is idle, and reported to the cloud control platform through the control channel.

[0040] It is important to note that, to reduce the impact of probe activities on service traffic, this embodiment lowers the priority of probe packets before adding them to the sending queue: the DSCP tag of the probe packets is set to the lowest priority to ensure that game data packets are sent first. Simultaneously, the time synchronization module performs fast NTP calibration when the client starts up and uses simplified PTP exchange messages every 30 seconds to perform fine-grained correction on the latency measurement benchmark, thereby ensuring the monotonic consistency between the sending and receiving timestamps.

[0041] When the number of accumulated link monitoring result entries in the monitoring result cache reaches the set threshold (12 entries in this embodiment, corresponding to the data in the most recent 12 seconds), the link detection module triggers the prediction algorithm input process, organizes the three-dimensional index sequence in the sliding window into a time series vector, and provides a data basis for network quality prediction in the next monitoring cycle.

[0042] Through the above steps, this embodiment can obtain the packet loss rate, round-trip latency, and latency jitter of cross-border links in real time without affecting the core business flow of the game, and continuously record and report them in an itemized manner, providing reliable data support for subsequent adaptive redundancy control, priority queue bandwidth constraint adjustment, and proxy node switching decisions.

[0043] In some embodiments, forward error correction encoding is performed on the game data packets to be sent to generate redundant data packets corresponding to the source data packets, including:

[0044] Based on the current redundancy ratio, a preset number of source data packets are sequentially collected from the sending buffer to form an error correction group;

[0045] The forward error correction encoder is invoked, and the error correction group is encoded using a preset forward error correction algorithm according to the redundancy ratio and the number of packets in the error correction group, so as to obtain redundant data packets that correspond one-to-one with the source data packets.

[0046] Write the error correction group identifier and incrementing sequence number to the source data packet and the redundant data packet respectively, and retain the existing priority label of the source data packet;

[0047] The source data packet and the corresponding redundant data packet are synchronously output to the sending queue that matches the priority label for subsequent transmission.

[0048] Specifically, in this embodiment, the client incorporates a forward error correction encoder, a transmission buffer, and a multi-level transmission queue. The current redundancy ratio is issued in real time by the link adaptive module and directly determines the number of source data packets within the error correction group during the encoding stage. Taking a moderate packet loss scenario as an example, when the redundancy ratio is set to 1:1, the forward error correction encoder sequentially retrieves four source data packets from the transmission buffer, arranges them in order, and generates an error correction group of length 4. If the link monitoring results indicate an increase in the packet loss rate and adjust the redundancy ratio to 1:1.5, the encoder automatically extends the error correction group length, requiring a total of 20 source data packets to form a new error correction group.

[0049] Once the error correction group is assembled, the forward error correction encoder first reads the redundancy ratio and the number of packets within the group, and then selects the corresponding preset forward error correction algorithm. For configurations with a redundancy ratio not exceeding 1:1, this embodiment uses ReedSolomon encoding. The encoder performs polynomial operations on the error correction group on a byte-by-byte basis, outputting redundant data packets that correspond one-to-one with the source data packets. For configurations with a redundancy ratio higher than 1:1, the encoder enables a concatenated LDPC and ReedSolomon scheme, appending a short ReedSolomon checksum after the LDPC matrix encoding to improve burst packet loss recovery capabilities.

[0050] After encoding, the forward error correction encoder writes a unified error correction group identifier for each source data packet and its corresponding redundant data packet, and assigns an incrementing sequence number to each data packet within the group. The error correction group identifier is 16 bits long, and the incrementing sequence number is 8 bits long. Both, along with the original 20-bit priority label, are placed in the packet header extension field. If the source data packet has already been assigned a priority label during the traffic classification stage, that label is retained, and only the error correction field is added.

[0051] Subsequently, the encoder inserts each source data packet and its corresponding redundant data packet into the transmission queue that matches the priority tag, in the order of "source packet followed by redundant packet". For example, the control flow has the highest priority, and its corresponding transmission queue is configured by the scheduling module to have the highest token generation rate; the video stream has a lower priority, and its corresponding queue has a relatively limited token rate. This ensures that data packets within the same error correction group are relatively aggregated on the network, facilitating timely decoding by proxy nodes, and also ensures that high-priority services are sent first when bandwidth is limited.

[0052] After acquiring sufficient tokens, the sending queue encapsulates the data packets into a UDP tunnel and writes a local timestamp to them, which is then handed over to the network interface module. Upon receiving the packets, the proxy node restores the packet relationships based on the error correction group identifier. When the number of source packets and redundant packets within the group reaches the threshold specified by the encoder, the decoding process is immediately initiated. If the number of missing packets within the group does not exceed the redundancy capacity, the proxy node can restore the complete set of source packets and forward them to the target game server in the original order. If decoding fails or a timeout occurs, the proxy node generates a partial packet loss alarm and sends it back to the client along with the next link monitoring receipt, allowing the link adaptation module to adjust the redundancy ratio in the next cycle.

[0053] To minimize the impact on the main thread, this embodiment runs the forward error correction encoder in a separate, lightweight thread within the client. This thread uses a circular buffer as the source data packet input, sharing data with the send buffer via a lock-free queue to avoid unnecessary delays caused by lock contention. Simultaneously, a double-buffering strategy ensures that source data packet writing and redundant data packet output do not block each other under high load. This guarantees real-time encoding without affecting the normal execution of the game engine and other modules.

[0054] Through the above implementation methods, this embodiment can quickly assemble error correction groups and dynamically adjust the redundancy ratio when the link packet loss increases. After the link recovers, it can promptly reduce the error correction groups and reduce redundancy overhead. Combined with priority queues, it can achieve hierarchical protection for different service flows, and improve the stability of game data transmission and bandwidth utilization in cross-border high packet loss network environments.

[0055] In some embodiments, the data stream to be sent is classified in real time to obtain priority labels for different traffic categories, and the source data packets and redundant data packets are written into a header field containing the priority labels, including:

[0056] Extract the quintuple information of each data packet in the data stream to be sent and the payload segment of a preset length to generate the corresponding traffic feature vector;

[0057] The traffic feature vector is input into the traffic classification module, and the traffic category to which the data packet belongs is determined by the deep packet inspection algorithm or the traffic identification model based on machine learning.

[0058] Based on the pre-stored traffic category priority mapping table, priority labels are matched to the discrimination results;

[0059] Call the packet header write interface to write the priority label into the reserved packet header field, and retain the error correction group identifier and sequence number added during the forward error correction coding process;

[0060] The source data packet after the priority label is written, along with the corresponding redundant data packet, is output to the send queue associated with the priority label.

[0061] Specifically, in this embodiment, the client is configured with a traffic classification module, a packet header writing interface, and a multi-level sending queue corresponding to priority tags. The traffic classification module internally encapsulates a lightweight deep packet inspection model, employing a cascaded structure of convolutional neural networks and temporal convolutional networks, enabling rapid identification of service flows without decrypting the payload. The model input is a fixed-dimensional traffic feature vector, and the output is a predefined traffic category identifier. The priority tags use 6-bit encoding, mapping control flow, game logic flow, voice flow, video flow, and other traffic according to their weights from high to low.

[0062] First, the traffic classification module captures each data packet entering the send buffer from the data stream to be sent. Upon capturing a packet, the module immediately extracts the five-tuple information: source address, destination address, source port, destination port, and transport layer protocol. Simultaneously, it extracts the first 64 bytes of the payload as a payload fragment. These two parts of data are then vectorized and concatenated into a fixed-length traffic feature vector. To ensure efficient parallelism between feature extraction and packet processing, this embodiment uses a zero-copy method to directly map the payload fragment from the circular buffer, eliminating the need for additional memory copying.

[0063] Next, the generated traffic feature vectors are fed into the neural network within the traffic classification module. The model first uses multi-scale convolutional kernels to extract spatial features, then uses a temporal convolutional network to mine local temporal dependencies, and finally outputs a set of class confidence values ​​at the fully connected layer. The module uses the maximum confidence principle to classify data packets into specific traffic categories, for example, classifying the game logic flow as category ID=1. If the model's confidence level is lower than a threshold, the module triggers a fast rollback process, calling an emergency rule based on the port number to supplement the classification result, avoiding queuing disorder caused by classification failure.

[0064] Subsequently, the traffic classification module queries the local traffic category priority mapping table. The mapping table stores the correspondence between traffic category IDs and priority tags. In this embodiment, game logic streams are mapped to the highest priority tag 0x3F, audio streams to the second highest tag 0x2A, video streams to tag 0x15, and other traffic streams to tag 0x00. The module generates priority tags based on the mapping results and appends them to the packet header extension field. To maintain consistency with the forward error correction process, the priority tags, error correction group identifiers, and incrementing sequence numbers are concatenated in memory in a preset order and written all at once to avoid duplicate parsing.

[0065] After the packet header is written, the client scheduling module selects the corresponding sending queue based on the priority label. Control flow and game logic flow are placed in the queue with the highest token generation rate, voice flow is placed in the secondary queue, and video flow and other traffic are placed in the low-speed queue. When the sending thread polls the queues, it always prioritizes processing high-priority queues to ensure low latency requirements for core game data. If both the source packet and its corresponding redundant packet exist in the queue, the scheduling module retrieves them consecutively in the order of "source packet followed by redundant packet" to maintain the consistency of packet order within the error correction group.

[0066] To enhance the scalability of real-time classification, this embodiment also reserves a cloud-based model hot update mechanism. When the cloud control platform pushes a new model or new mapping rule, the client traffic classification module will open a dual model buffer to complete the model replacement without stopping data packet processing. The replaced mapping table takes effect immediately without requiring a client restart or interruption of the game session.

[0067] Through the above process, this embodiment can complete the real-time classification of data packets, priority tag generation, and packet header writing within microseconds, dynamically diverting high-priority service flows and low-priority flows to different sending queues. This provides a finely detailed traffic basis for subsequent bandwidth constraints and redundancy ratio control, thereby further ensuring the transmission stability and response speed of game data in cross-border high packet loss network environments.

[0068] In some embodiments, after writing the source data packet and redundant data packets into a header field containing a priority label, the method further includes:

[0069] Based on the priority label carried by each data packet, the target sending queue identifier is determined by looking up a table, and the data packet is written into the corresponding sending queue;

[0070] Initialize a token bucket counter for each sending queue, and configure the bucket capacity and token generation rate, wherein the token generation rate is determined jointly based on the priority label and the network quality prediction value of the previous monitoring period.

[0071] In the sending thread, each sending queue is polled to check the current token count of the corresponding token bucket. When the token count is not less than the number of bytes of the data packet to be sent, the data packet is taken out from the sending queue and the same amount of tokens are deducted. Then the data packet is handed over to the network interface.

[0072] At the end of each monitoring period, the token generation rate and bucket capacity parameters of each token bucket are adaptively adjusted based on the updated network quality prediction values ​​to maintain consistency with the dynamic redundancy ratio and agent node switching configuration.

[0073] Specifically, in this embodiment, the client internally pre-configures four-level transmission queues Q0 to Q3, with priorities decreasing sequentially. The scheduling module maintains a priority-queue mapping table, mapping priority tags 0x3F to Q0, 0x2A to Q1, 0x15 to Q2, and 0x00 to Q3. After completing the priority tag writing, the packet header writing interface immediately reads this mapping table, generates a target transmission queue identifier, and records it along with the error correction group identifier and incrementing sequence number in a local circular buffer. Based on this, the scheduling module calls the queue writing function to sequentially insert the source data packet and the corresponding redundant data packet into the tail of the corresponding queue, maintaining the adjacent arrangement of packets from the same error correction group in the queue.

[0074] During the queue initialization phase, the scheduling module configures an independent token bucket counter for each sending queue. The bucket capacity C is set according to the principle of "higher priority, smaller capacity" to avoid a single queue occupying the interface for a long time; in this embodiment, the bucket capacities of Q0 to Q3 are set to 16K, 32K, 48K, and 64K bytes, respectively. The token generation rate R is jointly determined by the priority weight and the predicted packet loss rate ρ of the previous monitoring period: R = α × W / (1 + β × ρ).

[0075] Where W is the priority weight, α is the total bandwidth coefficient, and β is the packet loss sensitivity coefficient. As ρ increases, the denominator in the formula increases, and the token generation rate automatically decreases to allow queues with high redundancy ratios to obtain more bandwidth. Therefore, in high packet loss scenarios, the R values ​​of Q0 and Q1 remain relatively stable, while Q2 and Q3 will significantly reduce their rates to ensure that critical service flows are sent out first.

[0076] The sending thread uses an unconditional polling method to traverse the four-level queues, checking the token bucket counters sequentially in the order Q0→Q1→Q2→Q3. When the current token count of a queue is greater than or equal to the length of the packet at the head of the queue, the thread immediately retrieves the packet, deducts an equal number of tokens, and then calls the network interface module to fill the UDP tunnel packet and add a local timestamp. If the current token count is insufficient, the thread skips the queue and continues to check the next level of queues until all queues have been traversed. After that, it enters a short sleep (set to 25µs in this embodiment) before starting the next round of polling. This ensures that high-priority queues are served first when tokens are plentiful, while avoiding long-term starvation of low-priority streams due to queue congestion.

[0077] At the end of each monitoring cycle, the link monitoring module writes the latest predicted network quality value ρ, ΔRTT, and other metrics into the shared state area. Upon receiving an update event, the scheduling module immediately calculates the new token generation rate R′ and compares it differentially with the current R. When the difference exceeds a preset threshold of 3%, the token bucket module uses linear interpolation to gradually transition to the new rate over the next 100ms, avoiding sudden bandwidth fluctuations. Simultaneously, if the link adaptive module has adjusted its redundancy ratio or switched proxy nodes, the scheduling module synchronously refreshes the queue mapping table and updates the bucket capacity C′, ensuring that the priority scheduling logic remains consistent with the latest network environment.

[0078] To prevent extreme queue congestion, this embodiment also includes a saturation fallback mechanism: when the length of any queue exceeds 2048 data packets and it has not been fully served for three consecutive polling cycles, the scheduling module will temporarily increase the token bucket capacity of that queue by 50% and trigger a penalty token deduction for low-priority queues until the length of high-priority queues returns to below 1280 data packets. This mechanism can prioritize bandwidth allocation when a sudden high packet loss on the link causes a large increase in redundant packets, ensuring the continuous availability of control flow and game logic flow.

[0079] Through the synergy of the aforementioned real-time queue mapping, token bucket rate control, and dynamic rollback mechanism, this embodiment can complete bandwidth allocation updates within microseconds based on network quality predictions and packet priorities. This ensures that high-priority game data receives stable and sufficient transmission resources in cross-border high-packet-loss environments, while avoiding link congestion and bandwidth waste caused by a surge in redundant data packets, thereby further improving the continuity and smoothness of the overall gaming experience.

[0080] In some embodiments, the network quality prediction value for the next monitoring period is obtained by inputting the link monitoring results into a prediction algorithm, including:

[0081] The link monitoring results within a preset sliding window are aggregated to form a data vector of packet loss rate, round-trip time, and latency jitter arranged in a time series.

[0082] Perform weighted smoothing preprocessing on the data vector to obtain the denoised feature vector;

[0083] The feature vector is input into the prediction algorithm, which is based on an adaptively adjustable state-space model to jointly predict packet loss rate, round-trip time, and latency jitter, and outputs the predicted packet loss rate, predicted round-trip time, and predicted latency jitter for the next monitoring period.

[0084] The predicted packet loss rate, predicted round-trip time, and predicted delay jitter are encapsulated into network quality prediction values ​​and written into the session state table.

[0085] Specifically, in this embodiment, a prediction module is deployed inside the client. The prediction module consists of a data buffer unit, a preprocessing unit, an adaptive state-space prediction unit, and a result writing unit. Each time the link monitoring module completes a monitoring cycle, it writes the latest link monitoring result entry into the data buffer unit. The data buffer unit stores a fixed number of entries in a ring structure. In this embodiment, a sliding window of length 12 is used, which caches the packet loss rate, round-trip latency, and latency jitter data for the most recent 12 monitoring cycles.

[0086] When the sliding window fills or updates, the preprocessing unit immediately reads the three types of indicators within the window in chronological order and concatenates them to form a multidimensional data vector. To eliminate the interference of occasional spikes on model convergence, the preprocessing unit performs exponentially weighted smoothing on the data vector. The smoothing factor λ is adaptively set according to the variance of the packet loss rate within the window: λ decreases when the variance increases to increase the smoothing weight; λ increases when the variance decreases to improve the model's sensitivity. After smoothing, a denoised feature vector is obtained and written into the adaptive state-space prediction unit.

[0087] The adaptive state-space prediction unit internally implements an adjustable Kalman filter. The filter continuously maintains the system state vector and covariance matrix, with initial values ​​set via a fast self-test upon client startup. Subsequently, it performs a state update and a time prediction each time a new feature vector is received. To balance steady-state error and instantaneous convergence speed at different link stages, the filter's process noise covariance Q and observation noise covariance R are adjusted in real-time according to the following strategy: if the packet loss rate variance exceeds a threshold within the sliding window, Q is appropriately increased and R is decreased to improve the model's response to sudden increases in packet loss; conversely, the adjustment is reversed to make the prediction smoother. After the update, the prediction unit outputs the predicted packet loss rate, predicted round-trip time, and predicted delay jitter for the next monitoring cycle.

[0088] The result writing unit receives three predicted values, generates a network quality predicted value structure, and writes it along with the current session identifier into the session state table. The state table is shared and read by the link adaptation module, scheduling module, and node switching module, and is used to drive redundancy ratio adjustments, token bucket rate revisions, and candidate agent node scoring. To prevent short-term extreme predictions from triggering frequent adjustments, the result writing unit also implements threshold protection: when the difference between any predicted indicator and the previous prediction result is less than a set jitter threshold, the old value is directly reused to avoid unnecessary fluctuations.

[0089] Through the above implementation, this embodiment can jointly predict link packet loss rate, round-trip latency, and latency jitter locally on the client side based on a limited number of monitoring items, and maintain model robustness by using adaptive covariance adjustment. The prediction results are written to the session state table in a timely manner, providing a reliable reference for downstream bandwidth allocation and redundancy control, thereby suppressing the impact of link degradation on game data transmission in advance in cross-border high packet loss environments.

[0090] In some embodiments, adaptively adjusting the redundancy ratio, transmission queue bandwidth constraint parameters, and proxy nodes according to network quality prediction values ​​includes:

[0091] Quantization mapping is performed on the predicted packet loss rate, predicted round-trip time, and predicted delay jitter in the network quality prediction values ​​to obtain the redundancy ratio adjustment factor, bandwidth constraint adjustment factor, and node score weight.

[0092] Based on the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented incremental rule to generate the target redundancy ratio, which is then sent to the forward error correction encoder.

[0093] Based on the bandwidth constraint adjustment factor, the token generation rate and bucket capacity of the token bucket corresponding to each sending queue are adjusted proportionally, and the bandwidth constraint parameters are updated.

[0094] Candidate proxy nodes are comprehensively scored according to their node scoring weights to determine the target proxy node;

[0095] While maintaining existing communication, a backup tunnel is established for the target proxy node, and a proxy node switching operation is triggered when the scoring result meets the switching threshold.

[0096] Specifically, the link monitoring and prediction module outputs three metrics: predicted packet loss rate ρ, predicted round-trip time τ, and predicted delay jitter j. The adaptive module first categorizes these three metrics:

[0097] When ρ < 3%, it belongs to gear A; when 3% ≤ ρ < 10%, it belongs to gear B; when 10% ≤ ρ < 20%, it belongs to gear C; and when ρ ≥ 20%, it belongs to gear D.

[0098] The baseline for predicting round-trip delay is the historical stationary delay τ0. If τ0 = 100 milliseconds, then |τ-τ0| ≤ 20% × τ0 is classified as level A, exceeding 20% ​​but not exceeding 50% is level B, exceeding 50% but not exceeding 100% is level C, and exceeding 100% is level D.

[0099] The latency jitter grading is similar to that of round-trip latency, with the baseline being the historical jitter average value j0.

[0100] Furthermore, after the classification is completed, the module generates three internal factors:

[0101] The redundancy ratio adjustment factor Fρ is determined solely by the ρ level.

[0102] The bandwidth constraint adjustment factor Fb depends on the larger of τ and j;

[0103] The node scoring weight matrix W takes into account three levels simultaneously, with the weight order being packet loss > latency > jitter.

[0104] Furthermore, the initial redundancy ratio of the system is set to 1:1 (i.e., 1 source packet to 1 redundant packet). When Fρ changes, this ratio is corrected using a piecewise incremental rule:

[0105] When the ρ gear is A and the current redundancy ratio is >0, it will immediately be reduced to 0 redundancy;

[0106] When in gear B, adjust the ratio to 1:0.5;

[0107] When in gear C, adjust to 1:1;

[0108] When in gear D, adjust to 1:1.5.

[0109] The corrected results generate a target redundancy ratio control command, which is sent to the forward error correction encoder via a shared memory channel. The encoder switches to the new ratio after processing the current error correction group, ensuring consistency between group boundaries.

[0110] Furthermore, the client sets up four sending queues Q0 to Q3, with priorities from high to low corresponding to control flow, game logic flow, audio flow, video, and other streams. Each queue is bound to a token bucket (capacity C and rate R), with initialization examples as follows: Q0 (C=16K, R=40Mbps), Q1 (C=32K, R=30Mbps), Q2 (C=48K, R=20Mbps), and Q3 (C=64K, R=10Mbps).

[0111] In some examples, when Fb shows increased link congestion (level C or D), the adaptive module proportionally reduces the rate of low-priority queues:

[0112] In gear C, keep Q0 constant, reduce Q1 by 20%, Q2 by 40%, and Q3 by 50%.

[0113] When in gear D, Q1, Q2, and Q3 are reduced by an additional 10%.

[0114] When Fb indicates the link is stabilizing (level A or B), the rate is increased proportionally until the initial configuration is restored. Bucket capacity adjustments are scaled at the same rate, in 5 short steps, each 20 milliseconds apart, for a smooth transition.

[0115] Furthermore, the client stores up to 5 connectable proxy nodes, each maintaining real-time metrics: packet loss rate ρn, average latency τn, jitter jn, real-time load Ln, and cost Fn. A typical configuration example of the node rating weight matrix W is as follows: when ρ is at level D, the weight ratio is ρ:τ:j:L:F = 5:2:1:1:1; when ρ is at level A, the weight ratio drops to 3:3:2:1:1.

[0116] The comprehensive score Sn = the sum of the standardized 5 indicators multiplied by their corresponding weights; a higher score indicates better performance. If the score of the highest-scoring node T is higher than the current node by a threshold ΔS (ΔS = 8 points in this example), and the current node's lock-in period has ended, then the adaptive module sets T as the target proxy node and initiates backup tunnel preheating.

[0117] Handshake initiation and verification delay <200 milliseconds;

[0118] Send 100 probe packets consecutively to verify that ρ < 5% and τ is equal to or lower than the current node;

[0119] Maintain the backup tunnel heartbeat for 20 seconds. If there are no abnormalities during this period, the switching conditions are met.

[0120] The switching action is performed at the boundary of the next error correction group. After the switch, the old tunnel remains alive for 30 seconds. If an anomaly is found in the target tunnel during this period, it can be rolled back immediately.

[0121] In some examples, this embodiment also includes closed-loop protection and anti-shake design, as detailed below:

[0122] Gear shift anti-shake: The same indicator gear must be maintained for at least one complete monitoring cycle (1 second) before it is allowed to change again.

[0123] Parameter adjustment threshold: The redundancy ratio adjustment must be ≥0.5 across levels. Bandwidth parameter adjustment will not be triggered when the difference between the old and new values ​​is <3%.

[0124] Node locking and switching protection: After each node switch, the node is locked for 50 seconds, during which no new switch will be triggered.

[0125] Overload rollback: If any queue length is >2048 packets and has not decreased for 3 consecutive polling cycles (approximately 75 microseconds), increase the queue bucket capacity by 50% and deduct 20% of tokens from low-priority queues until the length drops below 1280 packets.

[0126] In a specific example, in a test environment, the client connects to an overseas node. Initial state: packet loss rate 2%, round-trip latency 95 milliseconds, jitter 6 milliseconds, corresponding to Tier A. Redundancy ratio 0, queue rate at initial configuration. Several minutes later, link jitter and a slight increase in packet loss occur: ρ=8% (Tier B), τ=110 milliseconds (Tier B), j=9 milliseconds (Tier B). The module adjusts the redundancy ratio to 1:0.5 according to the rules, while the rates of Q1, Q2, and Q3 decrease by 20% sequentially. Five seconds later, the link experiences a sudden 50% packet loss and a doubling of latency: ρ=25% (Tier D), τ=210 milliseconds (Tier D), j=18 milliseconds (Tier C). The redundancy ratio immediately increases to 1:1.5, low-priority rates are further compressed, and high-priority rates remain unchanged. Node scoring shows that the backup node S scores 12 points higher than the current node. The module warms up the backup tunnel and completes the switchover in the next error correction group. Subsequently, the link quality recovers to 4% packet loss and 120 milliseconds latency. The system automatically adjusted the redundancy ratio to 1:0.5 and gradually released low-priority packets. Throughout the process, the game session did not experience any noticeable lag; the average frame synchronization latency was kept below 200 milliseconds, and the number of consecutive high-priority packets lost did not exceed two.

[0127] Through the above process, this embodiment achieves rapid redundancy adjustment, fine bandwidth scheduling and intelligent node switching on the client side based on predicted network quality. The complete closed loop ensures that game data maintains reliable, low-latency and high-bandwidth efficiency transmission characteristics even in cross-border high packet loss environments.

[0128] In some embodiments, after adaptively adjusting the redundancy ratio, transmission queue bandwidth constraint parameters, and proxy nodes according to network quality prediction values, the method further includes:

[0129] When the packet loss rate does not exceed the second threshold for three consecutive monitoring periods, a cancellation command is issued to the forward error correction encoder to stop generating redundant data packets, while maintaining the priority label and sending queue configuration.

[0130] Specifically, after the above adaptive adjustment is completed, the client continuously performs link monitoring. At the end of each monitoring cycle, the link monitoring module writes the packet loss rate for that cycle into a circular state buffer. To ensure the safe and reliable operation of revoking forward error correction, this embodiment introduces a "continuous stability window" determination mechanism: the client maintains a recent packet loss rate list L=[ρ1, ρ2, ρ3] of length 3, corresponding sequentially to the three most recent monitoring cycles; when a new monitoring result ρnew appears, the list is shifted to the right in chronological order, discarding the oldest data and placing ρnew at the beginning. After each update, the adaptive module immediately checks whether all elements in L are less than or equal to the second threshold ρ2. The second threshold is set to 1% in this embodiment and can be configured within the range of 0% to 3% according to business needs.

[0131] If L satisfies the condition that all values ​​are less than or equal to ρ2, it indicates that the link has maintained low packet loss for three consecutive cycles, and redundant coding can be safely withdrawn. At this point, the adaptive module performs the following steps:

[0132] Furthermore, the module constructs a "redundancy deactivation" control frame. The frame header includes a cancellation flag and a timestamp `tstop`, used to inform the forward error correction encoder to stop generating redundant data packets. To prevent the control frame from being dropped in the network, the client sends three identical control frames consecutively and sets an acknowledgment timer locally, waiting for the encoder to return an acknowledgment notification. If no acknowledgment is received within 3 seconds, the module retransmits the control frame and issues an alarm log.

[0133] Upon receiving a revocation command, the forward error correction encoder first completes the encoding and transmission of the current error correction group. It then clears the internal error correction group buffer and resets the sequence number counter within the group to 0, ensuring that there will be no conflict with old sequence numbers when redundancy is reactivated next time. After completing these operations, the encoder returns a confirmation message containing the revocation effective timestamp tclear.

[0134] After redundancy is removed, the traffic classification module continues to write priority tags to newly generated source data packets according to the original process; the token bucket rate and bucket capacity of the sending queue remain at their latest configurations before removal, and will not be immediately amplified due to the disappearance of redundancy, preventing data surges caused by sudden bandwidth spikes. If subsequent forecast indicators show that the network continues to be stable, the bandwidth constraint control submodule will gradually release the low-priority queue rate within a normal cycle, restoring it to the recommended value under stable link conditions.

[0135] To avoid repeated restarts and shutdowns of redundancy due to slight fluctuations in the link, this embodiment sets a "silent observation period" (Tobs=2 seconds) after cancellation. During the silent period, even if the packet loss rate exceeds ρ2 in a single instance, redundancy will not be restarted immediately; instead, it will wait for the observation period to end before re-entering the normal judgment process. If the packet loss rate is still greater than ρ2 in any monitoring period after the silent observation period ends, the counter will be immediately reset to zero and the Fρ judgment process will be re-entered.

[0136] The adaptive module writes the revocation event to the session state table as a "session configuration update" entry. The recorded fields include the revocation start time (tstop), revocation confirmation time (tclear), revocation reason code (continuous low packet loss), and the redundancy ratio (0) after revocation. This entry is synchronously written to the local log file and reported the next time Telemetry is sent to the cloud control platform, facilitating the cloud-side scheduler's statistics on the client's adaptive status.

[0137] After the revocation takes effect, the adaptive module continues to collect link monitoring results and input them into the prediction algorithm. If subsequent network quality predictions show that the packet loss rate tier has risen to B or higher, the module immediately restarts the previously described redundancy ratio increment process. To prevent frequent oscillations, the system requires that at least one complete error correction group be coded after redundancy is enabled before the revocation conditions can be re-evaluated.

[0138] Through the aforementioned cancellation mechanism, this embodiment ensures that the activation and deactivation of forward error correction are based on continuous, multi-cycle stable indicators, avoiding unnecessary redundancy or premature cancellation due to instantaneous data fluctuations. At the same time, through the silent observation period and log backtracking capabilities, it provides traceable evidence for subsequent link trend analysis and user experience evaluation, further improving the overall stability and bandwidth utilization efficiency of game data transmission in cross-border high packet loss environments.

[0139] In some embodiments, sending the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy node includes:

[0140] Establish and maintain a transport tunnel with the updated proxy node;

[0141] The sorted source data packets and redundant data packets are retrieved sequentially from each sending queue according to their priority order.

[0142] Write the agent node identifier, error correction group identifier, incrementing sequence number, and priority label into the forwarding header of the source data packet and redundant data packet;

[0143] The source data packet and redundant data packets are forwarded to the agent node via the transmission tunnel;

[0144] The proxy node performs decapsulation and forward error correction decoding on the received data packets, rearranges the restored source data packet sequence, and forwards the source data packet sequence to the target game server or game client.

[0145] Specifically, in this embodiment, the client has determined the target proxy node T through the adaptive module and completed tunnel preheating. Then, it enters the formal data forwarding phase, the specific process of which is described below.

[0146] The client establishes a session with node T using a UDP-based multiplexed tunneling protocol. The handshake message includes a client-side random number, a list of supported cipher suites, and a session identifier (SID). Node T returns a handshake confirmation and negotiates the session key. A handshake round-trip delay of less than 180 milliseconds is considered successful. The client records the SID locally and starts a keep-alive timer, sending a heartbeat packet containing the SID to node T every 3 seconds. Node T immediately acknowledges receipt, and both parties maintain a counter (cnt) for consecutive unacknowledged responses. If cnt ≥ 3, the tunnel is considered to have failed, and the client immediately reverts to the backup path and reports an anomaly.

[0147] The client scheduling thread polls in the order of the priority queue Q0 → Q1 → Q2 → Q3. If the token bucket permits, it retrieves the packet at the head of the current queue and writes it into the internal sorting buffer B. To maintain the integrity of the error correction group, when a source packet is retrieved, its error correction group identifier IDg is immediately read, and packet retrieval continues until IDg changes or the number of packets in the group reaches the upper limit, ensuring that packets in the same group are arranged consecutively. The size of buffer B is fixed at 256 packets. When it is full or a 5 - millisecond timeout occurs, it triggers a transmission batch.

[0148] The sending thread traverses buffer B and performs header writing for each source packet and its corresponding redundant packet:

[0149] Proxy node identifier IDn: 4 bytes, using the hash abbreviation of node T;

[0150] Error correction group identifier IDg: 2 bytes;

[0151] Incremental sequence number SN: 4 bytes, incrementing separately in the source and redundant packets;

[0152] Priority label PL: 1 byte, corresponding to the mapping values of Q0 - Q3.

[0153] The total header length is 11 bytes, which is directly inserted into the UDP payload header without recalculating the IP - layer checksum. After writing is completed, the packet is moved to the sending buffer S.

[0154] The client configures a rate - based sender for the tunnel. The initial PacingRate is determined by the BBR algorithm based on the recent RTT and the estimated bandwidth. Whenever a packet is retrieved from the sending buffer S, the packet size is recorded in the sending token counter, and the next allowed sending time tallow is calculated according to PacingRate. If the current time < tallow, the thread pauses briefly for 10 µs and then retries to avoid short - term bursts. After the packet is sent, the local millisecond - level timestamp is recorded and written into the circular log for subsequent lost - packet inference.

[0155] Node T listens for the tunnel corresponding to SID in the worker thread pool. After receiving a client packet, it first checks the match between IDn and SID, then resolves IDg and SN to restore the error correction group relationship, and writes the packet into the group cache Cg. The capacity of each group cache is dynamically adjusted according to the redundancy ratio. For example, in a 1:1 ratio, each group can receive at most 8 packets. When Cg reaches the group capacity or a 10 - millisecond timeout occurs, it triggers decoding. When the number of lost source packets does not exceed the number of redundant packets, node T calls the local FEC decoding library to reconstruct the missing source packets; if the loss exceeds the limit, it immediately marks it as failed and writes it into the lost - packet statistics. The decoded source packets are written into the rearrangement buffer R in ascending order of SN.

[0156] Node T performs traffic classification mapping on the rearrangement buffer R, determines the internal scheduling order based on PL priority, and uses a token bucket and WFQ hybrid algorithm to control the outbound rate to the target game server or game client, ensuring that high-priority packets are given priority. Node T removes proxy-related fields from the header, retaining only the original game payload and necessary NAT traversal identifiers to maintain compatibility with the server protocol.

[0157] Node T generates a transmission statistics frame every second, with fields including the number of successfully decoded groups, the number of failed decoded groups, the average group recovery delay, the real-time packet loss rate, and the egress bandwidth usage. The statistics frame is returned to the client via the control channel, serving as input for the prediction model in the next cycle. Upon receiving the frame, the client updates its local status table and simultaneously writes key metrics to a visualization panel for user viewing.

[0158] If node T reports a decoding failure rate >30% or heartbeat disconnection for 3 consecutive seconds, the client immediately triggers a fast node switchover process:

[0159] Select the second-best node S2 from the list of candidate nodes;

[0160] Start the S2 tunnel warm-up and smoothly migrate the send pointer;

[0161] Disconnect from T tunnel after both error correction groups are completed.

[0162] Switching events are logged and synchronized to the cloud control platform. To prevent frequent switching, the system sets a 50-second lockout period for the same node, during which it will not be evaluated as a candidate node.

[0163] The results of this embodiment demonstrate that, in a test scenario with an average packet loss rate of 10% and a latency of 180 milliseconds on cross-border links, the above process can control the final end-to-end packet loss rate to within 0.8%, increase the average latency of the logical flow by no more than 25 milliseconds, and no game interruption or large-scale rollback was observed during tunnel switching. This embodiment further verifies that by using ordered packaging, priority-based traffic splitting, and edge decoding collaboration, the reliability and stability of real-time game data transmission in cross-border high packet loss environments can be significantly improved.

[0164] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0165] Figure 2 This is a schematic diagram of the packet loss optimization device for a game accelerator based on traffic priority management provided in an embodiment of this application. Figure 2 As shown, the game accelerator packet loss optimization device based on traffic priority management includes:

[0166] The detection module 201 is used to perform periodic link detection on at least one proxy node, obtain packet loss rate, latency and jitter data for each monitoring period, and generate corresponding link monitoring results;

[0167] The error correction module 202 is used to determine whether the packet loss rate of two consecutive monitoring periods exceeds the first threshold based on the link monitoring results. If it exceeds the threshold, it sends an enable command to the forward error correction encoder and selects the corresponding redundancy ratio according to the packet loss rate range. It performs forward error correction encoding on the game data packets to be sent and generates redundant data packets corresponding to the source data packets.

[0168] The classification module 203 is used to classify the data stream to be sent in real time, obtain priority labels for different traffic categories, and write the source data packets and redundant data packets into the header field containing the priority labels.

[0169] The adjustment module 204 is used to input the prediction algorithm based on the link monitoring results to obtain the network quality prediction value for the next monitoring period, and adaptively adjust the redundancy ratio, sending queue bandwidth constraint parameters and proxy nodes according to the network quality prediction value.

[0170] The sending module 205 is used to send the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy node, so as to achieve accelerated forwarding of game data.

[0171] In some embodiments, Figure 2 In each monitoring period, the detection module 201 sends a sequence of detection packets to the target agent node at a preset detection packet sending rate. Each detection packet in the sequence carries a link identifier, a monitoring period identifier, an incrementing sequence number, and a sending timestamp. After receiving the acknowledgment corresponding to the detection packet sequence, the module compares the number of acknowledged detection packets with the number of sent detection packets based on the incrementing sequence number to calculate the packet loss rate for the current monitoring period. The module calculates the round-trip delay based on the sending timestamp and the arrival time of the acknowledgment, and uses a sliding window to statistically analyze the delay difference of consecutive detection packets to obtain the delay jitter corresponding to the current monitoring period. The module writes the packet loss rate, round-trip delay, and delay jitter into the link monitoring result entry associated with the monitoring period, and stores the link monitoring result entry in the local monitoring cache and / or reports it to the control platform.

[0172] In some embodiments, Figure 2The error correction module 202 sequentially collects a preset number of source data packets in the transmission buffer according to the current redundancy ratio to form an error correction group; it calls the forward error correction encoder, and according to the redundancy ratio and the number of packets in the error correction group, it uses a preset forward error correction algorithm to encode the error correction group to obtain redundant data packets that correspond one-to-one with the source data packets; it writes the error correction group identifier and the incrementing sequence number to the source data packets and the redundant data packets respectively, and retains the existing priority label of the source data packets; it synchronously outputs the source data packets and the corresponding redundant data packets to the transmission queue that matches the priority label for subsequent transmission.

[0173] In some embodiments, Figure 2 The classification module 203 extracts the five-tuple information and a pre-defined length payload segment from each data packet in the data stream to be sent, generating a corresponding traffic feature vector. The traffic feature vector is input into the traffic classification module, which uses a deep packet inspection algorithm or a machine learning-based traffic identification model to determine the traffic category to which the data packet belongs. According to the pre-stored traffic category priority mapping table, a priority label is matched to the determination result. The packet header writing interface is called to write the priority label into the reserved packet header field, and the error correction group identifier and sequence number added during the forward error correction coding process are retained. The source data packet with the priority label written and the corresponding redundant data packet are output to the sending queue associated with the priority label.

[0174] In some embodiments, Figure 2 The detection module 206 is used to, after writing the source data packet and redundant data packet into the packet header field containing the priority label, look up a table to determine the target sending queue identifier according to the priority label carried by each data packet, and write the data packet into the corresponding sending queue; initialize a token bucket counter for each sending queue, configure the bucket capacity and token generation rate, wherein the token generation rate is jointly determined based on the priority label and the network quality prediction value of the previous monitoring period; in the sending thread, poll each sending queue, detect the current token count of the corresponding token bucket, when the token count is not less than the number of bytes of the data packet to be sent, take the data packet from the sending queue and deduct an equal amount of tokens, and then transfer the data packet to the network interface; at the end of each monitoring period, adaptively adjust the token generation rate and bucket capacity parameters of each token bucket based on the updated network quality prediction value, so as to keep in line with the dynamic redundancy ratio and agent node switching configuration.

[0175] In some embodiments, Figure 2The adjustment module 204 aggregates the link monitoring results within a preset sliding window, forming a data vector of packet loss rate, round-trip delay, and delay jitter arranged in a time series. Weighted smoothing preprocessing is performed on the data vector to obtain a denoised feature vector. This feature vector is then input into a prediction algorithm, which, based on an adaptively adjustable state-space model, jointly predicts the packet loss rate, round-trip delay, and delay jitter, outputting the predicted packet loss rate, predicted round-trip delay, and predicted delay jitter for the next monitoring period. The predicted packet loss rate, predicted round-trip delay, and predicted delay jitter are then encapsulated into network quality prediction values ​​and written into the session state table.

[0176] In some embodiments, Figure 2 The adjustment module 204 performs quantization mapping on the predicted packet loss rate, predicted round-trip time, and predicted delay jitter in the network quality prediction values ​​to obtain the redundancy ratio adjustment factor, bandwidth constraint adjustment factor, and node scoring weight. Based on the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented incremental rule to generate the target redundancy ratio, which is then sent to the forward error correction encoder. Based on the bandwidth constraint adjustment factor, the token generation rate and bucket capacity of the token buckets corresponding to each sending queue are adjusted proportionally to update the bandwidth constraint parameters. The candidate proxy nodes are comprehensively scored according to the node scoring weight to determine the target proxy node. While maintaining existing communication, a backup tunnel is established for the target proxy node, and the proxy node switching operation is triggered when the scoring result meets the switching threshold.

[0177] In some embodiments, Figure 2 After the adjustment module 204 adaptively adjusts the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value, when the packet loss rate does not exceed the second threshold for three consecutive monitoring periods, it issues a cancellation command to the forward error correction encoder to stop generating redundant data packets, while maintaining the priority label and sending queue configuration.

[0178] In some embodiments, Figure 2 The sending module 205 establishes and maintains a transmission tunnel with the updated proxy node; it sequentially retrieves sorted source data packets and redundant data packets from each sending queue according to the priority order of the sending queue; it writes the proxy node identifier, error correction group identifier, incrementing sequence number, and priority label into the forwarding header of the source data packets and redundant data packets; it forwards the source data packets and redundant data packets to the proxy node through the transmission tunnel; the proxy node performs decapsulation and forward error correction decoding on the received data packets, rearranges the restored source data packet sequence, and forwards the source data packet sequence to the target game server or game client.

[0179] It should be understood that the sequence number of each step in the above embodiments does not imply 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.

[0180] Figure 3 This is a schematic diagram of the structure of the electronic device 3 provided in an embodiment of this application. For example... 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, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0181] 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 complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 303 in electronic device 3.

[0182] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0183] Processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

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

[0185] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to 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 embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0186] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0187] Those skilled in the art will recognize that the units and algorithm steps of the various examples 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 implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art 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.

[0188] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and 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, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

[0189] The units described as separate components may or may not be physically separate. The 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 the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0190] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0191] If an integrated module / unit is implemented as 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0192] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application are described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for optimizing packet loss in a game accelerator based on traffic priority management, characterized in that, include: Perform periodic link probing on at least one proxy node, obtain packet loss rate, latency and jitter data for each monitoring period, and generate corresponding link monitoring results; Based on the link monitoring results, it is determined whether the packet loss rate of two consecutive monitoring periods exceeds the first threshold. If it does, an activation command is sent to the forward error correction encoder, and the corresponding redundancy ratio is selected according to the packet loss rate range. Forward error correction encoding is performed on the game data packets to be sent to generate redundant data packets corresponding to the source data packets. The data stream to be sent is classified in real time to obtain priority labels for different traffic categories, and the source data packets and the redundant data packets are written into the header field containing the priority labels. Based on the link monitoring results, the prediction algorithm is used to obtain the network quality prediction value for the next monitoring period, and the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes are adaptively adjusted according to the network quality prediction value. The sorted source data packets and redundant data packets are sent to the target game server or game client according to the updated proxy nodes to achieve accelerated forwarding of game data; The adaptive adjustment of the redundancy ratio, sending queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value includes: Quantization mapping is performed on the predicted packet loss rate, predicted round-trip time, and predicted delay jitter in the network quality prediction values ​​to obtain the redundancy ratio adjustment factor, bandwidth constraint adjustment factor, and node score weight. Based on the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented incremental rule to generate the target redundancy ratio, which is then sent to the forward error correction encoder. Based on the bandwidth constraint adjustment factor, the token generation rate and bucket capacity of the token bucket corresponding to each sending queue are adjusted proportionally, and the bandwidth constraint parameters are updated. The candidate proxy nodes are comprehensively scored according to the node scoring weights to determine the target proxy node; While maintaining existing communication, a backup tunnel is established for the target proxy node, and a proxy node switching operation is triggered when the scoring result meets the switching threshold.

2. The method according to claim 1, characterized in that, The process involves performing periodic link probing on at least one proxy node, acquiring packet loss rate, latency, and jitter data for each monitoring period, and generating corresponding link monitoring results, including: Within each monitoring period, a sequence of probe packets is sent to the target proxy node at a preset probe packet sending rate. Each probe packet in the sequence carries a link identifier, a monitoring period identifier, an incrementing sequence number, and a sending timestamp. After receiving the receipt corresponding to the probe packet sequence, the number of probe packets with receipts is compared with the number of probe packets sent based on the incrementing sequence number, and the packet loss rate of the current monitoring period is calculated. The round-trip delay is calculated based on the sending timestamp and the receipt arrival time, and the delay difference of continuous probe packets is statistically analyzed through a sliding window to obtain the delay jitter corresponding to the current monitoring period. The packet loss rate, round-trip time, and latency jitter are written into the link monitoring result entries associated with the monitoring period, and the link monitoring result entries are stored in the local monitoring cache and / or reported to the control platform.

3. The method according to claim 1, characterized in that, The step of performing forward error correction encoding on the game data packets to be sent to generate redundant data packets corresponding to the source data packets includes: Based on the current redundancy ratio, a preset number of source data packets are sequentially collected from the sending buffer to form an error correction group; The forward error correction encoder is invoked, and the error correction group is encoded using a preset forward error correction algorithm according to the redundancy ratio and the number of packets in the error correction group to obtain redundant data packets that correspond one-to-one with the source data packets. Write the error correction group identifier and incrementing sequence number to the source data packet and the redundant data packet respectively, and retain the existing priority label of the source data packet; The source data packet and the corresponding redundant data packet are synchronously output to the sending queue that matches the priority label for subsequent sending.

4. The method according to claim 1, characterized in that, The step of real-time classification of the data stream to be sent, obtaining priority labels for different traffic categories, and writing the source data packets and the redundant data packets into a header field containing the priority labels includes: Extract the quintuple information of each data packet in the data stream to be sent and the payload segment of a preset length to generate the corresponding traffic feature vector; The traffic feature vector is input into the traffic classification module, and the traffic category to which the data packet belongs is determined by a deep packet inspection algorithm or a machine learning-based traffic identification model. Based on the pre-stored traffic category priority mapping table, priority labels are matched to the discrimination results; Call the packet header writing interface to write the priority tag into the reserved packet header field, and retain the error correction group identifier and sequence number added during the forward error correction coding process; The source data packet with the priority tag written on it, along with the corresponding redundant data packet, is output to the sending queue associated with the priority tag.

5. The method according to claim 1, characterized in that, After writing the source data packet and the redundant data packet into the header field containing the priority label, the method further includes: Based on the priority label carried by each data packet, the target sending queue identifier is determined by looking up a table, and the data packet is written into the corresponding sending queue; Initialize a token bucket counter for each sending queue, and configure the bucket capacity and token generation rate, wherein the token generation rate is determined jointly based on the priority label and the network quality prediction value of the previous monitoring period; In the sending thread, each sending queue is polled to check the current token count of the corresponding token bucket. When the token count is not less than the number of bytes of the data packet to be sent, the data packet is taken out from the sending queue and the same amount of tokens are deducted. Then the data packet is handed over to the network interface. At the end of each monitoring period, the token generation rate and bucket capacity parameters of each token bucket are adaptively adjusted based on the updated network quality prediction values ​​to maintain consistency with the dynamic redundancy ratio and agent node switching configuration.

6. The method according to claim 1, characterized in that, The step of inputting the link monitoring results into the prediction algorithm to obtain the network quality prediction value for the next monitoring period includes: The link monitoring results within a preset sliding window are aggregated to form a data vector of packet loss rate, round-trip time, and latency jitter arranged in a time series. The data vector is subjected to weighted smoothing preprocessing to obtain the denoised feature vector; The feature vector is input into the prediction algorithm, which is based on an adaptively adjustable state-space model to jointly predict packet loss rate, round-trip time, and latency jitter, and outputs the predicted packet loss rate, predicted round-trip time, and predicted latency jitter corresponding to the next monitoring period. The predicted packet loss rate, predicted round-trip time, and predicted delay jitter are encapsulated into network quality prediction values ​​and written into the session state table.

7. The method according to claim 1, characterized in that, After adaptively adjusting the redundancy ratio, transmission queue bandwidth constraint parameters, and proxy nodes according to the network quality prediction value, the method further includes: When the packet loss rate does not exceed the second threshold for three consecutive monitoring periods, a cancellation command is issued to the forward error correction encoder to stop generating redundant data packets, while maintaining the priority label and sending queue configuration.

8. The method according to claim 1, characterized in that, The step of sending the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy nodes includes: Establish and maintain a transport tunnel with the updated proxy node; The sorted source data packets and redundant data packets are retrieved sequentially from each sending queue according to their priority order. Write the agent node identifier, error correction group identifier, incrementing sequence number, and priority label into the forwarding header of the source data packet and redundant data packet; The source data packet and redundant data packets are forwarded to the proxy node via the transmission tunnel; The proxy node performs decapsulation and forward error correction decoding on the received data packets, rearranges the restored source data packet sequence, and forwards the source data packet sequence to the target game server or game client.

9. A packet loss optimization device for a game accelerator based on traffic priority management, characterized in that, include: The detection module is used to perform periodic link detection on at least one proxy node, obtain packet loss rate, latency and jitter data for each monitoring period, and generate corresponding link monitoring results; The error correction module is used to determine whether the packet loss rate of two consecutive monitoring periods exceeds the first threshold based on the link monitoring results. If it does, it sends an enable command to the forward error correction encoder and selects the corresponding redundancy ratio according to the packet loss rate range. It performs forward error correction encoding on the game data packets to be sent and generates redundant data packets corresponding to the source data packets. The classification module is used to classify the data stream to be sent in real time, obtain priority labels for different traffic categories, and write the source data packets and the redundant data packets into the header field containing the priority labels. The adjustment module is used to input the prediction algorithm based on the link monitoring results to obtain the network quality prediction value for the next monitoring period, and adaptively adjust the redundancy ratio, transmission queue bandwidth constraint parameters and proxy nodes according to the network quality prediction value. The sending module is used to send the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy node, so as to accelerate the forwarding of game data; The adjustment module is used to perform quantization mapping on the predicted packet loss rate, predicted round-trip time and predicted delay jitter in the network quality prediction value to obtain the redundancy ratio adjustment factor, bandwidth constraint adjustment factor and node score weight. Based on the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented incremental rule to generate the target redundancy ratio, which is then sent to the forward error correction encoder. Based on the bandwidth constraint adjustment factor, the token generation rate and bucket capacity of the token buckets corresponding to each sending queue are adjusted proportionally to update the bandwidth constraint parameters. The candidate proxy nodes are comprehensively scored according to the node scoring weight to determine the target proxy node. While maintaining existing communication, a backup tunnel is established for the target proxy node, and a proxy node switching operation is triggered when the scoring result meets the switching threshold.

Images