Game accelerator packet loss optimization method and device based on flow priority management

Abstract

The invention provides a game accelerator packet loss optimization method and device based on flow priority management. The method comprises the following steps: executing periodic link detection on at least one proxy node, and generating a corresponding link monitoring result; judging whether the packet loss rates of two continuous monitoring periods exceed a first threshold value or not according to the link monitoring result; performing real-time classification on the to-be-sent data streams to obtain priority labels for different traffic categories; inputting a prediction algorithm based on a link monitoring result, obtaining a network quality prediction value of a next monitoring period, adaptively adjusting a redundancy proportion according to the network quality prediction value, and sending a queue bandwidth constraint parameter and an agent node; and sending the sorted source data packet and the redundant data packet to a target game server or a game client according to the updated proxy node so as to realize accelerated forwarding of the game data. According to the invention, the reliability, delay stability and bandwidth utilization rate of game data transmission in a cross-border high packet loss network environment can be improved.

Description

Technical Field

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

[0002] With the increasing prevalence of cross-border network infrastructure, more and more domestic players are using accelerators to connect to game servers located overseas. Cross-border links often face objective factors such as long transmission distances, multiple relay layers, and varying congestion control strategies, resulting in increased round-trip latency, significant jitter, and high packet loss rates. In competitive and massively multiplayer online gaming scenarios, where network real-time performance is crucial, any momentary packet loss or latency fluctuation can disrupt user experience and game synchronization. Therefore, ensuring highly reliable delivery of game data in unpredictable cross-border network environments has become a technical issue of concern to the industry.

[0003] To address these issues, the industry typically employs methods such as: establishing dedicated proxy channels between the user end and overseas nodes to forward gaming traffic via TCP or UDP tunnels; enabling automatic reconnection or retransmission confirmation (ARQ)-based compensation mechanisms on the client; configuring static forward error correction (FEC) parameters in proxy nodes to combat moderate 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: excessive reliance on retransmission introduces additional latency, static redundancy configurations continue to occupy bandwidth even after network recovery, and simple node switching strategies are unable to cope with drastic fluctuations in link conditions. Furthermore, existing technologies typically treat all types of gaming-related traffic equally, failing to differentiate between 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, an embodiment of the present application provides a game accelerator packet loss optimization method and device based on traffic priority management to solve the problem that the existing technology is unable to dynamically adjust redundancy compensation according to real-time network quality and implement priority management for different business flows, resulting in insufficient game data transmission reliability and bandwidth utilization in cross-border high packet loss environments.

[0005] According to a first aspect of an embodiment of the present application, a method for optimizing packet loss of a game accelerator based on traffic priority management is provided, comprising: performing periodic link detection on at least one proxy node, obtaining packet loss rate, delay and jitter data of each monitoring period, and generating corresponding link monitoring results; judging whether the packet loss rate of two consecutive monitoring periods exceeds a first threshold value based on the link monitoring results, and if so, sending an enable instruction to a forward error correction encoder, selecting a corresponding redundancy ratio based on the packet loss rate interval, performing forward error correction encoding on the game data packet to be sent, and generating a redundant data packet corresponding to the source data packet; classifying the data stream to be sent in real time, obtaining priority labels for different traffic categories, and writing the source data packet and the redundant data packet into a packet header field containing the priority label; inputting a prediction algorithm based on the link monitoring results 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; sending the sorted source data packet and redundant data packet to the target game server or game client according to the updated proxy node to achieve accelerated forwarding of game data.

[0006] According to a second aspect of an embodiment of the present application, a game accelerator packet loss optimization device based on traffic priority management is provided, comprising: a detection module for performing periodic link detection on at least one proxy node, obtaining packet loss rate, latency, and jitter data for each monitoring period, and generating corresponding link monitoring results; an error correction module for determining whether the packet loss rate of two consecutive monitoring periods exceeds a first threshold based on the link monitoring results; if so, issuing an activation instruction to a forward error correction encoder, selecting a corresponding redundancy ratio based on the packet loss rate interval, performing forward error correction encoding on game data packets to be transmitted, and generating redundant data packets corresponding to source data packets; a classification module for classifying data streams to be transmitted in real time, obtaining priority tags for different traffic categories, and writing source data packets and redundant data packets into a packet header field containing the priority tag; an adjustment module for inputting a prediction algorithm based on the link monitoring results, obtaining 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 a sending module for sending the sorted source data packets and redundant data packets to a target game server or game client according to the updated proxy node to achieve accelerated forwarding of game data.

[0007] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: By performing periodic link detection on at least one proxy node, the packet loss rate, delay and jitter data of each monitoring cycle are obtained, and the corresponding link monitoring results are generated; based on the link monitoring results, it is determined whether the packet loss rate of two consecutive monitoring cycles exceeds the first threshold. If it exceeds, an activation instruction is sent to the forward error correction encoder, and the corresponding redundancy ratio is selected according to the packet loss rate range, and the game data packet to be sent is forward error correction encoded to generate a redundant data packet corresponding to the source data packet; the data stream to be sent is classified in real time, priority labels for different traffic categories are obtained, and the source data packet and the redundant data packet are written into the packet header field containing the priority label; based on the link monitoring results, a prediction algorithm is input to obtain the network quality prediction value of the next monitoring cycle, and the redundancy ratio, the sending queue bandwidth constraint parameters and the proxy node are adaptively adjusted according to the network quality prediction value; the sorted source data packet and the redundant data packet are sent to the target game server or game client according to the updated proxy node to realize the accelerated forwarding of game data. This application can improve the reliability, delay stability and bandwidth utilization of game data transmission in a cross-border high packet loss network environment. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] Figure 1 1 is a flow chart of a method for optimizing packet loss in a game accelerator based on traffic priority management according to an embodiment of the present application; Figure 2 2 is a schematic diagram of the structure of a game accelerator packet loss optimization device based on traffic priority management provided by an embodiment of the present application; Figure 3 It is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

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

[0011] Existing technologies generally use accelerators to establish dedicated tunnels between clients and overseas proxy nodes, and employ fixed redundant FEC, simple ARQ retransmission, or timed node switching to mitigate high packet loss on cross-border links. However, these approaches lack granular monitoring and prediction of link packet loss rates, latency, and jitter. They are unable to adjust redundancy based on demand when network quality fluctuates dramatically, and they fail to differentiate between the importance of control streams, voice streams, and video streams. This can lead to significant loss of critical gaming data and considerable bandwidth waste during periods of low packet loss.

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

