Server node selection method for game rooms

Abstract

The application discloses a server node selection method of a game room, and the method comprises the following steps: in response to a room creation request of a player, obtaining network quality data of the player at each candidate node, and determining overall network quality of all players at the corresponding candidate node; determining a delay tolerance threshold corresponding to the room request; selecting a minimum value in the overall network quality, and eliminating the candidate node corresponding to the minimum value in the case that the minimum value is greater than the delay tolerance threshold, to obtain an intermediate node; determining a comprehensive generation cost corresponding to the intermediate node based on the overall network quality data and a server load index corresponding to the intermediate node, and selecting the intermediate node corresponding to the minimum comprehensive generation cost as the server node of the game room. The embodiment of the application can improve the stability of the distributed game room node selection and the overall interactive experience of the user.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of game technology, and in particular to a method for selecting server nodes in a game room. Background Technology

[0002] In distributed online multiplayer games and player-generated content platforms, the system needs to allocate suitable server nodes to newly created game rooms. Currently, common server node selection methods often employ the principle of minimizing the average latency of all players within the group or allocating nodes based on geographical proximity. These methods primarily aim to optimize overall or average network metrics. However, they lack network fairness (i.e., the "weakest link" effect). That is, in a multiplayer battle scenario with strong consistency and synchronization, even if the average latency of players in the room is low, if any individual player experiences excessively high latency to the target node, that player's high latency (such as timeout retransmission or packet loss) will trigger anomalies in the state synchronization of the entire room. This leads to a decline in the interactive experience for all participants in the room, undermining the fairness of multiplayer battles. Therefore, methods that only optimize average latency are insufficient to guarantee a basic level of network experience for every player in the room. Summary of the Invention

[0003] This application provides a method for selecting server nodes in a game room, which can improve the stability of distributed game room node selection and the overall user interaction experience.

[0004] In a first aspect, embodiments of this application provide a method for selecting server nodes in a game room, applied to a backend control system, the method comprising: In response to a player's request to create a room, obtain the player's network quality data at each candidate node, and determine the overall network quality of all players at the corresponding candidate node; Determine the latency tolerance threshold corresponding to the room request; The minimum value is selected from the overall network quality. If the minimum value is greater than the latency tolerance threshold, the candidate node corresponding to the minimum value is removed to obtain the intermediate node. Based on the overall network quality data and server load indicators corresponding to the intermediate node, the comprehensive value of the intermediate node is determined, and the intermediate node with the smallest comprehensive value is selected as the server node of the game room.

[0005] Secondly, a server node selection device for a game room according to an embodiment of this application is applied to a backend control system, the device comprising: A preprocessing module is used to respond to a player's request to create a room, obtain the player's network quality data at each candidate node, and determine the overall network quality of all players at the corresponding candidate node; A first calculation module is used to determine the latency tolerance threshold corresponding to the room request; The second calculation module is used to select the minimum value in the overall network quality, and when the minimum value is greater than the latency tolerance threshold, remove the candidate node corresponding to the minimum value to obtain the intermediate node. The selection module is used to determine the comprehensive value of the intermediate node based on the overall network quality data and server load index corresponding to the intermediate node, and select the intermediate node with the smallest comprehensive value as the server node of the game room.

[0006] Thirdly, an electronic device provided according to an embodiment of this application includes: At least one processor; At least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the server node selection method for the game room according to any one of the first aspects is implemented.

[0007] Fourthly, according to the embodiments of the application, a computer-readable storage medium is provided, storing computer-executable instructions, which are used to execute the server node selection method for the game room as described in any of the first aspects.

