Game flow limiting method, device and system and computer equipment

Abstract

The invention provides a game flow limiting method, device and system and computer equipment, and relates to the technical field of computers. The game traffic limiting method comprises the steps that a login request from a client side is received, and whether login is allowed or not is determined according to the number of online people; if login is allowed, an authentication token containing expiration time is sent to the client; receiving a service request containing the authentication token from a client, and updating the authentication token based on expiration time in the authentication token; and updating the number of online people based on the number of unexpired authentication tokens.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, system, computer device, computer-readable storage medium, and computer program product for limiting game bandwidth. Background Technology

[0002] In high-concurrency login load scenarios of online games, to ensure service stability, game servers can limit the number of online players, thus implementing login rate limiting. For games using long-connection mechanisms, the server can monitor player online / offline status in real time by establishing and closing connections, thereby controlling the number of online players. For games using short-connection mechanisms, a heartbeat mechanism can be used, where clients periodically send heartbeat signals to infer player online status. However, frequent heartbeat requests significantly increase the server's QPS (Queries Per Second), easily leading to server bottlenecks. Furthermore, the heartbeat mechanism has a latency issue, making it unreliable to count the number of online players and hindering accurate rate limiting.

[0003] In view of this, some embodiments of this specification provide a game rate limiting method, apparatus, system, computer device, computer-readable storage medium, and computer program product, which aim to reduce the computational load on the server side and improve the accuracy of rate limiting services. Summary of the Invention

[0004] This specification provides one or more embodiments of a game traffic limiting method, the method comprising: receiving a login request from a client, determining whether to allow login based on the number of online users; if login is allowed, sending an authentication token containing an expiration time to the client; receiving a service request containing an authentication token from the client, and updating the authentication token based on the expiration time in the authentication token; and updating the number of online users based on the number of non-expired authentication tokens.

[0005] According to one or more embodiments of this specification, a method for receiving a login request from a client and determining whether to allow login based on the number of online users includes: upon receiving a login request from a client, determining whether the number of online users has reached the maximum limit; allowing login when the number of online users has not reached the maximum limit; and adding the player account identifier corresponding to the client to a queue when the number of online users has reached the maximum limit.

[0006] According to one or more embodiments of this specification, when the number of online users reaches the maximum limit, the player account identifier corresponding to the client is added to the queue, including: when the number of online users reaches the maximum limit, determining whether the number of people in the queue has reached the queue limit; when the number of people in the queue has not reached the queue limit, adding the player account identifier corresponding to the client to the queue; when the number of people in the queue reaches the queue limit, rejecting the login request.

[0007] According to one or more embodiments of this specification, the method for adding a player account identifier corresponding to a client to a queue includes: adding the player account identifier corresponding to the client to the queue, and determining the ranking of the player account identifier in the queue based on at least one of the following information: the player account's level, the player account's payment information, the time of joining the queue, and random weight.

[0008] The method provided according to one or more embodiments of this specification further includes: sending queuing information to a client, the queuing information including at least one of the following: total number of people in the queue, their rank in the queue, and estimated waiting time; wherein the estimated waiting time is determined based on the queuing rank.

[0009] The method provided according to one or more embodiments of this specification, after sending an authentication token containing an expiration time to the client, further includes: confirming successful login when a confirmation login message is received from the client before the expiration time.

[0010] According to one or more embodiments of this specification, a method for receiving a service request containing an authentication token from a client and updating the authentication token based on the expiration time in the authentication token includes: receiving a service request containing an authentication token from a client and verifying the validity period of the authentication token; updating the expiration time in the authentication token when the authentication token has expired or is within a preset time range before expiration.

[0011] According to one or more embodiments of this specification, sending an authentication token containing an expiration time to a client includes: sending the authentication token containing an expiration time to the client and establishing status information corresponding to the authentication token in a status information table, the status information including the expiration time of the authentication token and the player account identifier; updating the number of online users based on the number of unexpired authentication tokens includes: deleting the status information corresponding to expired authentication tokens in the status information table based on a preset time interval; updating the number of online users based on the status information corresponding to unexpired authentication tokens in the status information table, wherein the status information corresponding to unexpired authentication tokens in the status information table can represent the number of unexpired authentication tokens.

[0012] The method provided according to one or more embodiments of this specification further includes: receiving a business request containing an authentication token from a client, and when there is no status information corresponding to the authentication token in the status information table, if the number of online players reaches the maximum limit, logging off the player account corresponding to the client; if the number of online players does not reach the maximum limit, responding to the business request and updating the expiration time in the authentication token and the status information in the status information table.

[0013] One or more embodiments of this specification also provide another method for game traffic limiting, the method comprising: sending a login request to a server, the login request being used to instruct the server to determine whether to allow login based on the number of online users, and returning an authentication token containing an expiration time when login is allowed; sending a business request containing the authentication token to the server, the business request being used to instruct the server to update the authentication token based on the expiration time in the authentication token; wherein the number of online users is updated based on the number of authentication tokens that have not expired.

[0014] One or more embodiments of this specification also provide a game traffic limiting device, the device comprising: a login request receiving module, configured to receive a login request from a client and determine whether to allow login based on the number of online users; an authentication token sending module, configured to send an authentication token containing an expiration time to the client if login is allowed; an authentication token updating module, configured to receive a service request containing an authentication token from the client and update the authentication token based on the expiration time in the authentication token; and a user count updating module, configured to update the number of online users based on the number of non-expired authentication tokens.

[0015] One or more embodiments of this specification also provide a game traffic limiting system, the system including a client and a server. The client is used to send a login request and a business request containing an authentication token to the server. The server is used to receive the login request from the client, determine whether to allow login based on the number of online users, and if login is allowed, send an authentication token containing an expiration time to the client. In response to the business request containing the authentication token from the client, the server updates the authentication token based on the expiration time in the authentication token, and updates the number of online users based on the number of non-expired authentication tokens.

[0016] One or more embodiments of this specification also provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it is able to implement the game traffic limiting method described in some embodiments of this specification.

[0017] One or more embodiments of this specification also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, can implement the game traffic limiting method described in some embodiments of this specification.