[0013] To this end, this application proposes a method and device for optimizing packet loss in a game accelerator based on traffic priority management. The technical solution of this application mainly includes the following contents: Periodically sends probe packets to proxy nodes to obtain packet loss rate, round-trip delay, and jitter, and generates a predicted value for network quality for the next period through a prediction algorithm. When the predicted or real-time monitored packet loss rate exceeds the set threshold, forward error correction coding is performed on the game data packets in the data stream to be sent according to the redundancy ratio selected in the interval to generate redundant data packets; Extract features from each data packet in the data stream to be sent, use the traffic classification model to identify the traffic category and write a priority label; The scheduling module places data packets into the corresponding sending queue based on the priority tag, and adaptively adjusts the redundancy ratio, queue rate, and proxy nodes based on the token bucket bandwidth constraint and network quality prediction value; When the packet loss rate returns to below the cancellation threshold within multiple consecutive monitoring cycles, redundant encoding is automatically terminated, and the priority and queue configuration are retained to achieve closed-loop control.

[0014] Through the above solution, this application can promptly increase redundancy and prioritize critical business flows when packet loss occurs, quickly reducing redundancy and freeing up bandwidth after network recovery. Furthermore, by combining node scoring and a fast switching mechanism, the exposure time of high-packet-loss links can be further reduced. This significantly improves the reliability and latency stability of game data transmission in cross-border high-packet-loss network environments, and increases overall bandwidth utilization.

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

[0016] Figure 1 FIG. 1 is a flow chart of a method for optimizing packet loss in a game accelerator based on traffic priority management provided by an embodiment of the present application. Figure 1As shown, the game accelerator packet loss optimization method based on traffic priority management may specifically include: S101, performing periodic link detection on at least one proxy node, obtaining packet loss rate, delay and jitter data of each monitoring period, and generating corresponding link monitoring results; S102: Determine, based on the link monitoring results, whether the packet loss rate for two consecutive monitoring periods exceeds a first threshold. If so, issue an activation instruction to the forward error correction encoder, select a corresponding redundancy ratio based on 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. S103, classifying the data stream to be sent in real time, obtaining priority labels for different traffic categories, and writing the source data packet and the redundant data packet into a packet header field containing the priority label; S104, inputting the prediction algorithm based on the link monitoring results to obtain a network quality prediction value for the next monitoring period, and adaptively adjusting the redundancy ratio, the sending queue bandwidth constraint parameter, and the proxy node according to the network quality prediction value; S105: Send the sorted source data packets and redundant data packets to the target game server or game client according to the updated proxy node to achieve accelerated forwarding of game data.

[0017] In some embodiments, periodic link detection is performed on at least one proxy node to obtain packet loss rate, latency, and jitter data for each monitoring period, and generate corresponding link monitoring results, including: In each monitoring cycle, a sequence of detection packets is sent to the target proxy node at a preset detection packet sending rate. Each detection packet in the detection packet sequence carries a link identifier, a monitoring cycle identifier, an increasing sequence number, and a sending timestamp. After receiving the receipt corresponding to the probe packet sequence, the number of received probe packets is compared with the number of sent probe packets based on the increasing 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 consecutive detection packets is counted through a sliding window to obtain the delay jitter corresponding to the current monitoring period; The packet loss rate, round-trip delay and delay jitter are written into the link monitoring result entry associated with the monitoring period, and the link monitoring result entry is stored in the local monitoring cache and / or reported to the control platform.

[0018] Specifically, in this embodiment, the client is equipped with a link detection module, a time synchronization module, and a monitoring result buffer. The link detection module is responsible for performing link quality detection on at least one overseas proxy node at a preset interval. This embodiment uses a 1-second monitoring interval, but in practice, it can be adjusted to other durations, such as 500ms or 2s, based on business needs.

[0019] First, at the beginning of each monitoring cycle, the link detection module preempts the sending right from the sending scheduling queue based on the detection packet sending rate. It 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 to the sending rate. For example, at a 100 pps configuration, one detection packet is generated and sent every 10,000 µs until the end of the cycle. Each detection packet contains the following fields: a link identifier, used to distinguish the current tunnel; a monitoring cycle identifier, used to identify the cycle sequence and correspond to subsequent result entries; an incrementing sequence number, used to determine packet loss; and a transmission timestamp, provided by a local monotonically increasing timer with a granularity of 10 µs.

[0020] Secondly, upon receiving a probe packet, the proxy node immediately generates a receipt and returns it along the same route. When receiving a response, the link detection module first parses the link identifier and monitoring cycle identifier, processing only receipts that match the current cycle. It then compares the increasing sequence numbers, counts the number of probe packets for which receipts have been received, and compares this with the number of probe packets sent in the current cycle to calculate the packet loss rate. For example, if 100 probe packets are sent in a cycle and only 92 receipts are received, the link detection module records the current packet loss rate as 8%.

[0021] Then, the link detection module calculates the round trip delay based on the difference between the sending timestamp and the receipt arrival time. s , the arrival timestamp is t r , then the round trip delay Δt=t r -t s The link detection module uses the sliding window method to collect statistics on the round-trip delay difference of consecutive detection packets in the same cycle. The window length can be configured to be 5 to 10 detection packets. In this embodiment, the window length is 6 detection packets. By calculating Δt i and Δt i-1 The absolute value of the difference between the two values is taken and the average is taken to obtain the delay jitter value j.

[0022] The link detection module then generates a link monitoring result entry. This entry includes three core metrics: monitoring period identifier, packet loss rate, round-trip delay, and delay jitter, as well as a generation timestamp and an optional prediction reference tag. The link monitoring result entry is first written to the local monitoring cache for subsequent prediction algorithm invocation. 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 via the control channel.

[0023] It's important to note that to reduce the impact of probing on service traffic, this embodiment lowers the priority of probe packets before they are added to the transmit queue: the DSCP tag of the probe packet is set to the lowest priority to ensure that game data packets are sent first. Furthermore, the time synchronization module performs a fast NTP calibration upon client startup and uses simplified PTP exchange messages every 30 seconds to perform fine-grained corrections to the latency measurement benchmark, ensuring monotonic consistency between the transmit and receive timestamps.

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

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

[0026] In some embodiments, forward error correction coding is performed on a game data packet to be sent to generate a redundant data packet corresponding to the source data packet, including: Sequentially collecting a preset number of source data packets in the sending buffer according to the current redundancy ratio to form an error correction group; Calling the forward error correction encoder to encode the error correction group using a preset forward error correction algorithm based on the redundancy ratio and the number of packets in the error correction group, thereby obtaining redundant data packets that correspond one-to-one to the source data packets; Write the error correction group identifier and incrementing sequence number for the source data packet and redundant data packet respectively, and retain the existing priority tag of the source data packet; The source data packet and the corresponding redundant data packet are synchronously output to the sending queue matching the priority label for subsequent transmission.