[0008] In summary, the server node selection method for game rooms according to the above embodiments of this application includes: responding to a player's request to create a room, obtaining the player's network quality data at each candidate node, and determining the overall network quality of all players at the corresponding candidate nodes; determining the latency tolerance threshold corresponding to the room request; selecting the minimum value from the overall network quality; if the minimum value is greater than the latency tolerance threshold, eliminating the candidate node corresponding to the minimum value to obtain an intermediate node; determining the comprehensive cost value corresponding to the intermediate node based on the overall network quality data and server load indicators corresponding to the intermediate node, and selecting the intermediate node corresponding to the minimum comprehensive cost value as the server node of the game room. This embodiment of the application, by determining the overall network quality of all players at each candidate node and selecting the minimum value, compares this minimum value with a dynamically determined latency tolerance threshold. It focuses on the network condition of the worst individual player at each node. When the worst condition exceeds the threshold, the node is eliminated. This establishes network fairness constraints from the scheduling source, fundamentally preventing the "weakest link" effect—where a few players' network lag disrupts the fairness of the entire room's battles. By calculating the comprehensive cost value and selecting the best option, the optimization objective of node selection is expanded from a single network latency to a multi-dimensional index that includes network stability and server resource utilization. This avoids the risk of uneven server load or overload that may result from only pursuing the optimal average latency, and achieves the optimal scheduling of overall resources while ensuring individual fairness. This significantly improves the stability of node selection in distributed game rooms and the overall user interaction experience. Attached Figure Description

[0009] Figure 1 This is a flowchart of the steps of a method for selecting a server node in a game room according to an embodiment of this application; Figure 2 This application provides an architecture diagram of a server node selection method for game rooms according to one embodiment; Figure 3 This is a flowchart illustrating a method for selecting server nodes in a game room according to an embodiment of this application; Figure 4 This is a hardware schematic diagram of an electronic device provided in one embodiment of this application. Detailed Implementation

[0010] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0011] It is understandable that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, or the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0012] In distributed online multiplayer games and player-generated content platforms, the system needs to allocate suitable server nodes to newly created game rooms. Currently, common server node selection methods often employ the principle of minimizing the average latency of all players within the group or allocating nodes based on geographical proximity. These methods primarily aim to optimize overall or average network metrics. However, they lack network fairness (i.e., the "weakest link" effect). That is, in a multiplayer battle scenario with strong consistency and synchronization, even if the average latency of players in the room is low, if any individual player experiences excessively high latency to the target node, that player's high latency (such as timeout retransmission or packet loss) will trigger anomalies in the state synchronization of the entire room. This leads to a decline in the interactive experience for all participants in the room, undermining the fairness of multiplayer battles. Therefore, methods that only optimize average latency are insufficient to guarantee a basic level of network experience for every player in the room.

[0013] Based on this, the embodiments of this application provide a method for selecting server nodes in a game room, which can improve the stability of distributed game room node selection and the overall user interaction experience.

[0014] This application provides a method for selecting server nodes in a game room, applied to a backend control system, as described above. Figure 1 , Figure 2 as well as Figure 3 As shown, the method includes, but is not limited to, the following steps: Step S100: In response to a player's request to create a room, obtain the player's network quality data at each candidate node, and determine the overall network quality of all players at the corresponding candidate nodes; When multiple players are preparing to enter the same game room and initiate online play, the game client sends a room creation request to the backend control system. This request retrieves server nodes on the current platform that can provide concurrent resource scheduling as candidate nodes. The network quality data is obtained by measuring the network connection status between the player's client and the server node, which is used for subsequent screening and evaluation. At the same time, for each candidate node, the overall network quality is obtained by combining the network status of all players in the room to that node, which can be used as a quantitative indicator.

[0015] Specifically, the backend control system can receive network probe results actively reported by clients, or actively initiate network probe requests to candidate nodes to collect data, obtaining network quality data for each player at each candidate node. For each candidate node, the worst value (e.g., maximum latency) among all players' network quality metrics measured at that node can be extracted as the overall network quality of the candidate node, or the average or weighted average of the network quality metrics of all players at that candidate node can be calculated. Using the worst value as the overall network quality in this embodiment can more rigorously guarantee fairness.

[0016] Step S110: Determine the latency tolerance threshold corresponding to the room request.