[0018] One or more embodiments of this specification also provide a computer program product, including a computer program that, when at least a portion of the computer program is executed by a processor, can implement the game traffic limiting method described in some embodiments of this specification.

[0019] The beneficial effects that the embodiments of this specification may bring include, but are not limited to: receiving login requests from clients, determining whether login is allowed based on the number of online users, and if login is allowed, sending an authentication token containing an expiration time to the client; further, receiving business requests containing authentication tokens from clients, updating the authentication token based on the expiration time in the authentication token, and updating the number of online users based on the number of unexpired authentication tokens. This can reduce the computational load on the server side and improve the accuracy of the rate limiting service. By using a status information table to maintain the expiration time and player account identifier corresponding to the authentication token, and determining the number of unexpired authentication tokens based on the number of unexpired times in the status information table, the number of online users can be determined. In this way, the player activity status can still be accurately perceived without maintaining a persistent connection, improving the accuracy of online user statistics and the accuracy of the rate limiting service. By sending queuing information to clients so that players know the current queuing progress, the predictability of the player experience is improved, and the frustration caused by frequent retries due to "server busy" is reduced. It should be noted that different embodiments may produce different beneficial effects. In different embodiments, the beneficial effects that may occur can be any one or a combination of the above, or any other possible beneficial effects. Attached Figure Description

[0020] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. The same numbers in the drawings denote the same structures or steps.

[0021] Figure 1 This is a schematic diagram of a game traffic-limiting operating environment shown in some embodiments of this specification.

[0022] Figure 2 This is an exemplary flowchart illustrating a game rate limiting method according to some embodiments of this specification.

[0023] Figure 3 This is a schematic diagram of a business request process according to some embodiments of this specification.

[0024] Figure 4 This is an exemplary flowchart of a queuing login method according to some embodiments of this specification.

[0025] Figure 5 This is a schematic diagram of the login process according to some embodiments of this specification.

[0026] Figure 6 This is an exemplary flowchart illustrating another game rate limiting method according to some embodiments of this specification.

[0027] Figure 7 This is an exemplary block diagram of a game traffic limiting device according to some embodiments of this specification.

[0028] Figure 8 This is an exemplary block diagram of a game traffic limiting device according to some embodiments of this specification.

[0029] Figure 9 This is an exemplary block diagram of a game traffic limiting system according to some embodiments of this specification. Detailed Implementation

[0030] To more clearly illustrate the technical solutions of the embodiments in this specification, the embodiments will be described in detail below with reference to the accompanying drawings. Obviously, the content described below are some examples or embodiments of this specification. For those skilled in the art, without creative effort, the technical solutions or means disclosed in this specification can be applied to other scenarios based on this technical content.

[0031] It should be understood that the terms "system," "device," "unit," and / or "module" used in this specification are a method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0032] Unless otherwise specified, the technical terms used to describe components, elements, etc. in this specification are not singular but may include plural. Generally speaking, terms such as "comprising" or "including" only indicate that explicitly identified steps, elements, or components are included, and these steps, elements, and components do not constitute an exclusive list, as the described method or apparatus may also include other steps or components.

[0033] This specification uses flowcharts to illustrate the operational steps performed by the apparatus or system of related embodiments. However, unless otherwise specified, the order in which these steps are described should not be construed as a limitation on the order of execution. Those skilled in the art can adjust the order of these steps based on the knowledge and information conveyed by the embodiments in this specification. Such adjustments include, but are not limited to, reversing the order of steps, merging multiple steps, and splitting a step.

[0034] Online games are games that run on electronic devices, are controlled by computer programs (such as game applications), and are intended for intellectual or entertainment purposes. High-concurrency load scenarios often occur in online games, where the system needs to handle a large number of user requests or operations simultaneously within a very short time window. Under high-concurrency load scenarios, server computing resources, network bandwidth, and other resources are heavily consumed, easily leading to system crashes. Therefore, it is necessary to implement service throttling for online games.

[0035] Figure 1This is a schematic diagram illustrating a game traffic-limiting operating environment according to some embodiments of this specification. For example... Figure 1 As shown, the game rate-limiting operating environment 100 may include: a server 110, a client 120, and a network 130. The server 110 and client 120 can transmit data via the network 130. In the online game, the client 120 can send login requests or business requests to the server 110 via the network 130. The server 110 can process the login requests and business requests and provide rate-limiting services to prevent system overload.

[0036] The server 110 can be a high-performance computer device used to analyze and process requests from clients and perform complex calculations or logical processing in the online game. For example, the server 110 can receive login requests from clients 120, determine whether to allow login based on the number of online users, and if login is allowed, generate an authentication token with an expiration time and send it to clients 120. Alternatively, the server 110 can receive business requests containing authentication tokens from clients 120 and update the authentication tokens based on their expiration times. Furthermore, the server 110 can update the number of online users based on the number of unexpired authentication tokens. In some embodiments, the server 110 can also publish various versions of the game application for players to download or update. In some embodiments, the server 110 can include a local server or a cloud server; depending on different service requirements, local servers corresponding to those regions can be deployed in one or more regions. In some embodiments, the server 110 can be a single computer device or a computing cluster composed of multiple computer devices, thereby providing more powerful computing power and more efficient response to user service requests.

[0037] Client 120 may include, but is not limited to, terminal devices such as desktop computers, smartphones, laptops, VR (Virtual Reality) devices, tablets, smart TVs, and in-vehicle terminals. Client 120 may include a display screen and a processor. The display screen can be used to present a graphical user interface (GUI). For example, client 120 can present a login interface through the GUI. In some embodiments, the display screen may be separate from the human-machine interface device. The user can operate on the GUI through the human-machine interface device. The processor of client 120 can receive operation commands generated by operations on the GUI through the human-machine interface device. The display screen can be used to present the GUI, for example, to present response results generated based on operation commands input through the GUI. In other embodiments, the display screen may be a touch screen, which can receive operation commands input by the user based on the GUI. For example, client 120 can receive login operation commands input by the user based on the GUI through the touch screen. Client 120 can respond to the login operation commands by generating a login request and sending it to server 110. As another example, client 120 can receive game operation commands input by the user based on the GUI through the touch screen. Client 120 can respond to the game operation commands by generating a service request and sending it to server 110.