[0027] Specifically, in this embodiment, the client has a built-in forward error correction encoder, a sending buffer, and a multi-level sending queue. The current redundancy ratio is issued in real time by the link adaptation module, and directly determines the number of source data packets in the error correction group during the encoding stage. Taking a medium packet loss scenario as an example, when the redundancy ratio is set to 1:1, the forward error correction encoder will sequentially take out 4 source data packets from the sending buffer, arrange them in order, and generate a group of error correction groups with a length of 4. If the link monitoring results determine that the packet loss rate has increased and the redundancy ratio is adjusted to 1:1.5, the encoder will automatically expand the length of the error correction group, and a new error correction group can only be formed when 20 source data packets are accumulated.

[0028] Once the error correction group is assembled, the forward error correction encoder first reads the redundancy ratio and the number of packets in the group, then selects the corresponding preset forward error correction algorithm. For configurations with a redundancy ratio of no more than 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 packets that correspond one-to-one with the source packets. For configurations with a redundancy ratio greater than 1:1, the encoder uses a cascaded LDPC and ReedSolomon scheme, appending a short ReedSolomon check after the LDPC matrix encoding to improve resilience to burst packet loss.

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

[0030] The encoder then inserts each source data packet and its corresponding redundant data packet into a send queue matching the priority tag, in the order of "source packet immediately followed by redundant packet." For example, the control stream has the highest priority, and its corresponding send 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 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.

[0031] After obtaining sufficient tokens, the sending queue passes the data packet to the network interface module for encapsulation into the UDP tunnel and writing a local timestamp. After receiving the packet, the proxy node restores the grouping relationship based on the error correction group identifier and immediately initiates the decoding process when the number of source and redundant data packets in the group reaches the threshold specified by the encoder. If the number of missing data packets in the group does not exceed the redundancy capacity, the proxy node can restore the complete set of source data packets and forward them to the target game server in the original order. If decoding fails or the waiting timeout occurs, the proxy node generates a local packet loss alarm and transmits it back to the client along with the next link monitoring receipt, so that the link adaptation module can increase the redundancy ratio in the next cycle.

[0032] 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 ring buffer as the source packet input port, sharing data with the send buffer via a lock-free queue to avoid unnecessary delays caused by lock contention. A double-buffering strategy also ensures that source packet writing and redundant packet output do not block each other under high load. This ensures real-time encoding without impacting the normal execution of the game engine and other modules.

[0033] Through the above implementation method, this embodiment can quickly assemble error correction groups and dynamically adjust the redundancy ratio when the link packet loss increases. After the link is restored, it can promptly reduce the error correction group and reduce the redundancy overhead. In conjunction with the priority queue, it can realize hierarchical protection of different business flows, and overall improve the stability of game data transmission and bandwidth utilization in cross-border high packet loss network environments.

[0034] In some embodiments, classifying a data stream to be transmitted in real time, obtaining priority labels for different traffic categories, and writing a source data packet and a redundant data packet into a packet header field containing the priority label includes: Extract the five-tuple information of each data packet in the data stream to be sent and the payload segment of the preset length to generate the 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. Match priority labels to the identified results according to the pre-stored traffic class priority mapping table; 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 encoding process; The source data packet with the priority tag written therein and the corresponding redundant data packet are output to a sending queue associated with the priority tag.

[0035] Specifically, in this embodiment, the client is equipped 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, which uses a cascaded structure of a convolutional neural network and a time-series convolutional network to quickly identify 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 tag uses a 6-bit encoding, and the control flow, game logic flow, voice flow, video flow, and other traffic are mapped in descending order of weight.

[0036] First, the traffic classification module captures each packet entering the transmit buffer from the outgoing data stream. Upon capturing the packet, the module immediately extracts the five-tuple information: source address, destination address, source port, destination port, and transport layer protocol. It also extracts the first 64 bytes of the payload as the payload segment. These two pieces of data are vectorized and concatenated into a fixed-length traffic feature vector. To ensure efficient parallelization of feature extraction and packet processing, this embodiment uses a zero-copy approach to map payload segments directly from the ring buffer, eliminating the need for additional memory copying.

[0037] The generated traffic feature vector is then fed into the neural network within the traffic classification module. The model first uses multi-scale convolution kernels to extract spatial features, then uses a temporal convolutional network to mine local temporal dependencies. Finally, a set of category confidence values is output at the fully connected layer. The module uses the maximum confidence principle to classify packets as belonging to a specific traffic category, such as game logic flow category ID = 1. If the model confidence falls below a threshold, the module triggers a rapid fallback process, invoking port number-based emergency rules to supplement the classification results, thus preventing queue disruptions caused by classification failures.

[0038] 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, the game logic stream is mapped to the highest priority tag 0x3F, the voice stream is mapped to the second highest tag 0x2A, the video stream tag is 0x15, and the other traffic tag is 0x00. The module generates a priority tag based on the mapping result and appends it to the packet header extension field. To maintain consistency with the forward error correction process, the priority tag, error correction group identifier, and incremental sequence number are spliced in the memory in a preset order and written at one time to avoid repeated parsing.

[0039] After the packet header is written, the client scheduling module selects the corresponding send queue based on the priority tag. Control and game logic flows are placed in the queue with the highest token generation rate, voice flows are placed in a secondary queue, and video flows and other traffic flows are placed in a lower-rate queue. When the sending thread polls the queues, it always prioritizes the high-priority queue to ensure low latency for core game data. If both the source data packet and the corresponding redundant data packet exist in the queue, the scheduling module removes them sequentially in the order of "source packet followed by redundant packet" to maintain message order consistency within the error correction group.

[0040] To enhance the scalability of real-time classification, this embodiment also provides a cloud-based hot-update mechanism for models. When the cloud control platform pushes new models or mapping rules, the client-side traffic classification module activates a dual-model buffer, allowing the model to be replaced without interrupting packet processing. The replaced mapping table takes effect immediately, without requiring a client restart or interrupting the game session.

[0041] Through the above process, this embodiment can complete the real-time classification, priority label generation and packet header writing of data packets within microseconds, dynamically divert high-priority business flows and low-priority flows to different sending queues, and provide a granular and segmented traffic basis for subsequent bandwidth constraints and redundancy ratio control, thereby further ensuring the transmission stability and response speed of game data in a cross-border high-packet loss network environment.

[0042] In some embodiments, after writing the source data packet and the redundant data packet into the packet header field containing the priority tag, the method further comprises: According to the priority tag carried by each data packet, the table is looked up to determine the target sending queue ID, and the data packet is written to the corresponding sending queue; Initialize the token bucket counter for each send queue, configure the bucket capacity and token generation rate, where the token generation rate is determined by the priority tag and the network quality prediction value of the previous monitoring cycle; In the sending thread, poll each sending queue and check the current number of tokens in the corresponding token bucket. When the number of tokens 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 the same number of tokens, and then forward the data packet 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 value to keep consistent with the dynamic redundancy ratio and proxy node switching configuration.