[0017] It is understood that the latency tolerance threshold is a time limit value used to determine whether the network condition of a candidate node is acceptable. The latency tolerance threshold in this embodiment is not fixed; its value is related to the game scene characteristics corresponding to the current room request.

[0018] Different game genres (such as competitive shooters and casual sandbox games) have varying sensitivities to network synchronization, and therefore different tolerable network latency limits. This application dynamically determines the latency tolerance threshold based on room requests, allowing the selection criteria to adapt to specific business scenarios and avoiding suboptimal scheduling caused by using the same settings.

[0019] Specifically, the backend control system can query a preset scene-threshold mapping table based on the game type identifier (such as game ID or mode ID) carried in the room request to obtain the corresponding latency tolerance threshold. For example, a strict threshold of 80ms can be configured for "high-speed competitive" games, and a lenient threshold of 150ms can be configured for "open-world" games.

[0020] Step S120: Select the minimum value in the overall network quality. If the minimum value is greater than the latency tolerance threshold, remove the candidate node corresponding to the minimum value to obtain the intermediate node.

[0021] It should be noted that the minimum value of the overall network quality refers to the smallest value among all candidate nodes. The intermediate nodes selected based on the minimum value can meet the basic latency requirements.

[0022] Understandably, by finding the minimum of the worst network conditions among all nodes and comparing it with a dynamic threshold, candidate nodes that might lead to unacceptably high latency players in the room can be directly identified and eliminated. This prevents the "weakest link" phenomenon from the source and ensures that the network conditions of the worst players in the room for any node remaining in the candidate pool are above an acceptable baseline, thus guaranteeing the synchronization fairness of the entire room.

[0023] Specifically, the backend control system iterates through the overall network quality values ​​of all candidate nodes and finds the minimum value. Then, it compares the minimum value with the latency tolerance threshold. If the minimum value is greater than the threshold, it means that even the worst player's latency cannot meet the requirements of the node with the best network condition among all nodes, so the node is removed. If the minimum value is not greater than the threshold, it means that at least one node's network condition meets the requirements, so it is not removed, and all nodes enter the next stage.

[0024] Step S130: Determine the comprehensive value of the intermediate node based on the overall network quality data and server load index corresponding to the intermediate node, and select the intermediate node with the smallest comprehensive value as the server node of the game room.

[0025] It should be noted that server load metrics indicate the current resource usage of intermediate nodes, such as CPU utilization, memory utilization, or the number of current connections.

[0026] It is understood that the embodiments of this application avoid over-concentrating traffic on a node that is good but already fully loaded by introducing server load indicators, thereby avoiding the risk of overload. On this basis, a comprehensive cost value is calculated based on overall network quality data and server load indicators. The comprehensive cost value can uniformly measure and weigh the latency of the intermediate node from multiple dimensions, and finally select the node with the lowest comprehensive cost, thus achieving optimal global resource scheduling under the hard fairness constraint.

[0027] Specifically, the backend control system acquires the overall network quality data (such as the average latency of players in the room) and real-time server load metrics for each intermediate node. Then, it converts these metrics into dimensionless scores using a preset normalization formula. The scores are then weighted and summed according to the weights configured for the current game scenario (e.g., network quality is weighted in competitive scenarios, while load balancing is weighted in casual scenarios) to calculate the comprehensive cost value of each node. Finally, the comprehensive cost values ​​of all intermediate nodes are compared, and the node with the smallest value is selected as the final server node.

[0028] For example, suppose there are 3 players (P1, P2, P3) in a room, and 2 candidate server nodes (Node A, Node B). The backend control system obtains the latency data from each player to the node as follows: to Node A, it is [30ms, 40ms, 90ms], and to Node B, it is [50ms, 55ms, 60ms]. If the current scenario is competitive, the latency tolerance threshold is 80ms. The overall network quality of Node A (taking the worst latency) is determined to be 90ms, and that of Node B is 60ms. The minimum overall network quality is 60ms (Node B). Since it is less than the 80ms threshold, no node is eliminated, and the intermediate nodes are {A, B}. The combined cost of Node A and Node B (considering average latency and load) is calculated. Assuming that the cost of Node B is lower, Node B is finally selected as the server node for the game room.