[0038] Network 130 can be any type of wired or wireless network, or any combination thereof. As an example, network 130 can be one or more of the following: wired network, fiber optic network, telecommunications network, internal network, Internet, local area network (LAN), wide area network (WAN), wireless local area network (WLAN), metropolitan area network (MAN), public switched telephone network (PSTN), Bluetooth network, etc. Network 130 can have multiple access points, and server 110 and client 120 can access network 130 through these access points.

[0039] It should be noted that, Figure 1 The diagram illustrating a game rate-limiting operating environment is merely an example. The game rate-limiting operating environment described in the embodiments of this specification is intended to more clearly illustrate the technical solutions of the embodiments of this specification and does not constitute a limitation on the technical solutions provided in the embodiments of this specification. For example, Figure 1 The number of server-side 110 and client-side 120 in this specification is merely illustrative and is not intended to limit the scope of patent protection of this application. Depending on the actual situation, any number of server-side 110 and client-side 120 may be used. As will be apparent to those skilled in the art, with the development of computer technology and the emergence of new business scenarios, the technical solutions provided in the embodiments of this specification are also applicable to similar technical problems.

[0040] In high-concurrency login load scenarios of online games, to ensure service stability, online game servers can limit the number of online players, thus implementing login rate limiting. Connection methods in online games can include persistent connections and short connections. A persistent connection refers to a connection established between the client and server that remains open for an extended period, allowing both parties to remain online and communicate in real time. An example is a persistent connection based on the TCP protocol. A short connection refers to a new connection established for each communication between the client and server, which is closed immediately after communication is complete; each interaction is a new connection process. An example is a one-time connection based on the HTTP protocol.

[0041] In some embodiments, for games employing long-connection mechanisms, the server can monitor player online / offline status in real time by establishing and disconnecting connections, thereby controlling the number of online players. In other embodiments, for games employing short-connection mechanisms, such as lightweight casual games or H5 games, a heartbeat mechanism can be used, where the client periodically sends heartbeat signals to infer the player's online status. However, frequent heartbeat requests significantly increase the server's QPS (Queries Per Second), increasing server computation and potentially causing server bottlenecks. Furthermore, the heartbeat mechanism has a latency issue, making it unreliable to accurately count online players and hindering precise rate limiting. In high-concurrency load scenarios, game servers need to use rate limiting mechanisms to control the maximum number of online players to ensure overall service stability. Therefore, how to implement a rate-limiting service that accurately controls online concurrency without relying on long-connection mechanisms under a short-connection architecture has become a pressing problem.

[0042] In view of this, some embodiments of this specification provide a game rate limiting method. This method receives login requests from clients, determines whether login is allowed based on the number of online users, and if login is allowed, sends an authentication token containing an expiration time to the client. Furthermore, it receives a business request containing the authentication token from the client, updates the authentication token based on its expiration time, and updates the number of online users based on the number of unexpired authentication tokens. This reduces server-side computation and improves the accuracy of the rate limiting service.

[0043] Figure 2 This is an exemplary flowchart illustrating a game rate limiting method according to some embodiments of this specification. Figure 2 The process 200 shown can be executed by a computer device, for example, by... Figure 1 The server 110 shown is executed. In some embodiments, process 200 may be implemented by a game rate limiting device 700 deployed on a computer device. Figure 2 As shown, in some embodiments, process 200 may include the following steps.

[0044] Step 210: Receive a login request from the client and determine whether to allow login based on the number of online users. In some embodiments, step 210 can be implemented by the login request receiving module 710.

[0045] In some embodiments, users can log in through the client's graphical user interface, for example, by clicking the login icon in the graphical user interface of client 120. Client 120 can respond to this login operation by sending a login request to server 110. After receiving the login request from client 120, server 110 can first query the number of online players and determine whether to allow login based on the number of online players. If the number of online players in the game has not reached the player limit, login is allowed; if the number of online players in the game has reached the player limit, login is not allowed, and server 110 can add the player account ID corresponding to client 120 to the queue to wait for login. This can effectively control the number of online players and avoid system overload. For more details on determining whether to allow login based on the number of online players, please refer to the description in process 400 below.

[0046] Step 220: If login is allowed, send an authentication token containing an expiration time to the client. In some embodiments, step 220 can be implemented by the authentication token sending module 720.

[0047] In some embodiments, the authentication token can be a server-generated digital credential containing an expiration time, used to identify the login status of a player account and to authenticate the player account. For example, the authentication token can be a JWT (JSON Web Token). In some embodiments, if player account login is allowed, the server can generate an authentication token, set its expiration time according to the time the token was generated, and send the authentication token containing the expiration time to the client. When the client subsequently sends a business request to the server, it can include this authentication token. The server can then verify the authentication token in the business request and determine whether to renew it based on the expiration time, thereby maintaining the validity of the authentication token.

[0048] In some embodiments, the server can send an authentication token containing an expiration time to the client and establish the corresponding status information in a status information table. The status information table can be used to maintain and update the online status of player accounts. The status information table can be stored in an in-memory database and implemented using an ordered set in the in-memory database. The ordered set can be a data structure used to store unique elements (members), each element can be associated with a score, and the elements in the ordered set can be arranged according to their scores. The score in the ordered set can be a numerical value associated with an element (member) and used for comparison and sorting. In some embodiments, the status information in the status information table can include the expiration time of the authentication token and the player account identifier. The expiration time of the authentication token in the status information can be the same as the expiration time carried by the authentication token. For example, the server 110 can establish the expiration time of the authentication token and the player account identifier in the ordered set, using the player account identifier as a unique element and the expiration time of the authentication token as the score corresponding to the element, and sorting the player account identifiers in ascending order of scores.