[0043] Specifically, in this embodiment, the client internally presets four levels of send queues, Q0 to Q3, with descending priority levels. The scheduling module maintains a priority-queue mapping table, mapping priority tag 0x3F to Q0, 0x2A to Q1, 0x15 to Q2, and 0x00 to Q3. After completing the priority tag writing, the packet header write interface immediately reads the mapping table, generates the target send queue identifier, and records it in the local ring buffer along with the error correction group identifier and the incrementing sequence number. Based on this, the scheduling module calls the queue write function, sequentially inserting the source data packet and the corresponding redundant data packet into the tail of the corresponding queue, keeping messages in the same error correction group adjacent to each other in the queue.

[0044] During the queue initialization phase, the scheduling module configures a separate token bucket counter for each transmit queue. Bucket capacity C is set based on the principle of "higher priority, smaller capacity" to prevent a single queue from occupying the interface for extended periods. In this embodiment, the bucket capacities for Q0 through Q3 are set to 16K, 32K, 48K, and 64K bytes, respectively. The token generation rate R is determined by the priority weight and the predicted packet loss rate ρ from the previous monitoring cycle: R = α × W / (1 + β × ρ).

[0045] Where W is the priority weight, α is the total bandwidth coefficient, and β is the packet loss sensitivity coefficient. As ρ increases, the denominator 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 the rates of Q2 and Q3 are significantly reduced to ensure that critical business flows are prioritized.

[0046] The sending thread uses unconditional round-robin to traverse the four queue levels, checking the token bucket counters in the order Q0 → Q1 → Q2 → Q3. When the current token count in a queue is greater than or equal to the length of the first packet, the thread immediately removes the packet and deducts an equal number of tokens. It then calls the network interface module to fill the UDP tunnel message and stamp it with a local timestamp. If the current token count is insufficient, the thread skips that queue and continues checking the next queue level. After traversing all queues, it enters a short sleep (set to 25µs in this example) before initiating the next round of polling. This ensures that high-priority queues are served first when sufficient tokens are available, while also preventing low-priority flows from being starved of tokens due to queue occupancy.

[0047] At the end of each monitoring cycle, the link monitoring module writes the latest predicted network quality value ρ, ΔRTT, and other indicators into the shared status area. Upon receiving the update event, the scheduling module immediately calculates the new token generation rate R′ and compares it with the current R. When the difference exceeds the preset threshold of 3%, the token bucket module uses linear interpolation to gradually transition to the new rate over the next 100ms to avoid sudden bandwidth jitter. At the same time, if the link adaptation module has adjusted the redundancy ratio or switched proxy nodes, the scheduling module will simultaneously refresh the queue mapping table and update the bucket capacity C′ to ensure that the priority scheduling logic is consistent with the latest network environment.

[0048] To prevent extreme queue congestion, this embodiment also implements a saturation fallback mechanism: if any queue exceeds 2048 packets and has not been fully serviced for three consecutive polling cycles, the scheduling module temporarily increases the token bucket capacity of that queue by 50% and triggers a punitive token reduction for lower-priority queues until the high-priority queue length returns to below 1280 packets. This mechanism prioritizes bandwidth when sudden high packet loss on a link leads to a large increase in redundant packets, ensuring the continued availability of control and game logic flows.

[0049] Through the collaboration of the above-mentioned real-time queue mapping, token bucket rate control and dynamic fallback mechanism, this embodiment can complete bandwidth allocation updates within microseconds based on network quality prediction values and packet priority, enabling high-priority game data to obtain stable and sufficient transmission resources in cross-border high-packet loss environments, while avoiding link congestion and bandwidth waste caused by the surge in redundant data packets, thereby further improving the consistency and smoothness of the overall gaming experience.

[0050] In some embodiments, inputting the link monitoring results into a prediction algorithm to obtain a network quality prediction value for the next monitoring period includes: Aggregate the link monitoring results within the preset sliding window to form a data vector of packet loss rate, round-trip delay, and delay jitter arranged in time series; Perform weighted smoothing preprocessing on the data vector to obtain the denoised feature vector; The feature vector is input into the prediction algorithm. The prediction algorithm uses a state-space model with adaptive parameters to jointly predict the packet loss rate, round-trip delay, and delay jitter, and outputs the predicted packet loss rate, predicted round-trip delay, and predicted delay jitter corresponding to the next monitoring period. The predicted packet loss rate, predicted round-trip delay, and predicted delay jitter are encapsulated as network quality prediction values and written into the session state table.

[0051] Specifically, this embodiment deploys a prediction module within the client. The prediction module consists of a data buffer, a preprocessing unit, an adaptive state space prediction unit, and a result writing unit. After each monitoring cycle, the link monitoring module writes the latest link monitoring result entry into the data buffer. The data buffer stores a fixed number of entries in a ring structure. This embodiment uses a sliding window of length 12, caching the packet loss rate, round-trip delay, and delay jitter data for the last 12 monitoring cycles.

[0052] When the sliding window is filled or updated, the preprocessing unit immediately reads the three 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 based on the variance of the packet loss rate within the window: when the variance increases, λ is reduced to increase the smoothing weight; when the variance decreases, λ is increased to improve model sensitivity. After smoothing, a denoised feature vector is obtained and written into the adaptive state space prediction unit.

[0053] The adaptive state-space prediction unit implements a Kalman filter with adjustable parameters. The filter continuously maintains the system state vector and covariance matrix. The initial values are set through a quick self-test at client startup. Subsequently, a state update and a time prediction are performed each time a new feature vector is received. To balance the 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 within the sliding window exceeds a threshold, Q is appropriately increased and R is decreased to improve the model's response to sudden packet loss; otherwise, the reverse adjustment is made to achieve a smoother prediction. After the update is completed, the prediction unit outputs the predicted packet loss rate, predicted round-trip delay, and predicted delay jitter for the next monitoring period.

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

[0055] Through the above implementation, this embodiment can perform a joint prediction of link packet loss rate, round-trip delay, and delay jitter locally on the client based on a limited number of monitoring items, maintaining model robustness through adaptive covariance adjustment. The prediction results are promptly written to the session state table, providing a reliable reference for downstream bandwidth allocation and redundancy control. This can proactively mitigate the impact of link degradation on game data transmission in cross-border high-packet-loss environments.

[0056] In some embodiments, adaptively adjusting the redundancy ratio, the transmission queue bandwidth constraint parameter, and the proxy node according to the network quality prediction value includes: Quantization mapping is performed on the predicted packet loss rate, predicted round-trip delay, 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; According to the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented increment rule to generate the target redundancy ratio, and 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 proportionally adjusted to update the bandwidth constraint parameters; Comprehensively score the candidate proxy nodes according to the node scoring weight and determine the target proxy node; While maintaining existing communications, 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.