[0029] Understandably, by first applying a hard filter to candidate nodes based on the worst-case network conditions using a dynamic latency tolerance threshold, this method fundamentally eliminates the "weakest link" problem—where high latency from a single player compromises the overall room's synchronization fairness. Building upon this, by integrating multi-dimensional network quality and server load metrics for comprehensive optimization, a balance between resource utilization efficiency and overall experience can be achieved while ensuring basic network fairness. This effectively improves the scientific nature of distributed game room scheduling and the player experience.

[0030] In some embodiments, network quality data includes latency, packet loss rate, and jitter. Obtaining a player's network quality data at each candidate node includes: sending probe packets to the candidate node and receiving probe responses; calculating latency, packet loss rate, and jitter based on the probe responses.

[0031] It is understood that the embodiments of this application can more comprehensively evaluate the real-time quality and stability of network connections through latency, packet loss rate and jitter, providing a reliable data source for subsequent accurate screening and evaluation.

[0032] Specifically, after receiving a room creation request, the back-end control system can instruct the relevant client or gateway to send a series of UDP probe packets to the designated ports of all candidate nodes simultaneously. Based on the time and order of the received response packets, the round-trip delay of each probe can be calculated. By counting the number of probe packets that do not receive a response within the timeout period, the packet loss rate can be calculated. By calculating the variance or standard deviation of the delay measurement, the jitter value can be obtained.

[0033] Specifically, the backend control system instructs the client to send 10 UDP probe packets each to Node A and Node B. For Node A, 9 responses are received, with an average latency of 45ms and a latency variance of 5ms. For Node B, 10 responses are received, with an average latency of 60ms and a latency variance of 2ms. Therefore, the calculated packet loss rate for Node A is 10%, and the jitter is 5ms; the packet loss rate for Node B is 0%, and the jitter is 2ms. These specific latency, packet loss rate, and jitter data will be used as network quality data in subsequent steps.

[0034] In some embodiments, obtaining network quality data for a player at each candidate node further includes: calculating historical network quality data between the player and the corresponding candidate node based on historical game logs in the database of the backend control system when no probe response is received; and correcting the historical network quality data based on network topology features in the database of the backend control system to obtain predicted and completed network quality data.

[0035] Understandably, historical game logs are files stored in a database that record information about players' past game sessions, including the server nodes the player has connected to and the network quality data at the time; network topology features refer to information related to the network structure, such as the ISP to which the player and the server belong, and the connection relationship with the regional backbone network.

[0036] It is understandable that in real-world network environments, probe packets may not respond due to temporary node failures, network congestion, or firewall policies. Simply excluding nodes due to missing data could lead to scheduling failures or inaccurate decisions. This application's embodiments, when proactive probing fails, utilize historical logs and topology features for predictive completion, enhancing the robustness of the scheduling system and ensuring that the algorithm can continue operating based on reasonable predictions even with missing real-time data, thus avoiding service interruptions.

[0037] Specifically, when the backend control system detects a timeout or no response during a probe to a candidate node, it triggers a prediction completion process. This process is as follows: First, the system queries the database to filter out log records of the player (or players with similar characteristics from the same region or carrier) who have historically connected to the candidate node, calculating their historical average latency, packet loss rate, etc., as the base prediction value. Then, it corrects this base value based on current network topology characteristics (such as higher latency for cross-carrier access). For example, if historical connections were within the same carrier, but the current probe is across carriers, the predicted latency is multiplied by a correction coefficient greater than 1.

[0038] For example, an attempt is made to probe candidate node C, but a timeout occurs with no response. The backend control system queries historical logs and finds that the average latency of P1's 5 connections to Node C in the past week is 65ms. At the same time, based on network topology characteristics, the system finds that the IP address of P1's current login belongs to a different operator than that of Node C, while all previous connections were with the same operator. Using the preset correction rule that cross-operator latency usually increases by 20%, the system corrects the predicted latency to 65ms * 1.2 = 78ms and uses this value as the predicted network quality data from P1 to Node C for subsequent overall network quality calculations and filtering.