[0049] In some embodiments, after the server sends an authentication token containing an expiration time to the client, the user can confirm login before the expiration time. For example, the user can click the confirm login icon in the graphical user interface of client 120, and client 120 can respond to the confirmation login operation by sending confirmation login information to server 110. In some embodiments, when the server receives confirmation login information from the client before the expiration time, it can confirm that the client has successfully logged in. For example, client 120 can respond to the confirmation login operation by sending confirmation login information to the server, which may carry an authentication token containing an expiration time. The server can verify the digital signature of the authentication token (e.g., JWT) to ensure that it has not been tampered with, and parse out the expiration time carried therein, comparing the expiration time with the current time. If the authentication token has not expired, server 110 can confirm that the client has successfully logged in and update the expiration time in the authentication token so that when the client sends a business request later, the authentication token in the business request can carry the updated expiration time. If the authentication token has expired, server 110 can confirm that the client's login has failed and return login failure information to the client. In some embodiments, the expiration time in the authentication token sent by the server to the client before login may be different from the expiration time of the authentication token in the business request.

[0050] Step 230: Receive a business request containing an authentication token from the client, and update the authentication token based on the expiration time in the authentication token. In some embodiments, step 230 can be implemented by the authentication token update module 730.

[0051] In some embodiments, the server can receive a business request containing an authentication token from the client and verify the validity period of the authentication token. When the authentication token has expired or is within a preset time range before expiration, the server updates the expiration time in the authentication token. The business request can be any request initiated by the client's player account to the server after successful login, executing specific game logic operations. For example, a business request could be a request to move a game character, a request to release a game character's skill, etc.

[0052] For example, after receiving a business request containing an authentication token from the client 120, the server 110 can verify the digital signature of the authentication token (e.g., a JWT) to ensure it has not been tampered with, and parse out the expiration time carried therein. This expiration time is then compared with the current time to verify the validity of the authentication token. For instance, if the current time is 14:31:00, and the expiration time in the authentication token is 14:30:00, then the authentication token has expired. As another example, if the preset time range is 5 minutes, and the current time is 14:26:00, and the expiration time in the authentication token is 14:30:00, then the current time is 4 minutes away from the expiration time in the authentication token, which is within the preset time range. Furthermore, when the authentication token has expired or the current time is within the preset time range from the expiration time of the authentication token, the server 110 can renew the authentication token. For example, it can use the time corresponding to 5 minutes prior to the current time as the renewed expiration time, thereby updating the expiration time in the authentication token. The server 110 can also synchronously update the expiration time corresponding to the authentication token in the status information table. For example, it can push back 5 minutes from the current time as the expiration time after renewal and overwrite the original expiration time in the status information table.

[0053] In some embodiments, when the server receives a business request containing an authentication token from a client, and the status information table does not contain status information corresponding to the authentication token, if the number of online players reaches the player limit, the server can log off the player account corresponding to the client. If the number of online players does not reach the player limit, the server can respond to the business request and update the expiration time in the authentication token and the status information in the status information table. For example, when the server 110 receives a business request containing an authentication token from the client 120, it can query the status information table to see if the expiration time and player account identifier corresponding to the authentication token exist. If not, it means the player may have been inactive for a long time, and the status information corresponding to the authentication token has been deleted from the status information table by the server 110 because it has expired. Further judgment can be made based on the number of online players. If the number of online players reaches the player limit, it means the current game is saturated, and the slot previously occupied by the player account has been reclaimed and reallocated. The server 110 can log off the player account corresponding to the client 120, and the player account can re-enter the login or queuing process, thereby ensuring the fairness of slot allocation, prioritizing the service response and game experience of active players, avoiding excessive server computation due to high QPS, and achieving precise rate limiting service. If the number of online players has not reached the maximum limit, it means that the number of players in the game is not yet saturated. The server 110 can respond to the business request and update the expiration time in the authentication token and the status information in the status information table to synchronize the expiration time in the status information with the expiration time in the authentication token.

[0054] In some embodiments, the server may include a rate limiting service center and a business server. The rate limiting service center can be used to provide rate limiting services, and the business server can be used to execute specific business logic and interact with the client and the rate limiting service center. Figure 3 This is a schematic diagram of a business request process according to some embodiments of this specification. For example... Figure 3 As shown, the client can send a service request containing an authentication token to the service server. The service server can verify the validity of the authentication token. When the authentication token has not expired (or the authentication token has not expired but the remaining time before expiration exceeds a preset time range), it does not need to be updated (or renewed), and the service server can return a service response to the client. When the authentication token has expired (or the authentication token has not expired but the remaining time before expiration is within a preset time range), the service server can request the rate limiting service center to update (or renew) the authentication token. The rate limiting service center can generate a new expiration time and return the authentication token containing the new expiration time to the service server, and update the expiration time in the status information table to synchronize it with the expiration time in the authentication token. Furthermore, the service server can return the updated authentication token and service response to the client.

[0055] Step 240: Update the number of online users based on the number of valid authentication tokens. In some embodiments, step 240 can be implemented by the user update module 740.

[0056] In some embodiments, the number of unexpired authentication tokens can be determined based on the expiration time in the status information. The server can compare the expiration time in the status information table with the current time and count the number of unexpired times. This count can represent the number of unexpired authentication tokens, which in turn represents the number of online users. In some embodiments, the server can also delete expired status information from the status information table. The number of expired status information entries in the status information table can then be used to represent the number of unexpired authentication tokens, which in turn represents the number of online users. For example, the server 110 can use the ZCARD shardKey command to count the number of unexpired times in the status information table, thereby counting the number of online users.

[0057] In some embodiments, the server can delete the status information corresponding to expired authentication tokens in the status information table based on a preset time interval, and update the number of online users based on the status information corresponding to unexpired authentication tokens in the status information table. The status information corresponding to unexpired authentication tokens in the status information table represents the number of unexpired authentication tokens. In some embodiments, the preset time interval can be a fixed time interval or a dynamically adjusted time interval. For example, the server can delete the status information corresponding to expired authentication tokens in the status information table every five minutes. The server can also dynamically adjust the preset time interval based on server computing power or the number of online users. For example, when the number of online users exceeds a preset number, or the server's QPS value exceeds a preset QPS threshold, the server 110 can automatically reduce the time interval, thereby accelerating the cleanup of expired tokens and the reallocation of idle tokens. For example, the server 110 can delete the status information corresponding to expired authentication tokens in the status information table according to the preset time interval using the `ZREMRANGEBYSCORE shardKey-inf now` command.