[0057] Specifically, the link monitoring and prediction module outputs three indicators: the predicted packet loss rate ρ, the predicted round-trip delay τ, and the predicted delay jitter j. The adaptive module first classifies these three indicators: When ρ<3%, it is classified as gear A, 3%≤ρ<10% is classified as gear B, 10%≤ρ<20% is classified as gear C, and ρ≥20% is classified as gear D.

[0058] The benchmark for predicting round-trip delay is the historical stable delay τ0. For example, if τ0 = 100 milliseconds, when |τ - τ0| ≤ 20% × τ0, it is classified as level A. When it exceeds 20% but does not exceed 50%, it is classified as level B. When it exceeds 50% but does not exceed 100%, it is classified as level C. When it exceeds 100%, it is classified as level D.

[0059] The delay jitter classification is similar to the round-trip delay, and the benchmark is the historical jitter average j0.

[0060] Furthermore, after the binning is completed, the module generates three internal factors: The redundant proportional adjustment factor Fρ is determined only by the ρ gear position; The bandwidth constraint adjustment factor Fb depends on the larger gear among τ and j; The node scoring weight matrix W refers to the three gears at the same time, and the weight order is packet loss > delay > jitter.

[0061] Furthermore, the system's initial redundancy ratio is set to 1:1 (i.e., one source packet is matched with one redundant packet). When Fρ changes, the ratio is corrected using the segmented incremental rule: When the ρ gear is A and the current redundancy ratio is greater than 0, it is immediately reduced to 0 redundancy; When the ρ gear is in B, adjust the ratio to 1:0.5; When the ρ gear is in C, adjust it to 1:1; When the ρ gear is in D, adjust it to 1:1.5.

[0062] The correction results generate a target redundancy ratio control instruction, which is sent to the forward error correction encoder via the shared memory channel. The encoder switches to the new ratio after processing the current error correction group, ensuring that the boundaries between groups are consistent.

[0063] Furthermore, the client sets up four levels of send queues, Q0 through Q3, with the highest priority corresponding to control flow, game logic flow, voice flow, video flow, and other flows. Each queue level is associated with a token bucket (capacity C and rate R). Example initialization values are: Q0 (C=16K, R=40Mbps), Q1 (C=32K, R=30Mbps), Q2 (C=48K, R=20Mbps), and Q3 (C=64K, R=10Mbps).

[0064] In some examples, when Fb indicates that the link is becoming more congested (level C or D), the adaptation module proportionally reduces the rate of the low-priority queue: In gear C, keep the Q0 rate unchanged, reduce Q1 by 20%, Q2 by 40%, and Q3 by 50%; In gear D, Q1, Q2, and Q3 are each reduced by an additional 10%.

[0065] When Fb indicates that the link is stable (position A or B), the rate is increased proportionally until the initial configuration is restored. Bucket capacity adjustment is scaled to the same rate, with a smooth transition in five short steps of 20 milliseconds per step.

[0066] Furthermore, the client maintains a maximum of five connectable proxy nodes, each of which maintains real-time metrics: packet loss rate ρn, average latency τn, jitter jn, real-time load Ln, and cost Fn. A typical configuration example for the node scoring weight matrix W is: when ρ is in gear D, the weight ratio is ρ:τ:j:L:F = 5:2:1:1:1; when ρ is in gear A, the weight ratio drops to 3:3:2:1:1.

[0067] The comprehensive score Sn is the sum of the five standardized indicators multiplied by their corresponding weights. A higher score indicates a better result. If the highest-scoring node T scores higher than the current node by a threshold value of ΔS (ΔS = 8 points in this example), and the current node's lock period has expired, the adaptive module sets T as the target proxy node and starts preheating the backup tunnel: Initiate handshake verification handshake delay < 200 milliseconds; Send 100 consecutive probe packets to verify that ρ<5% and τ is equal to or lower than the current node; Maintain the backup tunnel heartbeat for 20 seconds. If there is no abnormality during this period, the switching conditions are met.

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

[0069] In some examples, this embodiment also includes closed-loop protection and anti-shake design, the details of which are as follows: Gear change anti-shake: The gear of the same indicator must maintain at least one complete monitoring cycle (1 second) before it is allowed to change again.

[0070] Parameter adjustment threshold: The redundancy ratio cross-gear adjustment must change by ≥0.5. Bandwidth parameter adjustment is not triggered when the difference between the new and old values is <3%.

[0071] Node lock and switch protection: Each node is locked for 50 seconds after switching, and no new switch will be triggered during this period.

[0072] Overload fallback: If the length of any queue is greater than 2048 packets and does not decrease for three consecutive polling cycles (about 75 microseconds), the bucket capacity of the queue is increased by 50%, and the tokens of the low-priority queue are deducted by 20% until the length drops below 1280 packets.

[0073] In a specific example, in a test environment, a client connected to an overseas node. Initially, the packet loss rate was 2%, the round-trip latency was 95 milliseconds, and the jitter was 6 milliseconds, corresponding to gear A. The redundancy ratio was 0, and the queue rate was at the initial configuration. A few minutes later, link jitter and a slight increase in packet loss occurred: ρ = 8% (gear B), τ = 110 milliseconds (gear B), and j = 9 milliseconds (gear B). The module adjusted the redundancy ratio to 1:0.5 according to the rules, and simultaneously reduced the rates of Q1, Q2, and Q3 by 20% in sequence. Five seconds later, the link suddenly experienced a high packet loss of 50% and a doubling of latency: ρ = 25% (gear D), τ = 210 milliseconds (gear D), and j = 18 milliseconds (gear C). The redundancy ratio was immediately increased to 1:1.5, and low-priority rates were further compressed, while high-priority rates were maintained. The node score showed that the backup node S scored 12 points higher than the incumbent node. The module preheated the backup tunnel and completed the switch in the next error correction group. Subsequently, link quality returned to 4% packet loss and 120 milliseconds latency. The system automatically reset the redundancy ratio to 1:0.5 and gradually released low-priority packets. Throughout the entire process, the game session experienced no noticeable lag; the average frame synchronization delay was kept below 200 milliseconds, and no more than two high-priority packets were lost in a row.

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

[0075] In some embodiments, after adaptively adjusting the redundancy ratio, the sending queue bandwidth constraint parameter, and the proxy node according to the network quality prediction value, the method further includes: When the packet loss rate of three consecutive monitoring cycles does not exceed the second threshold, a revocation instruction is sent to the forward error correction encoder to stop generating redundant data packets while maintaining the priority label and the sending queue configuration.