[0039] Even in the event of a cold start or anomalies due to missing real-time data, the scheduling system can still make decisions based on reasonable predictions, avoiding scheduling failures or random allocations caused by missing data. Thus, this embodiment of the application, by introducing a predictive completion mechanism based on historical data and network topology, improves the robustness and availability of the node selection method when facing network probing uncertainties, ensuring the continuity and reliability of the game room creation service and enhancing the user experience.

[0040] In some embodiments, determining the latency tolerance threshold corresponding to a room request includes: selecting a mapping strategy based on the game type of the room request; and selecting a latency tolerance threshold from a preset threshold based on the mapping strategy.

[0041] It is understood that this application's embodiments, by introducing a mapping strategy, decouple the business concept of game type from the specific threshold selection action, enabling the system to support more flexible strategy configuration. For example, the same game type can correspond to different mapping strategies in different modes (such as ranked matches and casual matches). In this way, selecting from preset thresholds based on the mapping strategy achieves standardization and configurability of threshold determination, improving the system's maintainability and adaptability.

[0042] Specifically, after parsing the room request, the backend control system extracts the game type identifier. Then, based on the identifier, it queries the game type-mapping strategy association table to determine the mapping strategy to be adopted. The mapping strategy can be a simple direct mapping, such as mapping first-person shooter (FPS) to strategy A, or it can be a complex rule that includes branch judgments, such as selecting different strategies based on factors such as time period and player level. The system queries and returns a specific millisecond value from the threshold configuration table data structure as the latency tolerance threshold.

[0043] The room request carries a game type identifier of "GAME_001_FPS_RANKED". The backend control system queries the mapping table and finds that this identifier corresponds to the mapping policy "STRATEGY_COMPETITIVE". The logic of this policy is to directly return the value "80ms" corresponding to the "competitive_fps" item in the threshold configuration table. Therefore, the latency tolerance threshold determined in this example is 80 milliseconds. This embodiment of the application decomposes the process of determining the latency tolerance threshold into two levels: selecting a mapping policy and selecting a threshold based on the policy. This makes the threshold configuration more modular and flexible. System administrators can easily adjust the network fairness standards for different game scenarios by modifying the mapping policy or the preset threshold table without modifying the core scheduling algorithm, thereby improving the system's configurability and its ability to respond quickly to different business needs.

[0044] In some embodiments, determining the comprehensive cost value of an intermediate node based on the overall network quality data and server load index of the intermediate node includes: normalizing the overall network quality data and server load index respectively to obtain a first score value corresponding to the overall network quality data and a second score value corresponding to the server load index. Based on the preset weights associated with the game type corresponding to the room request, the first score and the second score are weighted and summed to obtain the comprehensive cost value.

[0045] The embodiments of this application convert raw metrics with different dimensions and ranges (such as milliseconds of latency, percentage of load) to a uniform, dimensionless scale (such as between 0 and 1) to enable fair comparison and calculation.

[0046] It is understood that the embodiments of this application solve the problem that multi-source heterogeneous indicators cannot be directly mathematically aggregated through normalization processing; on this basis, based on the weighted summation of preset weights, it can flexibly adjust the importance of different dimension indicators in the final decision according to the core requirements of current scenarios such as competitive scenarios that value network quality more, and casual scenarios that value load balancing game scenarios more, and can adapt to the intelligent trade-off of business objectives.

[0047] Specifically, for each intermediate node, the backend control system first normalizes its overall network quality data (such as average latency and average packet loss rate) and server load indicators (such as CPU utilization).

[0048] Specifically, the linear normalization formula is: Score = (Actual value - Optimal reference value) / (Worst tolerance value - Optimal reference value), and the result is restricted to the interval [0,1].