[0058] In some embodiments, the server can fragment the state information corresponding to the authentication token into multiple state information tables. For example, the player account identifier can be processed using a hash function to convert it into a hash value, and the state information corresponding to the authentication token can be fragmented and stored into multiple state information tables based on the hash value, thereby improving system concurrency performance. In some embodiments, the server can count and summarize the number of unexpired times in each state information table, and determine the number of online users based on the summary result.

[0059] In some embodiments, step 240 may be executed before or after any step in process 200. For example, step 240 may be executed before step 210, step 220 or step 230, or step 240 may be executed after step 210, step 220 or step 230.

[0060] Figure 4 This is an exemplary flowchart of a queuing login method according to some embodiments of this specification. Figure 4 The illustrated process 400 can be executed by a computer device, for example, by a login request receiving module 710 in a game throttling device 700 deployed on a computer device. In some embodiments, process 400 can be a further description of step 210. Figure 4 As shown, in some embodiments, process 400 may include the following steps.

[0061] Step 410: Upon receiving a login request from the client, determine whether the number of online users has reached the maximum limit.

[0062] In some embodiments, the number of online users can be determined based on the number of unexpired authentication tokens. The server can also update the number of online users based on the number of unexpired authentication tokens. For details on this part, please refer to the description in step 240 above, which will not be repeated here.

[0063] In some embodiments, a user can log in through the client's graphical user interface, for example, by clicking the login icon in the graphical user interface of client 120. Client 120 can respond to this login operation by sending a login request to server 110. After receiving the login request from client 120, server 110 can first query the number of online users to determine whether the number of online users has reached the limit.

[0064] In some embodiments, the number of unexpired authentication tokens can be determined based on the expiration time in the status information. The server can compare the expiration time in the status information table with the current time and count the number of unexpired tokens. This count can represent the number of unexpired authentication tokens, which in turn represents the number of online users. Further details regarding the number of online users (e.g., methods for determining and updating the number of online users) can be found in step 240 above and will not be repeated here.

[0065] Step 420: Allow login when the number of online users has not reached the maximum limit.

[0066] In some embodiments, the server determines to allow login when the number of online users has not reached the user limit. For example, the user limit could be 10,000; if there are 8,000 online users, login is allowed. Furthermore, the server can send an authentication token containing an expiration time to the client. In some embodiments, the server can continue with step 220 after step 420.

[0067] Step 430: When the number of online users reaches the maximum limit, determine whether the number of people in the queue has reached the maximum limit.

[0068] In some embodiments, when the number of online users reaches the maximum limit, in order to reduce the computational load on the server and avoid server overload, the server may disallow login and determine whether the number of people in the queue has reached the queuing limit, and make different decisions based on the determination result.

[0069] In some embodiments, the queue can be a queue for players waiting to log in to the game. The queue can be stored in an in-memory database and implemented using an ordered set within the database. The ordered set can be a data structure used to store unique members, each associated with a score, and the elements in the ordered set can be arranged according to their scores. The scores in the ordered set can be numerical values ​​associated with the members, used for comparison and sorting. Information in the ordered set can include player account identifiers and timestamps of joining the queue. For example, server 110 can store player account identifiers that have joined the queue using an ordered set, and use the timestamps of joining the queue as scores to sort the player account identifiers in ascending order of scores.

[0070] Step 440: When the number of people in the queue has not reached the queue limit, add the player account ID corresponding to the client to the queue.

[0071] In some embodiments, the player account identifier can be a unique identifier used to identify the player account, for example, the player account identifier can be a player account ID. For example, the queue limit can be 500 people. If the queue has 400 people, the server 110 can add the player account ID corresponding to the client 120 to the queue for queuing.

[0072] In some embodiments, the server can add the player account identifier corresponding to the client to a queue and determine the player account identifier's ranking in the queue based on at least one of the following: the player account's level, the player account's corresponding payment information, the time the player account joined the queue, and a random weight. The player account's level can reflect the player account's advancement level or experience points in the game. The player account's corresponding payment information can be the player's recharge amount or spending history. The time the player account joined the queue can be the timestamp when the player account requested login and entered the queue. The random weight can be a weight value randomly assigned to the player account. For example, the earlier the player account joined the queue, the higher its ranking in the queue. Similarly, the higher the player account's level and the heavier its corresponding payment information, the higher its ranking in the queue.

[0073] In some embodiments, the server can perform a weighted calculation based on at least one of the player account's level weight, the player account's corresponding payment weight, and a random weight to determine the ranking score corresponding to the player account identifier, and determine the player account identifier's rank in the queue based on the ranking score. The player account's level weight can be weight information determined after normalizing the player account's level. For example, if the level range is 1 to 100 and the player account level is 55, then the player account's level weight can be (player account level - minimum level range) / (maximum level range - minimum level range) = (55 - 1) / (100 - 1) = 0.545. The player account's corresponding payment weight can be weight information determined after normalizing the player account's payment information. For example, if the minimum payment amount for all player accounts can be 0, the maximum payment amount can be 10000, and the payment information corresponding to a player account is 2500, then the payment weight corresponding to the player account can be (player account payment information - minimum payment range) / (maximum payment range - minimum payment range) = (2500 - 0) / (10000 - 0) = 0.25. For instance, if the player account's level weight can be 0.545, the corresponding payment weight can be 0.25, and the random weight can be 0.5, then the ranking score corresponding to the player account identifier can be expressed as p = α × 0.545 + β × 0.25 + γ × 0.5, where α, β, and γ can be weight coefficients. The server can also store the player account identifier and its corresponding ranking score in an ordered set and sort the player account identifiers according to the ranking score. For example, sorting the player account identifiers in descending order of ranking score.