[0076] Specifically, after the above-mentioned adaptive adjustment is completed, the client continues to perform link monitoring, and each time a monitoring cycle ends, the link monitoring module will write the packet loss rate of this cycle into the ring status buffer. In order to ensure that the operation of revoking forward error correction is safe and reliable, this embodiment introduces a "continuous stability window" judgment mechanism: the client maintains a recent packet loss rate list L=[ρ1, ρ2, ρ3] of length 3, corresponding to the last 3 monitoring cycles in sequence; when a new monitoring result ρnew appears, the list is shifted right in chronological order and the oldest data is discarded, and ρnew is placed at the beginning. The adaptive module immediately checks whether all elements in L are less than or equal to the second threshold ρ2 after each update. The second threshold is set to 1% in this embodiment and can be configured within the range of 0%~3% according to business needs.

[0077] If L satisfies the condition that all L values are less than or equal to ρ2, it means that the link has maintained low packet loss for three consecutive cycles and the redundant coding can be safely removed. At this time, the adaptive module performs the following steps: The module then constructs a "redundancy disable" control frame. The frame header includes a revocation flag and a timestamp, tstop, to signal the forward error correction encoder to stop generating redundant data packets. To prevent control frames from being discarded on the network, the client sends three identical control frames in succession and sets a local confirmation timer, waiting for the encoder to return a confirmation notification. If no confirmation is received within three seconds, the module resends the control frame and issues an alarm log.

[0078] Upon receiving the revocation command, the FEC encoder first completes encoding and transmission of the current error correction group. It then clears its internal error correction group buffer and resets the group's sequence number counter to 0 to ensure that there will be no conflict with the old sequence number when redundancy is re-enabled. After completing these operations, the encoder returns a confirmation message containing the revocation effective timestamp, tclear.

[0079] After redundancy is removed, the traffic classification module continues to write priority tags to newly generated source packets according to the original process. The token bucket rate and bucket capacity of the send queue remain at the latest configuration before the removal, and are not immediately increased due to the loss of redundancy. This prevents sudden bandwidth increases and data spikes. If subsequent forecast indicators indicate that the network remains stable, the bandwidth constraint control submodule will gradually reduce the rates of low-priority queues over a regular period, restoring them to the recommended values for a stable link state.

[0080] To prevent redundancy from being repeatedly started and stopped due to minor link fluctuations, this embodiment sets a "silent observation period" of Tobs = 2 seconds after revocation. Even if the packet loss rate exceeds ρ2 even once during the silent period, redundancy is not immediately restarted. Instead, the process waits for the observation period to end and then reenters the normal determination process. If the packet loss rate still exceeds ρ2 during any monitoring period after the silent observation period, the counter is immediately reset to zero and the Fρ determination process reenters.

[0081] The adaptation module writes the revocation event to the session state table as a "session configuration update" entry. This entry includes the revocation start time tstop, the revocation confirmation time tclear, the revocation reason code (continuous low packet loss), and the redundancy ratio 0 that takes effect after the revocation. This entry is synchronously written to the local log file and reported the next time Telemetry is sent to the cloud control platform, allowing the cloud-side scheduler to collect statistics on client adaptation.

[0082] After the revocation takes effect, the adaptive module continues to collect link monitoring results and inputs them into the prediction algorithm. If subsequent network quality predictions again indicate that the packet loss rate has risen to B or higher, the module immediately restarts the previously described redundancy ratio increase process. To prevent frequent oscillations, the system requires that at least one complete error correction group be encoded after redundancy is enabled before re-evaluating the revocation condition.

[0083] Through the above-mentioned revocation mechanism, this embodiment ensures that the activation and deactivation of forward error correction are based on continuous, multi-cycle stability indicators, avoiding unnecessary redundancy or premature revocation due to instantaneous data fluctuations; at the same time, through the silent observation period and log backtracking capabilities, it provides a traceable basis 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.

[0084] 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: Establish and maintain a transmission tunnel with the updated proxy node; Taking out the sorted source data packets and redundant data packets from each sending queue in order of priority of the sending queue; Writing the proxy node identifier, error correction group identifier, incrementing sequence number, and priority tag into the forwarding headers of the source data packet and the redundant data packet; Forwarding the source data packet and the redundant data packet 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.

[0085] Specifically, in this embodiment, the client has determined the target proxy node T through the adaptive module and completed the tunnel warm-up. Subsequently, it enters the formal data forwarding stage, and the specific process is as follows.

[0086] The client uses the UDP-based multiplexing tunnel protocol to establish a session with node T. The handshake packet contains the client random number, the list of supported cipher suites, and the session identifier SID. Node T returns a handshake confirmation and negotiates the session key. If the handshake round-trip delay is less than 180 milliseconds, it is determined to be 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. After receiving it, node T immediately returns a confirmation receipt, and both parties maintain a consecutive non-receipt counter cnt. When cnt ≥ 3, it is regarded as a tunnel failure, and the client immediately falls back to the backup path and reports an exception.

[0087] The client scheduling thread polls in the order of the priority queue Q0 → Q1 → Q2 → Q3. If the token bucket permits, it takes the head packet from 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 taken, its error correction group identifier IDg is immediately read, and packets are continuously taken until IDg changes or the number of packets in the group reaches the upper limit, ensuring that packets in the same group are arranged continuously. The size of buffer B is fixed at 256 packets, and when it is full or reaches a 5-millisecond timeout, it triggers a transmission batch.

[0088] The sending thread traverses buffer B and performs header writing for each source packet and its corresponding redundant packet: Proxy node identifier IDn: 4 bytes, using the hash abbreviation of node T; Error correction group identifier IDg: 2 bytes; Incremental sequence number SN: 4 bytes, incrementing separately in the source and redundant packets; Priority label PL: 1 byte, corresponding to the mapping values of Q0~Q3.

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

[0090] The client configures a rate-based transmitter 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 taken 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 the 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 packet loss inference.

[0091] Node T listens to the tunnel corresponding to the SID in the worker thread pool. Upon receiving a client data packet, it first checks if IDn matches the SID, then resolves IDg and SN to restore the error correction group association and writes the packet to the group cache Cg. The capacity of each group cache dynamically adjusts with the redundancy ratio. For example, at a 1:1 ratio, each group can accept a maximum of 8 packets. Decoding is triggered when Cg reaches the group capacity or times out by 10 milliseconds. When the number of source packet losses 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, the packet is immediately marked as a failure and the packet loss statistics are recorded. Successfully decoded source packets are written to the reordering buffer R in ascending SN order.

[0092] Node T performs traffic classification mapping on the reordering buffer R, determines the internal scheduling order based on the PL priority, and uses a hybrid token bucket and WFQ algorithm to control the egress rate to the target game server or game client, ensuring that high-priority packets are prioritized. 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.

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

[0094] If node T reports a decoding failure rate > 30% for three consecutive seconds or loses heartbeat connection, the client immediately triggers the fast node switching process: Select the suboptimal node S2 from the candidate node list; Start S2 tunnel preheating and smoothly migrate the sending pointer; After two sets of error correction are completed, the T tunnel is disconnected.