[0049] Then, the system loads the corresponding weight combination from the configuration library according to the game type requested by the room. For example, the weight for competitive games is {network quality: 0.8, load: 0.2}, and the weight for casual games is {network quality: 0.3, load: 0.7}.

[0050] Finally, the comprehensive cost value is calculated as follows: (First score * Network quality weight) + (Second score * Load weight).

[0051] Understandably, by combining game type with dynamic configuration weights, the evaluation criteria can accurately reflect the optimization focus in different scenarios, thereby ensuring that the final selected server nodes not only meet the fairness requirements at the network level, but also achieve optimal or suboptimal allocation at the system resource level, thus improving the rationality and efficiency of the overall scheduling decision.

[0052] In some embodiments, the background control system includes an action arbitration controller and a node room scheduling instruction distributor. After selecting the intermediate node corresponding to the minimum comprehensive cost value as the server node of the game room, it further includes: performing resource arbitration and status confirmation on the server node through the action arbitration controller to obtain the resources to be allocated corresponding to the server node; and issuing a room creation instruction to the server node through the node room scheduling instruction distributor to call the resources to be allocated to create the game room.

[0053] Understandably, the action arbitration controller is a module in the backend control system responsible for coordination and consistency assurance. Resource arbitration refers to the process by which the controller checks whether the target server node currently has sufficient remaining resources (such as CPU, memory, and network bandwidth) to support a new room and attempts to reserve these resources.

[0054] Understandably, while the ultimately selected node is theoretically ideal, in a high-concurrency distributed system, directly issuing commands may lead to resource contention (overselling) or command loss. In this embodiment, the action arbitration controller, after arbitration, reserves specific resource identifiers or quotas for the room, ensuring it is currently in a healthy, serviceable state and that no duplicate scheduling commands for the same room are being executed. This ensures the consistency between the scheduling decision and the actual system state. Based on this, a room creation command is issued to the server node through a node room scheduling command distributor, calling the resources to be allocated to create the game room. The command distributor ensures that the scheduling decision can be reliably translated into actual actions on the server node.

[0055] For example, after determining the server node identifier, the action arbitration controller receives the identifier. First, it queries the node's real-time resource database to determine if the remaining resources meet the requirements of the new room. If so, it deducts the corresponding resource quota using an atomic operation (such as a database transaction) to complete resource reservation (arbitration). Simultaneously, it checks the global transaction log to ensure that there is no record of a successfully created room ID, preventing duplicate creation (status confirmation). After successful arbitration, the controller encapsulates the node identifier, room ID, and resource information to be allocated into a task and submits it to the node's room scheduling instruction distributor. The distributor reliably sends the room creation instruction to the target server node via RPC (Remote Procedure Call) or a message queue. Upon receiving the instruction, the daemon on the node parses it and uses the specified resources to instantiate a new game room process or container.

[0056] Specifically, the algorithm selects server node Node-Z. The action arbitration controller queries Node-Z and finds that its current CPU idle rate is 20% and its remaining memory is 2GB, which meets the requirements of a new room (requirements: CPU 5%, memory 1GB). Therefore, the "Reserved CPU" field of Node-Z is increased by 5% and the "Reserved Memory" field is increased by 1GB in the resource record, completing the arbitration. At the same time, a record is inserted into the global transaction table (Room ID: ROOM_123, Status: Creating). Subsequently, the task {Node: Node-Z, Room: ROOM_123, Resources: {cpu:5%, mem:1GB}} is sent to the instruction dispatcher. The instruction dispatcher sends a message to Node-Z through the message queue. The service program on Node-Z consumes this message and starts a game service instance according to the resource parameters in it.

[0057] This application embodiment introduces an action arbitration controller and a node room scheduling instruction distributor to prevent problems such as node overload (overselling) caused by resource contention, instruction loss caused by network or node failure, and duplicate room creation caused by request retries in high-concurrency scenarios. This ensures that each room creation request can be processed atomically, consistently, and reliably, greatly improving the production environment robustness and service reliability of the distributed game server scheduling system.