[0074] In some embodiments, the server may also send queuing information to the client. This queuing information may include at least one of the following: total number of people in the queue, rank in the queue, and estimated waiting time. The total number of people in the queue can be represented by the total number of player account identifiers in the current queue. The rank of a player account identifier in the queue can dynamically change as the queue updates. For example, if player account identifier 'a' is ranked 50th in the queue, and player account identifier 'b' (rank 1) is allowed to log in, the server can remove player account identifier 'b' from the queue to update the queue, and player account identifier 'a' will be ranked 49th. The estimated waiting time can be determined based on the queue rank. For example, the estimated waiting time can be determined based on the deletion rate of status information in the status information table and the queue rank. The deletion rate of status information in the status information table can be determined based on the historical deletion count of expired authentication token status information within a certain period. For example, if 200 expired status messages were deleted in the past ten minutes, the deletion rate of status messages in the status message table is 200 / 10 = 20 messages / minute. This means that an average of 20 slots are released per minute in the queue. The estimated waiting time can be the ratio of the queue position to the status message deletion rate. For example, if player account ID 'a' is ranked 50th in the queue, and the status message deletion rate is 20 messages / minute, then the estimated waiting time is 50 / 20 = 2.5 minutes.

[0075] In some embodiments, the client can also receive queuing information sent by the server, such as the total number of people in the queue, the player's position in the queue, and the estimated waiting time. The queuing information is then displayed in the graphical user interface so that the player is aware of the current queuing status, improving the predictability of the player's experience. Instead of frequently refreshing the page or blindly clicking the login request repeatedly, the player can intuitively understand their progress in the queue and the approximate time required. This deterministic feedback mechanism effectively alleviates the anxiety caused by unknown waiting in high-concurrency scenarios and reduces the frustration caused by frequent retries due to "server busy".

[0076] Step 450: When the number of people in the queue reaches the queue limit, the login request is rejected.

[0077] For example, the queue limit can be 500 people. If the queue is full (500 people), the server 110 can reject the login request and return a login request rejection response to the client 120. For instance, the server 110 can return a "busy" message to the client 120.

[0078] In some embodiments, the server can also update the queue. For example, server 110 can insert a new player account identifier and the timestamp of joining the queue into the ordered set to update the queue. When some player accounts log off in the game, and the number of online players falls below the maximum limit, the player accounts at the head of the ordered set can log in to the game first. Server 110 can delete the player account identifier and the corresponding timestamp of joining the queue from the ordered set, thereby freeing up queue slots.

[0079] In some embodiments, the server may include a rate limiting service center and a business server. The rate limiting service center can be used to provide rate limiting services, and the business server can be used to execute specific business logic and interact with the client and the rate limiting service center. Figure 5 This is a schematic diagram of the login process according to some embodiments of this specification. For example... Figure 5 As shown, the client can send a login request. After receiving the login request, the business server requests the rate limiting service center to detect the current number of online users. The rate limiting service center can query the number of unexpired status information entries in the status information table to determine the number of online users, and then determine whether the number of online users has reached the upper limit based on the upper limit. When the number of online users has not reached the upper limit, the rate limiting service center can generate an authentication token containing the expiration time and return it to the client through the business server. When the number of online users has reached the upper limit, the rate limiting service center can determine whether the number of people in the queue has reached the queue limit. For example, the rate limiting service center can use a ZCARD queue:<game_id> The command retrieves the number of people in the queue and compares it to the queue limit. When the number of people in the queue has not reached the limit, the rate limiting service center can add the player account ID corresponding to the client to the queue and return the queue status information to the client through the business server. When the number of people in the queue reaches the queue limit, the rate limiting service center can return a login request rejection message to the client through the business server.

[0080] Figure 6 This is an exemplary flowchart illustrating another game rate limiting method according to some embodiments of this specification. Figure 6 The process 600 shown can be executed by a computer device, for example, by... Figure 1 The client 120 shown executes this. In some embodiments, process 600 may be implemented by a game rate limiting device 800 deployed on a computer device. Figure 6 As shown, in some embodiments, process 600 may include the following steps.

[0081] Step 610: Send a login request to the server. In some embodiments, step 610 can be implemented by the login request sending module 810.

[0082] In some embodiments, a login request can be used to instruct the server to determine whether to allow login based on the number of online users, and to return an authentication token containing an expiration time if login is allowed. In some embodiments, the user can log in through the client's graphical user interface, for example, by clicking the login icon in the graphical user interface of client 120. Client 120 can respond to this login operation by sending a login request to server 110. After receiving the login request from client 120, server 110 can first query the number of online users and determine whether to allow login based on the number of online users. If the number of online users in the game has not reached the limit, login is allowed; if the number of online users in the game has reached the limit, login is not allowed, and server 110 can add the player account identifier corresponding to client 120 to the queue, waiting to log in to the game. This can effectively control the number of online users and avoid system overload. For more details on determining whether to allow login based on the number of online users, please refer to the description in process 400 above.

[0083] In some embodiments, if login is allowed, the server may send an authentication token containing an expiration time to the client. For a detailed explanation of this part, please refer to the description in step 220 above, which will not be repeated here.

[0084] Step 620: Send a service request containing an authentication token to the server. In some embodiments, step 620 can be implemented by the service request sending module 820.

[0085] In some embodiments, a service request can be used to instruct the server to update the authentication token based on the expiration time in the authentication token. For example, after receiving a service request containing an authentication token from a client, the server can update the authentication token based on the expiration time in the authentication token. For a detailed explanation of this part, please refer to the description in step 230 above, which will not be repeated here.

[0086] In some embodiments, the number of online users can be updated based on the number of unexpired authentication tokens, which can be determined based on the expiration time in the status information. For example, the server can delete the status information corresponding to expired authentication tokens from the status information table at preset time intervals, and update the number of online users based on the status information corresponding to unexpired authentication tokens in the status information table. For a detailed explanation of this part, please refer to the description in step 240 above, which will not be repeated here.

[0087] This manual also provides a game traffic limiting device. Figure 7 This is an exemplary block diagram of a game rate limiting device according to some embodiments of this specification. In some embodiments, the game rate limiting device 700 may be deployed on a computer device. For example, the game rate limiting device 700 may be deployed on a computer device such as... Figure 1 In server 110 shown. For example... Figure 7 As shown, in some embodiments, the game traffic limiting device 700 may include a login request receiving module 710, an authentication token sending module 720, an authentication token updating module 730, and a player count updating module 740.

[0088] The login request receiving module 710 can be used to receive login requests from clients and determine whether to allow login based on the number of online users.

[0089] The authentication token sending module 720 can be used to send an authentication token containing an expiration time to the client if login is allowed.