[0095] Switching events are recorded in the log and synchronized to the cloud control platform. To prevent frequent switching, the system sets a 50-second lock period for the same node, during which it will no longer be evaluated as a candidate.

[0096] The results of the implementation demonstrate that, in a test scenario with an average cross-border link packet loss rate of 10% and a latency of 180 milliseconds, the aforementioned process can control the final end-to-end packet loss rate to less than 0.8%, increase the average logical flow latency by no more than 25 milliseconds, and no game interruptions or large-scale rollbacks are observed during tunnel switching. This implementation further demonstrates that the coordinated implementation of ordered packetization, priority offloading, and edge decoding can significantly improve the reliability and stability of real-time game data transmission in cross-border high-packet-loss environments.

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

[0098] Figure 2 Schematic diagram of the structure of the game accelerator packet loss optimization device based on traffic priority management provided by the embodiment of the present application. Figure 2 As shown, the game accelerator packet loss optimization device based on traffic priority management includes: The detection module 201 is used to perform periodic link detection on at least one proxy node, obtain the packet loss rate, delay and jitter data of each monitoring period, and generate corresponding link monitoring results; The error correction module 202 is configured to determine, based on the link monitoring results, whether the packet loss rate for two consecutive monitoring periods exceeds a first threshold. If so, it issues an activation instruction to the forward error correction encoder, selects a corresponding redundancy ratio based on the packet loss rate range, performs forward error correction encoding on the game data packet to be sent, and generates a redundant data packet corresponding to the source data packet. The classification module 203 is used to classify the data flow to be sent in real time, obtain priority labels for different traffic categories, and write the source data packet and the redundant data packet into the packet header field containing the priority label; Adjustment module 204, 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, the transmission queue bandwidth constraint parameter, and the proxy node according to the network quality prediction value; 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 to achieve accelerated forwarding of game data.

[0099] In some embodiments, Figure 2 The detection module 201 sends a detection packet sequence to the target proxy node at a preset detection packet sending rate within each monitoring cycle. Each detection packet in the detection packet sequence carries a link identifier, a monitoring cycle identifier, an increasing sequence number, and a sending timestamp. After receiving the receipt corresponding to the detection packet sequence, the number of received detection packets is compared with the number of sent detection packets based on the increasing sequence number to calculate the packet loss rate of the current monitoring cycle. The round-trip delay is calculated based on the sending timestamp and the receipt arrival time, and the delay difference of consecutive detection packets is counted through a sliding window to obtain the delay jitter corresponding to the current monitoring cycle. The packet loss rate, round-trip delay, and delay jitter are written into the link monitoring result entry associated with the monitoring cycle, and the link monitoring result entry is stored in the local monitoring cache and / or reported to the control platform.

[0100] In some embodiments, Figure 2The error correction module 202 sequentially collects a preset number of source data packets in the sending buffer according to the current redundancy ratio to form an error correction group; calls the forward error correction encoder, and uses a preset forward error correction algorithm to encode the error correction group 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; writes the error correction group identifier and the increasing sequence number for the source data packet and the redundant data packet respectively, and retains the existing priority label of the source data packet; and synchronously outputs the source data packet and the corresponding redundant data packet to the sending queue that matches the priority label for subsequent transmission.

[0101] In some embodiments, Figure 2 The classification module 203 extracts the five-tuple information of each data packet in the data stream to be sent and the load segment of the preset length, and generates a corresponding traffic feature vector; inputs the traffic feature vector into the traffic classification module, and determines the traffic category to which the data packet belongs through a deep packet inspection algorithm or a traffic identification model based on machine learning; matches the priority label for the determination result according to the pre-stored traffic category priority mapping table; calls the packet header writing interface, writes the priority label into the reserved packet header field, and retains the error correction group identifier and serial number added during the forward error correction encoding process; outputs the source data packet after the priority label is written and the corresponding redundant data packet to the sending queue associated with the priority label.

[0102] In some embodiments, Figure 2 The detection module 206 is used to determine the target sending queue identifier by looking up the table according to the priority label carried by each data packet after writing the source data packet and the redundant data packet into the packet header field containing the priority label, and write the data packet into the corresponding sending queue; initialize the token bucket counter for each sending queue, configure the bucket capacity and token generation rate, wherein the token generation rate is determined jointly by the priority label and the network quality prediction value of the previous monitoring cycle; in the sending thread, poll each sending queue, detect the current number of tokens in the corresponding token bucket, and when the token number 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 number of tokens, and then transfer the data packet to the network interface; at the end of each monitoring cycle, adaptively adjust the token generation rate and bucket capacity parameters of each token bucket based on the updated network quality prediction value to be consistent with the dynamic redundancy ratio and the proxy node switching configuration.

[0103] In some embodiments, Figure 2The adjustment module 204 aggregates the link monitoring results within the preset sliding window to form a data vector of packet loss rate, round-trip delay and delay jitter arranged in time series; performs weighted smoothing preprocessing on the data vector to obtain a denoised feature vector; inputs the feature vector into the prediction algorithm, and the prediction algorithm jointly predicts the packet loss rate, round-trip delay and delay jitter based on a state space model with adaptive parameter adjustment, and outputs the predicted packet loss rate, predicted round-trip delay and predicted delay jitter corresponding to the next monitoring period; encapsulates the predicted packet loss rate, predicted round-trip delay and predicted delay jitter as network quality prediction values and writes them into the session state table.

[0104] In some embodiments, Figure 2 The adjustment module 204 performs quantitative mapping on the predicted packet loss rate, predicted round-trip delay, and predicted delay jitter in the network quality prediction value, respectively, to obtain a redundancy ratio adjustment factor, a bandwidth constraint adjustment factor, and a node score weight; based on the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented increment rule to generate a 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 proportionally adjusted to update the bandwidth constraint parameters; the candidate proxy nodes are comprehensively scored according to the node score weight to determine the target proxy node; while maintaining existing communications, 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.

[0105] In some embodiments, Figure 2 After the adjustment module 204 adaptively adjusts the redundancy ratio, the sending queue bandwidth constraint parameter and the proxy node according to the network quality prediction value, when the packet loss rate of three consecutive monitoring cycles does not exceed the second threshold, a revocation instruction is sent to the forward error correction encoder to stop generating redundant data packets, while maintaining the priority label and the sending queue configuration.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for optimizing packet loss of a game accelerator based on traffic priority management, characterized in that: include: Perform periodic link detection on at least one proxy node, obtain packet loss rate, delay and jitter data of each monitoring period, and generate corresponding link monitoring results; Determining whether the packet loss rate of two consecutive monitoring cycles exceeds a first threshold value based on the link monitoring result, and if so, issuing an activation instruction to a forward error correction encoder, selecting a corresponding redundancy ratio based on the packet loss rate interval, performing forward error correction encoding on the game data packet to be sent, and generating a redundant data packet corresponding to the source data packet; Classifying the data stream to be sent in real time, obtaining priority labels for different traffic categories, and writing the source data packet and the redundant data packet into a packet header field containing the priority label; Inputting the prediction algorithm based on the link monitoring results 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; The sorted source data packets and redundant data packets are sent to the target game server or game client according to the updated proxy node to achieve accelerated forwarding of game data.