[0058] In some embodiments, after calling the resources to be allocated to create the game room, the method further includes: if an abnormality of frame drops is detected in the game room, performing initial alarm processing and recording a frame drop alarm event; if the duration of the abnormality exceeds a preset time, performing multi-level alarm processing and sending the abnormality to the monitoring terminal of the background control system.

[0059] During the operation of the game room, if the server-side rendering or logical frame rate falls below the minimum standard required to maintain a smooth experience, an abnormal situation of frame drops occurs.

[0060] It is understandable that simple node selection and room creation cannot guarantee stable operation of the room throughout its entire lifecycle. This embodiment of the application, by detecting key anomalies such as frame drops in real time, enables the system to promptly identify potential performance degradation or software defects in server nodes. Employing a tiered strategy of initial alarms and multi-level alarms, it avoids overreacting to brief fluctuations while ensuring sufficient attention is paid to persistent issues and notifying maintenance personnel for intervention. This achieves continuous assurance of game service quality and rapid fault recovery.

[0061] For example, the monitoring agent of the backend control system continuously collects performance metrics of created game rooms, such as frames per second (FPS). When it detects that the FPS of a certain room is below a threshold for multiple consecutive sampling points (e.g., below 20 frames per second for 10 seconds), it is determined to be an anomaly of dropped frames. First, an initial alarm is recorded in the alarm log, including the room ID, node ID, timestamp, and metric details. At the same time, a prompt message may be sent to a low-priority alarm channel, and a timer is started. If the dropped frames in the room persist, and the duration exceeds a preset time (e.g., 5 minutes), it is marked as a critical event in the log, and an alarm is sent to a high-priority alarm channel (e.g., SMS, telephone). A detailed anomaly report (including metric trends, node load, and related log fragments) is pushed to the graphical monitoring terminal of the backend control system for operation and maintenance engineers to view and analyze. In this way, the mean time to recovery from failure can be shortened, the overall availability and stability of the game service can be improved, and players can be provided with a more continuous and smooth gaming experience.

[0062] Specifically, the game room ROOM_456 was running on node Node-Y. The monitoring system found that its FPS dropped sharply from 60 to 15 between 10:00:00 and 10:00:10 and remained thereafter. At 10:00:10, the system triggered an initial alarm: recorded the log "WARN:ROOM_456 on Node-Y low FPS (15)" and sent a warning to the operations and maintenance group. By 10:05:10, the room's FPS was still 15, and the abnormal duration had reached 5 minutes, exceeding the preset 3-minute threshold. The system triggered a multi-level alarm: recorded the log "ERROR: ROOM_456 on Node-Y sustained low FPS", sent an SMS alarm to the on-duty engineer, and pushed an event card with detailed charts to the active alarm area of ​​the monitoring screen.

[0063] This application provides a server node selection device for a game room, applied to a backend control system. The device includes: The preprocessing module is used to respond to a player's request to create a room, obtain the player's network quality data at each candidate node, and determine the overall network quality of all players at the corresponding candidate nodes. The first calculation module is used to determine the latency tolerance threshold corresponding to the room request. The second calculation module is used to select the minimum value in the overall network quality. If the minimum value is greater than the latency tolerance threshold, the candidate node corresponding to the minimum value is removed to obtain the intermediate node. The selection module is used to determine the comprehensive cost value of the intermediate node based on the overall network quality data and server load indicators corresponding to the intermediate node, and select the intermediate node with the smallest comprehensive cost value as the server node of the game room.

[0064] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned method for selecting server nodes in a game room. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0065] Please see Figure 4 , Figure 4 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 401 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 402 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 402 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 402 and is called and executed by the processor 401 to execute the server node selection method for the game room in the embodiments of this application. Input / output interface 403 is used to implement information input and output; The communication interface 404 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 405 transmits information between various components of the device (e.g., processor 401, memory 402, input / output interface 403, and communication interface 404); The processor 401, memory 402, input / output interface 403 and communication interface 404 are connected to each other within the device via bus 405.