[0090] The authentication token update module 730 can be used to receive a business request containing an authentication token from a client and update the authentication token based on the expiration time in the authentication token.

[0091] The user update module 740 can be used to update the number of online users based on the number of authentication tokens that have not expired.

[0092] In some optional embodiments, the login request receiving module 710 can also be used to determine whether the number of online users has reached the upper limit when a login request is received from the client; if the number of online users has not reached the upper limit, login is allowed; if the number of online users has reached the upper limit, the player account identifier corresponding to the client is added to the queue.

[0093] In some optional embodiments, the login request receiving module 710 can also be used to: determine whether the number of people in the queue has reached the queuing limit when the number of online users reaches the limit; add the player account identifier corresponding to the client to the queue when the number of people in the queue has not reached the queuing limit; and reject the login request when the number of people in the queue reaches the queuing limit.

[0094] In some optional embodiments, the login request receiving module 710 can also be used to add the player account identifier corresponding to the client to the queuing queue, and determine the ranking of the player account identifier in the queuing queue based on at least one of the following information: the player account's level, the player account's corresponding payment information, the time of joining the queuing queue, and random weight.

[0095] In some optional embodiments, the game flow limiting device 700 may further include a queue information sending module 750 for sending queue information to the client. The queue information may include at least one of the following: total number of people in the queue, rank in the queue, and estimated waiting time; wherein the estimated waiting time is determined based on the rank in the queue.

[0096] In some optional embodiments, the game throttling device 700 may further include a login success confirmation module 760, which is used to confirm successful login when a login confirmation message is received from the client before the expiration time after sending an authentication token containing an expiration time to the client.

[0097] In some optional embodiments, the authentication token update module 730 can also be used to receive a business request containing an authentication token from a client and verify the validity period of the authentication token; when the authentication token has expired or is within a preset time range before expiration, update the expiration time in the authentication token.

[0098] In some optional embodiments, the authentication token update module 730 can also be used to: receive a business request containing an authentication token from a client, and when there is no status information corresponding to the authentication token in the status information table, if the number of online players reaches the maximum limit, log off the player account corresponding to the client; if the number of online players does not reach the maximum limit, respond to the business request and update the expiration time in the authentication token and the status information in the status information table.

[0099] In some optional embodiments, the authentication token sending module 720 can also be used to send an authentication token containing an expiration time to the client and establish status information corresponding to the authentication token in a status information table. The status information includes the expiration time of the authentication token and the player account identifier. Updating the number of online users based on the number of unexpired authentication tokens includes: deleting the status information corresponding to expired authentication tokens in the status information table based on a preset time interval; and updating the number of online users based on the status information corresponding to unexpired authentication tokens in the status information table. The status information corresponding to unexpired authentication tokens in the status information table can represent the number of unexpired authentication tokens.

[0100] This manual also provides another game traffic limiting device. Figure 8 This is an exemplary block diagram of a game rate limiting device according to some embodiments of this specification. In some embodiments, the game rate limiting device 800 may be deployed on a computer device. For example, the game rate limiting device 800 may be deployed on a computer device such as... Figure 1 In client 120 shown. (As shown) Figure 8 As shown, in some embodiments, the game traffic limiting device 800 may include a login request sending module 810 and a service request sending module 820.

[0101] The login request sending module 810 is used to send a login request to the server. The login request is used to instruct the server to determine whether to allow login based on the number of online users, and to return an authentication token containing an expiration time when login is allowed.

[0102] The business request sending module 820 is used to send a business request containing an authentication token to the server. The business request is used to instruct the server to update the authentication token based on the expiration time in the authentication token. The number of online users is updated based on the number of authentication tokens that have not expired.

[0103] This manual also provides a game traffic limiting system. Figure 9 This is an exemplary block diagram of a game traffic limiting system according to some embodiments of this specification. For example... Figure 9 As shown, in some embodiments, the game traffic limiting system 900 may include a client 910 and a server 920. In some embodiments, the client 910 may be as follows: Figure 1 The client 120 is shown. The server 920 can be as follows: Figure 1 The server shown is 110.

[0104] Client 910 is used to send login requests and business requests containing authentication tokens to the server.

[0105] Server 920 is used to receive login requests from clients, determine whether to allow login based on the number of online users, and if login is allowed, send an authentication token containing an expiration time to the client; in response to a business request from the client containing an authentication token, it updates the authentication token based on the expiration time in the authentication token, and updates the number of online users based on the number of non-expired authentication tokens.

[0106] For more information on each module, please refer to [link / reference]. Figures 2-6 The relevant explanations will not be repeated here. It should be understood that... Figures 7-9 The apparatus, system, and modules illustrated can be implemented in various ways. For example, in some embodiments, they can be implemented by hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by an appropriate instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the methods, apparatus, and systems described above can be implemented using computer-executable instructions and / or included in the control code of a processor, such as code provided in the memory of a programmable device on a media such as a disk, CD, or DVD-ROM. The apparatus and modules described in this specification can be implemented not only by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips or transistors, or programmable hardware devices such as field-programmable gate arrays or programmable logic devices, but also by software, for example, executed by various types of processors, or by a combination of the aforementioned hardware circuitry and software (e.g., firmware).

[0107] It should be noted that the above descriptions of the devices, systems, and modules are for convenience only and should not be construed as limiting this specification to the embodiments described. It is understood that those skilled in the art, after understanding the principle of the device, can arbitrarily combine the various modules without departing from this principle to form sub-devices connected to other modules. Alternatively, some modules can be split to obtain more modules or multiple units under a single module. Such modifications are all within the scope of this specification.

[0108] Some embodiments of this specification also provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement this specification. Figures 2-6 The method shown.

[0109] Some embodiments of this specification also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, can implement this specification. Figures 2-6 The method shown.

[0110] Some embodiments of this specification also provide a computer program product, including a computer program that, when at least a portion of the computer program is executed by a processor, can implement this specification. Figures 2-6 The method is illustrated. In some embodiments, the computer program product may refer only to a computer program, which may be carried on a storage medium or a computer device. In other embodiments, the computer program product may also be a storage medium or a computer device containing the aforementioned computer program. The computer device may include one or more processors, and a storage medium.