2. The method according to claim 1, characterized in that The performing periodic link detection on at least one proxy node, obtaining packet loss rate, delay and jitter data of each monitoring period, and generating corresponding link monitoring results includes: In each monitoring cycle, a sequence of detection packets is sent to the target proxy node at a preset detection packet sending rate, wherein each detection packet in the detection packet sequence carries a link identifier, a monitoring cycle identifier, an increasing sequence number, and a sending timestamp; After receiving the receipt corresponding to the detection packet sequence, comparing the number of detection packets for which receipts have been received with the number of detection packets sent based on the incrementing sequence number, and calculating the packet loss rate of the current monitoring period; The round-trip delay is calculated based on the sending timestamp and the receipt arrival time, and the delay difference of consecutive detection packets is counted through a sliding window to obtain the delay jitter corresponding to the current monitoring period; The packet loss rate, round-trip delay and delay jitter are written into the link monitoring result entry associated with the monitoring period, and the link monitoring result entry is stored in the local monitoring cache and / or reported to the control platform.

3. The method according to claim 1, characterized in that The forward error correction coding of the game data packet to be sent to generate a redundant data packet corresponding to the source data packet includes: Sequentially collecting a preset number of source data packets in the sending buffer according to the current redundancy ratio to form an error correction group; Invoking a forward error correction encoder to encode the error correction group 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 to the source data packets; Writing an error correction group identifier and an increasing sequence number into the source data packet and the redundant data packet, respectively, and retaining the existing priority tag of the source data packet; The source data packet and the corresponding redundant data packet are synchronously output to a sending queue that matches the priority tag for subsequent sending.

4. The method according to claim 1, wherein The method of classifying the data stream to be sent in real time, obtaining priority labels for different traffic categories, and writing the source data packet and the redundant data packet into a packet header field containing the priority label includes: Extracting the five-tuple information and the payload segment of the preset length of each data packet in the data stream to be sent, and generating a corresponding traffic feature vector; Inputting the traffic feature vector into a traffic classification module, and determining the traffic category to which the data packet belongs through a deep packet inspection algorithm or a traffic identification model based on machine learning; Match priority labels to the identified results according to the pre-stored traffic class priority mapping table; Calling the packet header writing interface to write the priority tag into the reserved packet header field, and retaining the error correction group identifier and sequence number added during the forward error correction encoding process; The source data packet with the priority tag written therein and the corresponding redundant data packet are output to a sending queue associated with the priority tag.

5. The method according to claim 1, wherein After writing the source data packet and the redundant data packet into the packet header field containing the priority tag, the method further includes: According to the priority tag carried by each data packet, a table is looked up to determine the target sending queue identifier, and the data packet is written into the corresponding sending queue; Initializing a token bucket counter for each sending queue, configuring a bucket capacity and a token generation rate, wherein the token generation rate is determined based on the priority tag and a network quality prediction value from a previous monitoring period; In the sending thread, poll each sending queue and detect the current number of tokens in the corresponding token bucket. When the number of tokens 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 number of tokens, and then forward the data packet 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 value to keep consistent with the dynamic redundancy ratio and proxy node switching configuration.

6. The method according to claim 1, characterized in that The step of inputting the link monitoring result into a prediction algorithm to obtain a network quality prediction value for the next monitoring period includes: Aggregate the link monitoring results within the preset sliding window to form a data vector of packet loss rate, round-trip delay, and delay jitter arranged in time series; Performing weighted smoothing preprocessing on the data vector to obtain a denoised feature vector; Inputting the feature vector into a prediction algorithm, the prediction algorithm jointly predicts the packet loss rate, round-trip delay, and delay jitter based on a state-space model with adaptive parameter adjustment, and outputs the predicted packet loss rate, predicted round-trip delay, and predicted delay jitter corresponding to the next monitoring period; The predicted packet loss rate, predicted round-trip delay and predicted delay jitter are encapsulated as a network quality prediction value and written into a session state table.

7. The method according to claim 5, characterized in that The adaptively adjusting the redundancy ratio, the sending queue bandwidth constraint parameter, and the proxy node according to the network quality prediction value includes: Performing quantization mapping on the predicted packet loss rate, predicted round-trip delay, and predicted delay jitter in the network quality prediction value to obtain a redundancy ratio adjustment factor, a bandwidth constraint adjustment factor, and a node scoring weight; According to the redundancy ratio adjustment factor, the current redundancy ratio is corrected according to the segmented increment rule to generate a target redundancy ratio, and the target redundancy ratio is sent to the forward error correction encoder; According to the bandwidth constraint adjustment factor, the token generation rate and bucket capacity of the token bucket corresponding to each sending queue are proportionally adjusted to update the bandwidth constraint parameter; Comprehensively score the candidate proxy nodes according to the node scoring weights to determine the target proxy node; While maintaining the 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.

8. The method according to claim 1, characterized in that After adaptively adjusting the redundancy ratio, the sending queue bandwidth constraint parameter, and the proxy node according to the network quality prediction value, the method further includes: When the packet loss rate of three consecutive monitoring cycles does not exceed the second threshold, a revocation instruction is sent to the forward error correction encoder to stop generating redundant data packets, while maintaining the priority label and sending queue configuration.

9. 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 node includes: Establishing and maintaining a transmission tunnel with the updated proxy node; Taking out the sorted source data packets and redundant data packets from each sending queue in order of priority of the sending queue; Writing a proxy node identifier, an error correction group identifier, an increasing sequence number, and a priority tag into forwarding headers of the source data packet and the redundant data packet; forwarding the source data packet and the redundant data packet to a 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.

10. A game accelerator packet loss optimization device based on traffic priority management, characterized in that: include: A detection module is used to perform periodic link detection on at least one proxy node, obtain packet loss rate, delay and jitter data of each monitoring period, and generate corresponding link monitoring results; an error correction module, configured to determine, based on the link monitoring result, whether the packet loss rate of two consecutive monitoring cycles exceeds a first threshold; if so, to issue an activation instruction to a forward error correction encoder, select a corresponding redundancy ratio based on the packet loss rate interval, 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; 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 packet and the redundant data packet into a packet header field containing the priority label; An adjustment module is configured to input a prediction algorithm based on the link monitoring result to obtain a network quality prediction value for the next monitoring period, and adaptively adjust the redundancy ratio, the sending queue bandwidth constraint parameter, and the proxy node 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 to achieve accelerated forwarding of game data.

Images