[0066] In some embodiments, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for selecting server nodes in a game room.

[0067] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0068] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0069] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0070] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0071] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0072] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0073] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0074] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

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

[0077] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for selecting server nodes in a game room, characterized in that, Applied to a background control system, the method includes: In response to a player's request to create a room, obtain the player's network quality data at each candidate node, and determine the overall network quality of all players at the corresponding candidate node; Determine the latency tolerance threshold corresponding to the room request; The minimum value is selected from the overall network quality. If the minimum value is greater than the latency tolerance threshold, the candidate node corresponding to the minimum value is removed to obtain the intermediate node. Based on the overall network quality data and server load indicators corresponding to the intermediate node, the comprehensive value of the intermediate node is determined, and the intermediate node with the smallest comprehensive value is selected as the server node of the game room.

2. The server node selection method for game rooms according to claim 1, characterized in that, The network quality data includes latency, packet loss rate, and jitter. Obtaining the player's network quality data at each candidate node includes: Send probe packets to the candidate nodes and receive probe responses; The latency, packet loss rate, and jitter are calculated based on the detection response.

3. The server node selection method for game rooms according to claim 2, characterized in that, The process of obtaining the player's network quality data at each candidate node also includes: If the detection response is not received, the historical network quality data between the player and the corresponding candidate node is calculated based on the historical game logs in the database of the background control system. Based on the network topology features in the database of the background control system, the historical network quality data is corrected to obtain the predicted and completed network quality data.

4. The server node selection method for game rooms according to claim 1, characterized in that, The step of determining the latency tolerance threshold corresponding to the room request includes: Select a mapping strategy based on the game type requested in the room; The latency tolerance threshold is selected from the preset thresholds based on the mapping strategy.

5. The method for selecting server nodes for a game room according to claim 1, characterized in that, The determination of the comprehensive cost value corresponding to the intermediate node based on the overall network quality data and server load indicators corresponding to the intermediate node includes: The overall network quality data and the server load index are normalized respectively to obtain a first score value corresponding to the overall network quality data and a second score value corresponding to the server load index. Based on the preset weight associated with the game type corresponding to the room request, the first score and the second score are weighted and summed to obtain the comprehensive cost value.

6. The server node selection method for game rooms according to claim 1, characterized in that, The background control system includes an action arbitration controller and a node room scheduling instruction distributor. After selecting the intermediate node corresponding to the smallest comprehensive cost value as the server node of the game room, it also includes: The server node is arbitrated and its status is confirmed by the action arbitration controller to obtain the resources to be allocated for the server node. The node room scheduling instruction distributor sends a room creation instruction to the server node and calls the resources to be allocated to create a game room.

7. The server node selection method for game rooms according to claim 6, characterized in that, After the process of calling the resources to be allocated to create the game room, the following is also included: If an abnormal frame drop is detected in the game room, an initial alarm is triggered and a frame drop alarm event is recorded. If the duration of the abnormal situation exceeds a preset time, multi-level alarm processing will be performed, and the abnormal situation will be sent to the monitoring terminal of the background control system.

8. A server node selection device for a game room, characterized in that, The device, used in a background control system, includes: A preprocessing module is used to respond to a player's request to create a room, obtain the player's network quality data at each candidate node, and determine the overall network quality of all players at the corresponding candidate node; A first calculation module is used to determine the latency tolerance threshold corresponding to the room request; The second calculation module is used to select the minimum value in the overall network quality, and when the minimum value is greater than the latency tolerance threshold, the candidate node corresponding to the minimum value is removed to obtain the intermediate node. The selection module is used to determine the comprehensive value of the intermediate node based on the overall network quality data and server load index corresponding to the intermediate node, and select the intermediate node with the smallest comprehensive value as the server node of the game room.

9. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When at least one of the programs is executed by at least one of the processors, the server node selection method for the game room as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the server node selection method for any of the game rooms described in claims 1 to 7.

Images