[0111] In some embodiments, the processor may be a combination of one or more of the following processors: central processing unit (CPU), application-specific integrated circuit (ASIC), application-specific instruction set processor (ASIP), graphics processing unit (GPU), physical processing unit (PPU), digital signal processor (DSP), field-programmable gate array (FPGA), programmable logic device (PLD), programmable logic controller (PLC), reduced instruction set computer (RISC), and microprocessor.

[0112] In some embodiments, the storage medium may include one or more combinations of the following: mass storage, removable storage, volatile read-write memory, and read-only memory (ROM). Exemplary mass storage may include disks, optical disks, solid-state drives, etc. Exemplary removable storage may include flash drives, floppy disks, optical disks, memory cards, compressed hard disks, magnetic tapes, etc. Exemplary volatile read-write memory may include random access memory (RAM). Exemplary RAM may include dynamic random access memory (DRAM), dual data rate synchronous dynamic random access memory (DDRSDRAM), static random access memory (SRAM), silicon controlled retrieval memory (T-RAM), and zero-capacitance memory (Z-RAM), etc. Exemplary read-only memory may include masked read-only memory (MROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), compressed hard disk read-only memory (CD-ROM), and digital multifunction hard disk read-only memory, etc.

[0113] The basic concepts have been described above. It is obvious that the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, various modifications, improvements, and corrections may be made to this specification by those skilled in the art. Such modifications, improvements, and corrections are taught in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

Claims

1. A method for limiting game traffic, characterized in that, The method includes: Receive login requests from clients and determine whether to allow login based on the number of online users; If login is allowed, send an authentication token containing the expiration time to the client; Receive a business request from the client containing the authentication token, and update the authentication token based on the expiration time in the authentication token; The number of online users is updated based on the number of valid authentication tokens.

2. The method according to claim 1, characterized in that, Receiving a login request from a client and determining whether to allow login based on the number of online users includes: Upon receiving a login request from the client, determine whether the number of online users has reached the maximum limit. Login is allowed when the number of online users has not reached the maximum limit. When the number of online users reaches the maximum limit, the player account ID corresponding to the client is added to the queue.

3. The method according to claim 2, characterized in that, When the number of online users reaches the maximum limit, the player account identifier corresponding to the client is added to the queue, including: When the number of online users reaches the maximum limit, determine whether the number of people in the queue has reached the maximum limit. When the number of people in the queue has not reached the queue limit, the player account identifier corresponding to the client is added to the queue; When the number of people in the queue reaches the queue limit, the login request is rejected.

4. The method according to claim 2 or 3, characterized in that, Adding the player account identifier corresponding to the client to the queue includes: The player account identifier corresponding to the client is added to the queue, and the ranking of the player account identifier in the queue is determined based on at least one of the following information: the player account's level, the player account's payment information, the time of joining the queue, and random weight.

5. The method according to claim 2 or 3, characterized in that, Also includes: Send queuing information to the client, the queuing information including at least one of the following: total number of people in the queue, rank in the queue, and estimated waiting time; The estimated waiting time is determined based on the queue ranking.

6. The method according to claim 1, characterized in that, After sending an authentication token containing the expiration time to the client, the process also includes: When a login confirmation message is received from the client before the expiration time, the login is confirmed to be successful.

7. The method according to claim 1, characterized in that, The step of receiving a service request from a client containing the authentication token and updating the authentication token based on the expiration time in the authentication token includes: Receive a service request containing the authentication token from the client, and verify the validity period of the authentication token; When the authentication token has expired or is within a preset time range from the expiration time, update the expiration time in the authentication token.

8. The method according to claim 1, characterized in that, Sending an authentication token containing an expiration time to the client includes: Send the authentication token containing the expiration time to the client, and establish the status information corresponding to the authentication token in the status information table. The status information includes the expiration time of the authentication token and the player account identifier. The update of the number of online users based on the number of unexpired authentication tokens includes: Based on a preset time interval, delete the status information corresponding to the expired authentication token in the status information table; The number of online users is updated based on the status information corresponding to the unexpired authentication tokens in the status information table, wherein the status information corresponding to the unexpired authentication tokens in the status information table can represent the number of unexpired authentication tokens.

9. The method according to claim 8, characterized in that, Also includes: If a service request containing an authentication token is received from the client, and the status information table does not contain status information corresponding to the authentication token, and the number of online users reaches the maximum limit, the player account corresponding to the client will be logged off. If the number of online users has not reached the maximum limit, respond to the business request and update the expiration time in the authentication token and the status information in the status information table.

10. A method for limiting game traffic, characterized in that, The method includes: Send a login request to the server, the login request being used to instruct the server to determine whether to allow login based on the number of online users, and to return an authentication token containing an expiration time when login is allowed; Send a service request containing the authentication token to the server, the service request being used to instruct the server to update the authentication token based on the expiration time in the authentication token; The number of online users is updated based on the number of authentication tokens that have not expired.

11. A game traffic limiting device, characterized in that, The device includes: The login request receiving module is used to receive login requests from clients and determine whether to allow login based on the number of online users. An authentication token sending module is used to send an authentication token containing an expiration time to the client if login is allowed; The authentication token update module is used to receive a business request from the client containing the authentication token, and update the authentication token based on the expiration time in the authentication token; The user update module is used to update the number of online users based on the number of authentication tokens that have not expired.

12. A game traffic limiting system, characterized in that, The system includes a client and a server. The client is used to send a login request and a business request containing an authentication token to the server. The server is configured to receive the login request from the client, determine whether to allow login based on the number of online users, and if login is allowed, send an authentication token containing an expiration time to the client. In response to the business request from the client containing the authentication token, the authentication token is updated based on the expiration time in the authentication token, and the number of online users is updated based on the number of non-expired authentication tokens.

13. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, it is able to implement the method as described in any one of claims 1 to 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, enable the implementation of the method as described in any one of claims 1 to 10.

15. A computer program product, characterized in that, It includes a computer program that, when at least a portion of the computer program is executed by a processor, enables the implementation of the method as described in any one of claims 1 to 10.

Images