Connection with access service node and request processing method, device and storage medium

Abstract

The application discloses a connection and request processing method and device of an access service node and a storage medium, and relates to the technical field of network communication. The method comprises the following steps: after starting, a configuration file is pulled from a remote configuration storage end and loaded as a running parameter; node information is generated, written into Redis, and an expiration time is set, and the node information and the expiration time are periodically refreshed at a heartbeat interval; remote configurations are periodically pulled, and when the versions are inconsistent, a new configuration is hot-loaded; a client connection heartbeat is received and recorded in a Sorted Set of Redis, and a timeout connection is periodically scanned and cleaned up; a client custom binary protocol packet is parsed, and after login state verification, the packet is routed and forwarded to a business service end according to a message number; an HTTP response is received and encapsulated and written back to the client. Through unified management of node state synchronization, configuration hot loading, double heartbeat isolation and protocol-level authentication, the technical effects of unified cooperation of the access layer from state fragmentation, configuration change without restart and independent isolation of the fault domain are achieved.

Description

Technical Field

[0001] This application relates to the field of game server technology, and in particular to a method, device and storage medium for connecting and processing requests to access server nodes. Background Technology

[0002] In massively multiplayer online games (MMORPGs), the access layer acts as the hub between clients and business services, undertaking core responsibilities such as connection management, protocol parsing, traffic scheduling, and security protection. With the continuous expansion of the player base and the increasing complexity of business logic, the access layer is facing increasingly severe technical challenges in areas such as high-concurrency connection handling, elastic scaling capabilities, and operational observability.

[0003] To alleviate connection pressure and improve availability, the access layer typically employs a multi-node deployment approach. However, in a multi-node environment, node status awareness and traffic allocation present significant challenges: Firstly, business services cannot promptly ascertain the liveness status of each access node, and faulty nodes are difficult to remove in a timely manner, leading to incorrect allocation of connection requests. Secondly, the real-time load of each node lacks an effective synchronization mechanism, making it impossible for business services to perceive differences in node load when selecting access nodes, easily causing load skew. Furthermore, player connection activity detection needs to be managed separately from node liveness detection; mixing the two will amplify the impact of faults and increase the complexity of system maintenance.

[0004] Configuration management at the access layer also faces numerous constraints. Storing configuration files locally or deploying them with the code means that any configuration change requires restarting the service process to take effect, which interrupts all online connections, severely impacting the player experience. Even with mitigation measures like rolling restarts, connection jitter and service quality degradation cannot be completely avoided. Furthermore, the lack of effective isolation and version management between configurations in different operating environments makes configuration rollback difficult, significantly increasing the risk and complexity of operational tasks.

[0005] At the request processing level, the client and access layer communicate using a custom binary protocol, characterized by high frequency, small packets, and low latency. The access layer needs to accurately parse the protocol header, message number, and packet body content from the binary data stream and dynamically route the request to the corresponding business service based on the message number. During this process, the access layer also needs to simultaneously perform security operations such as login status verification, permission verification, and frequency control, while ensuring that processing performance is not affected. A complete client request needs to traverse three nodes: the client, the access layer, and the business service. The lack of an effective link identifier pass-through mechanism will severely restrict the efficiency of problem localization and performance analysis. Building an access layer architecture with automatic service discovery, dynamic configuration updates, flexible protocol parsing, and end-to-end observability has become a critical technical problem that urgently needs to be solved in the field of online game servers.

[0006] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0007] The main purpose of this application is to provide a method, device and storage medium for connection and request processing of access service nodes, which aims to solve the technical problem of state fragmentation and service interruption caused by the lack of a unified dynamic management mechanism in the game access layer.

[0008] To achieve the above objectives, this application proposes a connection and request processing method for an access service node, applied to an access service node, the method comprising: After the access service node starts, it sends a startup configuration retrieval request to the remote configuration storage terminal, receives the configuration file returned by the remote configuration storage terminal, and loads the configuration items in the configuration file as the running parameters of the access service node. Generate node information, which includes a unique node identifier, IP address, service port, current connection count, and version information; write the node information into the Redis registry and set a first expiration time; periodically rewrite the current node information into the Redis registry and refresh the first expiration time according to a preset first heartbeat interval; The system periodically sends configuration retrieval requests to the remote configuration storage. When it is determined that the version of the configuration file currently loaded locally is inconsistent with the version of the configuration file stored remotely, the system loads the configuration items in the remote configuration file and applies them. Based on the TCP long connection established between the access service node and the client, the connection heartbeat protocol packets sent by the client at regular intervals are received, and the latest heartbeat time of the client is recorded in the Sorted Set structure of the Redis registry. The Sorted Set is scanned at regular intervals, and the connection of clients whose latest heartbeat time exceeds the preset second expiration time is disconnected, and the corresponding login status and access permissions are cleared. In response to the custom binary protocol packet sent by the client, the message body and message number are parsed from the header of the custom binary protocol packet to verify whether the client has logged-in access rights; When it is determined that the client has access rights based on the verification result, the message body is forwarded to the corresponding business server via the internal HTTP protocol according to the message number; Receive the HTTP response returned by the business server, encapsulate the response result into the packet body format of the custom binary protocol, and write it back to the client; In one embodiment, the node information further includes the current number of connections of the access service node, and the step of periodically rewriting the current node information to the Redis registry and refreshing the first expiration time according to a preset first heartbeat interval includes: Each time the node information is rewritten, the current connection count in the node information is updated to the actual connection count of the access service node at the current moment, so that the service server can select a load balancing node based on the current connection count in the node information.

[0009] In one embodiment, after the step of receiving the configuration file returned by the remote configuration storage terminal and loading the configuration items in the configuration file as the running parameters of the access service node, the method further includes: Responding to node query requests sent by the business server; The system returns to the business server all node information of all access service nodes currently stored in the Redis registry center and the first expiration time of each node, so that the business server can filter healthy nodes according to the first expiration time and return the address of the filtered target access service node to the client.

[0010] In one embodiment, after the step of returning to the business server the node information of all access service nodes currently stored in the Redis registry and the first expiration time corresponding to each node, the method further includes: After determining that the client has disconnected, a connection disconnection notification is sent to the service server. The connection disconnection notification carries the client's connection identifier, so that the service server can clear the client's online status and related service data based on the connection identifier.

[0011] In one embodiment, the step of parsing the message body and message number from the header of the custom binary protocol packet sent by the client, and verifying whether the client has logged-in access rights, includes: Obtain the fixed-length header of the custom binary protocol packet, and extract the message number and packet body length from the header; Data corresponding to the packet body length is extracted from the custom binary protocol packet according to the packet body length and used as the message body. Search for the message number in the preset list of login-free protocols; If the message number belongs to a protocol number in the list of login-free protocols, then the login status verification is skipped; If the message number does not belong to the protocol number in the list of login-free protocols, then verify whether the client has logged-in access permissions.

[0012] In one embodiment, the step of forwarding the message body to the corresponding business server via an internal HTTP protocol according to the message number when it is determined that the client has access rights based on the verification result includes: The call address of the business server corresponding to the message number is determined by querying the preset routing mapping table based on the message number. Obtain the connection identifier of the client and the unique node identifier of the access service node, and add the connection identifier and the unique node identifier to the request header of the internal HTTP request; An internal HTTP request carrying the connection identifier and the unique identifier of the node is sent to the calling address so that the business server can process the request and perform link tracing based on the connection identifier and the unique identifier of the node.

[0013] In one embodiment, after the step of sending the internal HTTP request carrying the connection identifier and the node's unique identifier to the calling address, so that the business server can perform request processing and link tracing based on the connection identifier and the node's unique identifier, the method further includes: Obtain the request identifier corresponding to the HTTP response and the connection identifier of the client, and generate a protocol log containing the request identifier, the connection identifier, the message number, and processing time information; The protocol logs are sent to the log producer via the User Datagram Protocol (UDP), and the log producer writes the protocol logs into the log system.

[0014] Furthermore, to achieve the above objectives, this application also proposes a connection and request processing method for an access service node, applied to a client. The connection and request processing method for the access service node includes the following steps: Send an access address retrieval request to the business server; Receive the address information of the target access service node returned by the service server, wherein the address information includes at least the IP address and service port of the target access service node; A long TCP connection is established with the target access service node based on the address information, and a login protocol packet is sent to the target access service node, the login protocol packet carrying a login key; Based on the TCP long connection, connection heartbeat protocol packets are periodically sent to the target access service node at preset heartbeat intervals to maintain the active state of the TCP long connection; Send a custom binary protocol packet to the target access service node. The custom binary protocol packet contains a fixed-length header, and the header contains at least a message number and a packet body length. The system receives a response from the target access service node. The response is data that the target access service node writes back after encapsulating the HTTP response returned by the business server according to the packet body format of the custom binary protocol.

[0015] In addition, to achieve the above objectives, this application also proposes a connection and request processing device for an access service node, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the connection and request processing method for the access service node as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the connection and request processing method for the access service node as described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: The technical solution of this application, after the access service node starts, sends a startup configuration retrieval request to the remote configuration storage, receives the configuration file returned by the remote configuration storage, and loads the configuration items in the configuration file as the running parameters of the access service node; generates node information, which includes a unique node identifier, IP address, service port, current connection count, and version information; writes the node information to the Redis registry and sets a first expiration time, and periodically rewrites the current node information to the Redis registry and refreshes the first expiration time according to a preset first heartbeat interval; periodically sends a configuration retrieval request to the remote configuration storage, and when it is determined that the version of the configuration file currently loaded locally is inconsistent with the version of the configuration file stored remotely, loads the configuration items in the remote configuration file and makes them effective; based on the TCP long connection established between the access service node and the client, receives the connection heartbeat protocol packets sent by the client periodically, and records the latest heartbeat time of the client in the Sorted Set structure of the Redis registry, wherein the Sorted Set is periodically scanned. Set, disconnect clients whose latest heartbeat time exceeds a preset second expiration time, and clear the corresponding login status and access permissions; respond to the custom binary protocol packet sent by the client, parse the message body and message number from the header of the custom binary protocol packet, and verify whether the client has logged-in access permissions; if the verification result determines that the client has access permissions, forward the message body to the corresponding business server via the internal HTTP protocol according to the message number; receive the HTTP response returned by the business server, encapsulate the response result into the packet body format of the custom binary protocol, and write it back to the client.

[0018] The technical solution of this application ensures the high concurrency processing capability of the access layer while realizing unified dynamic management of various management dimensions. It solves the technical problems of lagging state awareness, service interruption required for configuration changes, mixed fault domains and broken link identifiers. It realizes the technical leap of access layer management from decentralized and fragmented to unified collaboration, from configuration restart to hot reloading, and from mixed fault domains to independent isolation. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the connection and request processing method for access service nodes in this application. Figure 2 This is a detailed step diagram of step S50 in one embodiment; Figure 3 This is a flowchart illustrating the second embodiment of the connection and request processing method for access service nodes according to the present invention. Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the connection and request processing method of the access service node in this embodiment of the application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0025] In the field of game access layer services, node management, configuration activation, and request routing mainly follow the technical path of local configuration loading, static node registration, and centralized authentication at the business layer.

[0026] In this type of solution, after the access service node starts, it loads the configuration file locally and statically registers the node information with the registration center. The business server detects node changes by periodically pulling the configuration file or by pushing it from the registration center. Client requests are passed through the access service to the business server to complete login verification. In scenarios with a small number of nodes and fixed business logic, this architecture is simple and easy to deploy. However, it is essentially a decentralized management model with inherent defects: local configuration changes require a process restart to take effect, and restarting will interrupt all online connections; after the node information is statically registered, the business side has difficulty in timely detecting node failures or recovery, and may easily allocate requests to failed nodes; node liveness and single connection activity are detected together, and a single connection anomaly may be misjudged as a node crash, expanding the fault domain; login state verification is all pushed down to the business layer, and the access layer cannot achieve protocol-level traffic control; there is a lack of unified link identifier pass-through, the call chain between the client, access layer and business service is broken, and fault location is difficult.

[0027] The core dilemma faced by the above paths is that the management dimensions of node status reporting, configuration loading, connection detection, and routing forwarding are fragmented. Their characteristics of lagging status awareness, service interruption required for configuration changes, mixed fault domains, and broken link identifiers are fundamentally contradictory to the inherent requirements of the game access layer for high-concurrency long-connection processing, service continuity assurance, and fine-grained routing.

[0028] To address the aforementioned shortcomings, this application proposes a method for handling connection and request processing of access service nodes. After the access service node starts, it first pulls the configuration file from a remote configuration storage and loads it as runtime parameters. Then, it generates node information including a unique node identifier, IP address, service port, and current connection count, writes it to Redis, and sets an expiration time. The node information and expiration time are periodically refreshed at heartbeat intervals, allowing the business side to remove abnormal nodes in real time. Each refresh synchronously updates the current connection count, enabling load-aware node selection. During operation, the remote configuration is periodically pulled, and hot reloading is achieved through version comparison, taking effect without restarting and avoiding connection interruptions. Node liveness and client connection activity are isolated using a dual heartbeat mechanism—node heartbeats prove node liveness, while client heartbeats are independently recorded in a Redis Sorted Set. Periodic scanning disconnects timed-out connections and clears the login status; the two types of heartbeats do not interfere with each other. At the request processing level, the access layer receives custom binary protocol packets, parses the message number and packet length from the fixed-length header, and implements protocol-level differentiated authentication through a list of login-free protocols. Non-login-free protocols require verification of login status before forwarding. The layer queries the routing table based on the message number to determine the business service call address, and passes the connection identifier and node identifier to the HTTP request header for the business end to perform link tracing. After the response is returned, a protocol log containing the request identifier, connection identifier, and processing time is generated and sent asynchronously to the log producer via UDP (User Datagram Protocol) to achieve end-to-end observability.

[0029] This application achieves unified dynamic management of all management dimensions while ensuring high-concurrency processing capabilities at the access layer. It solves the technical problems of lagging state awareness, service interruption required for configuration changes, mixed fault domains, and broken link identifiers. It realizes the technical leap of access layer management from decentralized and fragmented to unified collaboration, from configuration restart to hot reloading, and from mixed fault domains to independent isolation.

[0030] Based on this, embodiments of this application provide a method for connecting and processing requests to an access service node, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the connection and request processing method for access service nodes according to this application. In this embodiment, the connection and request processing method for access service nodes is applied to access service nodes and includes steps S10 to S70: Step S10: After the access service node starts, a startup configuration retrieval request is sent to the remote configuration storage terminal, the configuration file returned by the remote configuration storage terminal is received, and the configuration items in the configuration file are loaded as the running parameters of the access service node. After the access service node starts, it completes the loading of runtime parameters. During startup, its internal initialization module actively initiates a startup configuration pull request to the remote configuration storage. This remote configuration storage can be implemented using Tencent Cloud Object Storage Service. Configuration files are stored in isolation by environment; different runtime environments, such as test, pre-release, and production environments, each have independent configuration files, ensuring that configurations between environments do not interfere with each other. When initiating the pull request, the access service node includes the identifier of the current runtime environment in the request. The remote configuration storage returns the configuration file for the corresponding environment based on this identifier. After receiving the configuration file returned by the remote configuration storage, the access service node performs format validation and integrity checks. Once it confirms that the configuration file is in valid JSON format and contains all necessary configuration items, it loads each configuration item and applies it to the current access service node's runtime environment. These configuration items then become the runtime parameters for the subsequent operation of the access service node.

[0031] The aforementioned operating parameters cover various configuration information required for the normal operation of the access service nodes, including at least the connection address of the Redis (Remote Dictionary Server) registry, the first heartbeat interval, the second expiration time, and the calling address of the business server. The Redis registry connection address is used for subsequent node information registration and heartbeat refresh operations, specifying which Redis instance the access service node writes its information to. The first heartbeat interval controls the frequency at which nodes periodically refresh their own node information and expiration time; the value of this interval needs to comprehensively consider network overhead and the real-time requirements of node status awareness. The second expiration time controls the timeout determination of client connection heartbeats, i.e., how long a client must remain silent before the connection is considered invalid. The calling address of the business server is used to determine which business server instance to send HTTP (Hypertext Transfer Protocol) requests to during subsequent request forwarding. By pulling configurations from a remote configuration storage at startup, all access service nodes obtain consistent configuration information upon startup, avoiding operational problems caused by inconsistent local configuration files on each node, and laying the foundation for centralized management and dynamic updates of subsequent configurations.

[0032] Based on the above processing procedure, after the step of receiving the configuration file returned by the remote configuration storage terminal and loading the configuration items in the configuration file as the running parameters of the access service node, the method further includes: Responding to node query requests sent by the business server; The system returns to the business server all node information of all access service nodes currently stored in the Redis registry center and the first expiration time of each node, so that the business server can filter healthy nodes according to the first expiration time and return the address of the filtered target access service node to the client.

[0033] After the access service node completes the above startup configuration loading and successfully registers its node information with the Redis registry, it can provide access services. When allocating access service nodes to clients, the business server needs to first obtain the list of currently available access service nodes and the health status of each node. When responding to the client's access address acquisition request, the business server sends a node query request to the access service node. This request is used to obtain information on all access service nodes currently registered in the Redis registry. After receiving the node query request from the business server, the access service node queries the Redis registry for the node information of all currently stored access service nodes and the first expiration time corresponding to each node. The node information stored in the Redis registry is stored in a hash structure, with each access service node corresponding to a field in the hash. The access service node can obtain the complete information of all nodes using the HGETALL command. The first expiration time corresponding to each node is obtained through the Redis TTL command. This expiration time reflects the remaining lifespan of each node after the last heartbeat refresh.

[0034] The access service node returns all queried node information and the first expiration time for each node to the business server. Upon receiving this list of node information, the business server determines the health status of each node based on its first expiration time. Specifically, the business server compares the current system time with the first expiration time of each node. If the current system time has exceeded the node's first expiration time, it means the node has exceeded its preset validity period since the last heartbeat refresh. The node may have crashed or experienced network partitioning preventing normal heartbeat refreshes, and the business server classifies this node as an abnormal node and removes it from the candidate list. If the current system time has not exceeded the node's first expiration time, it means the node is still continuously refreshing its heartbeat and is in a healthy, active state, and the business server retains this node in the candidate list. Through this passive filtering mechanism based on expiration time, the business server can accurately determine the health status of each node without actively sending probe requests to the access service node. The business server selects a target access service node from the filtered list of healthy nodes according to a preset load balancing strategy. This load balancing strategy can use round-robin, random, or weighted methods based on the current number of connections of each node. Then, it returns the IP address (Internet Protocol) and service port of the target access service node to the client. Upon receiving this address information, the client can establish a TCP (Transmission Control Protocol) long connection with the target access service node. Through this node query and filtering mechanism, the business server reads node information from the Redis registry in real time each time a node is allocated, without establishing a local cache. This avoids the inconsistency in node status caused by caching, ensuring that the client can always connect to a currently healthy access service node.

[0035] Furthermore, after the step of returning to the business server the node information of all access service nodes currently stored in the Redis registry center and the first expiration time corresponding to each node, the method further includes: After determining that the client has disconnected, a connection disconnection notification is sent to the service server. The connection disconnection notification carries the client's connection identifier, so that the service server can clear the client's online status and related service data based on the connection identifier.

[0036] Based on the aforementioned node query and allocation mechanism, the access service node also needs to proactively notify the business server when the client's connection status changes, ensuring that the online status data maintained by the business server remains consistent with the actual connection status. During operation, the access service node continuously monitors the status of each client's TCP long connections. When the access service node detects that a client's connection has been broken, it determines that the client has disconnected. There may be various reasons for a client connection to break, including the client actively closing the connection, network anomalies causing connection interruption, or the client being actively removed by the access service node due to heartbeat timeout. Regardless of the cause of the connection break, the access service node must notify the business server of this event so that the business server can promptly clean up the client's related online status and business data.

[0037] After determining that a client has disconnected, the access service node constructs a connection disconnection notification message, which carries the client's connection identifier. This connection identifier is a unique identifier assigned by the access service node when the client establishes a connection and remains unchanged throughout the connection's lifecycle. Both the access service node and the business server use this connection identifier to associate and track requests from the same client. The access service node sends this connection disconnection notification message to the business server. This notification can be sent via an internal HTTP interface or through a pre-established messaging channel with the business server. Upon receiving the connection disconnection notification, the business server uses the connection identifier carried in the notification to find the player information and online status data corresponding to the client. After confirming that the client corresponding to the connection identifier is indeed online, the business server performs online status cleanup operations, including marking the client's login status as offline, removing the player from the online player list, and clearing the player's cached session data and temporary status data in the business server's memory. Furthermore, the business server can also trigger subsequent business processing flows based on this connection disconnection notification, such as notifying the player's friends that the player has gone offline or triggering status reset operations in the disconnection reconnection process. Through this proactive connection disconnection notification mechanism, the business server does not need to rely on its own heartbeat detection or timeout judgment to detect connection disconnection. It can be notified of the event almost simultaneously with the connection disconnection and perform state cleanup in a timely manner. This effectively avoids problems such as player duplicate login conflicts and state data disorder caused by residual expired online state data in the business server, and ensures the eventual consistency between the online state data maintained by the business server and the actual connection state of the access server node.

[0038] Step S20: Generate node information, which includes a unique node identifier, IP address, service port, current connection count, and version information; write the node information into the Redis registry and set a first expiration time; periodically rewrite the current node information into the Redis registry and refresh the first expiration time according to a preset first heartbeat interval; After loading the aforementioned runtime parameters, the access service node begins generating and registering node information. The access service node first collects its own runtime status information to generate complete node information, including a unique node identifier, IP address, service port, current connection count, and version information. The unique node identifier is used to uniquely distinguish different access service nodes in the Redis registry. It can use a UUID (Universally Unique Identifier) ​​or a string generated according to specific rules at node startup to ensure global uniqueness. The IP address is the internal or external IP address of the machine where the access service node resides, and the service port is the listening port number for the node to provide TCP long connection services. These two fields together constitute the address information required for clients to connect to the access service node. The current connection count is initially 0 at node startup and is continuously updated with heartbeat refreshes. The version information includes the access service node's build version number and code version number, facilitating quick identification of the program version currently running on the node during online operations and maintenance.

[0039] After generating the node information, the access service node writes this information to the Redis registry and sets a first expiration time. In the Redis registry, node information can be stored using a hash structure. Each access service node corresponds to a field in the hash structure, where the key is the node's unique identifier, and the value is a JSON (JavaScript Object Notation) string containing detailed node information. The first expiration time controls the validity period of the node information. If the access service node does not refresh this expiration time for an extended period, the Redis registry will automatically mark the node information as expired or even delete it. The business server can use this expiration time to determine if the node is still alive when reading node information. After the node information is written, the access service node periodically rewrites the current node information to the Redis registry and refreshes the first expiration time according to a preset first heartbeat interval. During each heartbeat refresh, the access service node updates the actual number of connections at the current moment to the node information, allowing the business server to perceive the real-time load of each access service node based on this field. This enables load-aware node selection during node allocation, preventing new connections from continuously flooding into high-load nodes. By actively writing and periodically refreshing, access service nodes continuously prove their liveness to the Redis registry. Business servers do not need to actively probe the node status; they only need to read the node information from the Redis registry and check the expiration time to know the health status of each node.

[0040] Step S30: Periodically send configuration retrieval requests to the remote configuration storage terminal. When it is determined that the version of the configuration file currently loaded locally is inconsistent with the version of the configuration file stored remotely, load the configuration items in the remote configuration file and apply them. During operation, the access service node needs to continuously monitor changes in the remote configuration to ensure timely application of new configurations without restarting the service process. Internally, the access service node maintains a scheduled task that sends configuration fetch requests to the remote configuration storage at preset time intervals. This time interval can be set to a value different from the first heartbeat interval. Since configuration changes typically occur less frequently than the node's heartbeat frequency, the configuration fetch interval can be set relatively long, such as fetching once per minute, to reduce access pressure on the remote configuration storage. When initiating a configuration fetch request, the access service node includes a version identifier of the currently loaded configuration file in the request. This version identifier can be the configuration file's modification time, version number, or content digest value. Upon receiving the fetch request, the remote configuration storage compares the version identifier carried in the request with the actual version identifier of the configuration file in the remote storage.

[0041] If the comparison results are consistent, it means the remote configuration file has not changed since the last fetch, and the access service node does not need to perform any operations; it can simply wait for the next scheduled fetch. If the comparison results are inconsistent, it means the remote configuration file has been updated. In this case, the access service node downloads the complete configuration file content from the remote configuration storage. Before loading and applying the new configuration, the access service node performs format validation and integrity checks on the downloaded configuration file to confirm that it is in valid JSON format and contains all necessary configuration items. After successful validation, the access service node applies each configuration item in the new configuration to the current runtime environment, replacing the old configuration items currently loaded locally. The entire loading and application process is completed within the running process of the access service node, without needing to stop or restart the access service node process. Through this version comparison and hot-reload mechanism, configuration changes can take effect without interrupting any client connections. Operations personnel only need to update the configuration file on the remote configuration storage, and all access service nodes automatically obtain the new configuration and apply it in their next fetch cycle, achieving zero-awareness of configuration changes for the business.

[0042] Step S40: Based on the TCP long connection established between the access service node and the client, receive the connection heartbeat protocol packets sent by the client periodically, and record the latest heartbeat time of the client in the Sorted Set structure of the Redis registry. The Sorted Set is scanned periodically, and the client connection with the latest heartbeat time exceeding the preset second expiration time is disconnected and the corresponding login status and access permissions are cleared. During operation, the access service node needs to manage two different types of heartbeats: one is the node's own heartbeat sent to the Redis registry center, proving that the access service node process itself is alive; the other is the connection heartbeat between the client and the access service node, proving that a specific client's TCP long connection is still active. These two types of heartbeats are managed from different perspectives: the node heartbeat targets the access service node as a whole, while the client connection heartbeat targets each client connection on the access service node. They must be managed independently and cannot be mixed. After the access service node establishes a TCP long connection with the client, the client will periodically send connection heartbeat protocol packets to the access service node at preset heartbeat intervals. These connection heartbeat protocol packets are distinguished from business protocol packets by their message numbers, allowing the access service node to identify that it is a heartbeat packet rather than a business request based on the message number.

[0043] After receiving a connection heartbeat packet from a client, the access server node records the client's latest heartbeat time in a Sorted Set structure in the Redis registry. In this Sorted Set, each client connection corresponds to a member, where the member's value is the client's unique connection identifier, and the member's score is the timestamp of the client's most recent heartbeat. When recording the heartbeat time, the access server node uses the ZADD command to write the client connection identifier as the member and the current timestamp as the score into the Sorted Set. If the member already exists, the ZADD command automatically updates its score to the new timestamp. Internally, the access server node also maintains a scheduled scanning task that scans the Sorted Set at preset time intervals. During the scan, the ZRANGEBYSCORE command is used to retrieve all members whose scores are less than the current time minus the second expiration time. The client connections corresponding to these members have exceeded the maximum allowed heartbeat interval and are considered invalid. For these timed-out client connections, the access service node proactively disconnects the persistent TCP connection with the client and clears the login state and access permission information corresponding to the connection from memory and Redis, ensuring that the connection can no longer send business requests. By storing node heartbeats and client connection heartbeats in different data structures in Redis, the fault domains of the two types of heartbeats are effectively isolated. The heartbeat timeout of a single client connection will not affect the overall liveness determination of the access service node, nor will the heartbeat timeout of a single access service node affect the heartbeat management of client connections on other nodes.

[0044] Step S50: In response to the custom binary protocol packet sent by the client, parse the message body and message number from the header of the custom binary protocol packet, and verify whether the client has logged-in access rights; After receiving a data packet from the client, the access service node needs to parse the packet according to the custom binary protocol format agreed upon by both parties. All protocol packets transmitted between the client and the access service node use a unified binary format. Each packet consists of a fixed-length header and a variable-length body. The header contains two core fields: a message number and a body length. The message number identifies the specific business operation type represented by the packet, and the body length indicates the number of bytes in the body following the header. The header length is fixed, for example, it can be designed to be 4 bytes or 8 bytes. When reading data from the TCP connection, the access service node first reads the fixed-length header data, and then extracts the values ​​of the message number and body length fields from the header according to the custom binary protocol format specification. After extracting the body length, the access service node continues to read the number of bytes specified by the body length from the TCP connection as the message body content.

[0045] After parsing the protocol packet, the access server node needs to verify whether the client has logged-in access permissions. This verification process specifically includes: the access server node first queries a pre-defined list of protocols that do not require login based on the parsed message number. This list records all protocol numbers that can be accessed without login, such as the login request protocol itself, heartbeat protocols, etc. If the current message number belongs to a protocol number in the list of protocols that do not require login, the access server node skips the login state verification and directly allows the protocol packet to enter the subsequent processing flow. If the current message number does not belong to a protocol number in the list of protocols that do not require login, the access server node checks whether the client connection has completed the login process and established a valid login state. The establishment of the login state occurs after the client successfully completes the login verification. The access server node records the client connection's logged-in status and the corresponding player information in its local memory. If the access server node finds that the client has not logged in but has sent a business protocol packet that requires login to access, it rejects the request, does not forward it to the business server, and can return an error response or directly disconnect the connection according to the policy. By implementing a protocol-level differentiated authentication strategy at the access layer, login state verification is moved to the access layer, preventing unverified requests from reaching the business server and reducing the security processing burden on the business server.

[0046] Step S60: When it is determined that the client has access rights based on the verification result, the message body is forwarded to the corresponding business server via the internal HTTP protocol according to the message number; After completing the login status verification and confirming the client's access permissions, the access service node needs to forward the client's request to the corresponding business service for processing. The access service node first queries a pre-defined routing table based on the parsed message number. This routing table maintains the correspondence between message numbers and business service call addresses. Different message numbers correspond to different business operation types; for example, login message numbers correspond to login services, chat message numbers to chat services, and activity message numbers to activity services. The routing table can be loaded from a configuration file when the access service node starts, or it can be dynamically updated. When the business service is adjusted or a new business type is added, only the routing table needs to be updated; there is no need to modify the access service node's code. The access service node searches the routing table for the corresponding business service call address based on the message number. If no corresponding mapping is found, it indicates that the message number has not been configured correctly or the business has not been deployed. The access service node can record an error log and return a corresponding error response to the client.

[0047] After locating the corresponding business server call address, the access server node needs to construct an internal HTTP request and forward the client's request to it. When constructing the HTTP request, in addition to using the parsed message body as the HTTP request body, the access server node also needs to add additional tracing information to the HTTP request header. Specifically, the access server node obtains the client's connection identifier and its own unique node identifier, and adds these two identifiers to the HTTP request header. The connection identifier uniquely identifies the TCP long connection between the client and the access server node, and the unique node identifier identifies which access server node is handling the request. The access server node sends an internal HTTP request carrying the connection identifier and unique node identifier to the aforementioned call address. After receiving the HTTP request, the business server can extract the connection identifier and unique node identifier from the request header and use these identifiers as the basis for request processing and tracing. When the business server returns an HTTP response after processing, it can also include these identifiers in the response or record them in the business log, thereby establishing a request chain association between the client, access server node, and business server. In this way, basic end-to-end request tracing capabilities can be achieved even without relying on independent distributed tracing systems such as Jaeger (an open-source distributed tracing system) or Zipkin (an open-source distributed tracing system).

[0048] Step S70: Receive the HTTP response returned by the service server, encapsulate the response result into the packet body format of the custom binary protocol, and write it back to the client.

[0049] After sending an internal HTTP request to the business server, the access server node enters a waiting state until it receives an HTTP response from the business server. After processing its business logic, the business server returns the processing result to the access server node in the form of an HTTP response, the body of which contains the complete data of the business server's processing result. Upon receiving this HTTP response, the access server node needs to repackage the response result according to a custom binary protocol's packet body format and then write it back to the client.

[0050] When encapsulating the response, the access service node extracts the processing result data returned by the business server from the HTTP response body, uses it as the body content of a custom binary protocol packet, and then constructs the corresponding protocol header. The message number in the protocol header is the same as the message number of the client's original request or is the response message number corresponding to that request. The packet length is padded according to the actual number of bytes in the packet body. After encapsulation, the access service node sends the complete binary protocol packet to the client through the previously established TCP long connection with the client. This completes a full client request processing flow, which involves the client sending the request, the access service parsing and authenticating, the access service forwarding it to the business server, the business server processing and returning a response, and the access service encapsulating the response and writing it back to the client—a complete closed loop.

[0051] After the response write-back is complete, the access service node can perform some subsequent auxiliary operations to improve system observability. The access service node obtains the request identifier and the client's connection identifier corresponding to the HTTP response, generating a protocol log. This log contains the request identifier, connection identifier, message number, and the complete processing time from request receipt to response write-back. The access service node sends this protocol log to the log producer via the User Datagram Protocol (UDP), which then writes the log to the Kafka (distributed message queue) log system. The advantage of using UDP for log transmission is that even if there are brief fluctuations in the log chain or a slowdown in the log producer's processing speed, it will not block the main business processing flow of the access service node, because UDP is a connectionless protocol, and the sending operation does not wait for the receiver's confirmation response. Through this asynchronous log reporting mechanism, the access service node ensures high performance of the main business chain while also achieving full-chain observability of request processing, making it easier for operations personnel to quickly retrieve relevant logs based on the connection identifier or request identifier to locate problems.

[0052] Based on the above embodiment, the node information further includes the current number of connections of the access service node, and the step of periodically rewriting the current node information to the Redis registry and refreshing the first expiration time according to a preset first heartbeat interval includes: Each time the node information is rewritten, the current connection count in the node information is updated to the actual connection count of the access service node at the current moment, so that the service server can select a load balancing node based on the current connection count in the node information.

[0053] In addition to relatively static configuration data such as unique node identifiers, IP addresses, service ports, and version information, the node information also includes a dynamic field: the current connection count. This field allows the service server to perceive the real-time load of each node when allocating access service nodes to clients, thus enabling load-aware node selection. The current connection count represents the total number of TCP long connections established between the access service node and clients at the current moment. This value changes in real time as new connections are established and existing connections are closed. When the access service node starts generating node information, the current connection count is initialized to 0 because the node has not yet provided connection services. As clients successively establish TCP long connections with the access service node, the current connection count gradually increases; conversely, when a client disconnects, the current connection count decreases accordingly. The access service node maintains an atomic counter in memory. Whenever a new TCP long connection is successfully established, the counter is incremented; whenever a TCP long connection is closed, the counter is decremented. This ensures that the current connection count accurately reflects the actual connection load of the access service node at any given time.

[0054] In the process of periodically rewriting the current node information and refreshing the first expiration time to the Redis registry at a preset first heartbeat interval, in addition to refreshing fields such as the node's unique identifier, IP address, service port, and version information, the current connection count in the node information also needs to be updated. Each time the access service node performs a heartbeat refresh operation, it reads the current value of the atomic counter maintained in memory, which is the actual connection count of the node at the current moment. The access service node fills this actual connection count into the current connection number field of the node information, and then rewrites the complete node information back to the Redis registry. By synchronously updating the current connection count with each heartbeat refresh, the node information stored in the Redis registry always contains a snapshot of the load status of each access service node in the most recent heartbeat cycle. Although this load status snapshot has a delay due to the heartbeat interval, this delay is within an acceptable range for the purpose of load balancing node selection. The access service node continuously updates the current connection count at the heartbeat frequency, enabling the business server to obtain relatively real-time load information of each node when allocating nodes.

[0055] When allocating access service nodes to clients, the business server reads the node information and first expiration time of all access service nodes from the Redis registry. It first filters out healthy nodes based on the first expiration time, then selects a target node from this list and returns it to the client. When selecting from the healthy node list, the business server can read the current connection count field from the node information of each healthy node, using this field as a reference for node selection. The business server can employ various load balancing strategies to implement connection-based node selection. For example, it can directly select the node with the fewest current connections as the target node, which evenly distributes new connections across nodes, preventing a continuous influx of new connections to high-load nodes. Alternatively, it can use a weighted round-robin strategy, selecting nodes based on the reciprocal of their current connection count or a weighted value based on a connection count range. Regardless of the specific balancing strategy used, the current connection count field in the node information serves as the fundamental data input for load balancing decisions, directly impacting the balancing effect of node selection. By continuously updating the current number of connections with each heartbeat, the business server can obtain the latest load status of each node every time it allocates nodes, thus achieving load balancing at the connection allocation level. This effectively avoids the load imbalance problem in multi-node deployment scenarios where some nodes are overloaded while others are idle, improving the resource utilization efficiency and connection service quality of the entire access layer cluster.

[0056] Further, see Figure 2 , Figure 2 This is a detailed step diagram of step S50 in one embodiment. The step of responding to the custom binary protocol packet sent by the client, parsing the message body and message number from the header of the custom binary protocol packet, and verifying whether the client has logged-in access permissions includes S51~S52: Step S51: Obtain the fixed-length header of the custom binary protocol packet, and extract the message number and packet body length from the header; Step S52: Extract data corresponding to the packet body length from the custom binary protocol packet according to the packet body length as the message body; Step S53: Query the message number in the preset list of login-free protocols; Step S54: If the message number belongs to the protocol number in the login-free protocol list, then skip the login status verification; Step S55: If the message number does not belong to the protocol number in the login-free protocol list, then verify whether the client has logged-in access permissions.

[0057] After receiving a custom binary protocol packet from the client, the access service node parses the complete protocol content from the data stream according to the agreed-upon protocol format. When reading data from the TCP connection, the access service node first obtains the fixed-length header of the custom binary protocol packet. This header is located at the very beginning of each protocol packet, and its length is determined during the protocol design phase, typically set to a fixed length of 4, 6, or 8 bytes. After reading a sufficient amount of data from the TCP connection, the access service node extracts two core fields from the header: the message number and the packet body length, according to the field arrangement of the custom binary protocol. The message number occupies a fixed number of bits in the header and is used to identify the specific business operation type corresponding to the protocol packet, such as login request message number, heartbeat message number, chat message number, activity request message number, etc. The packet body length also occupies a fixed number of bits in the header and is used to indicate the number of data bytes in the packet body. After extracting the message number and packet length from the packet header, the access service node extracts the specified number of bytes from the custom binary protocol packet based on the packet length value. This message body contains the business data carried by the protocol packet, and its specific format varies depending on the message number. For example, the message body of a login protocol packet contains the player account and login key, while the message body of a chat protocol packet contains the chat content and the target player identifier. When extracting the message body, the access service node must ensure that the length of the extracted data is exactly the same as the value of the packet length field to guarantee the accuracy of subsequent business processing.

[0058] After parsing the protocol packet and obtaining the message number and message body, the access service node proceeds to the login state verification stage. The specific process of the login state verification stage includes: the access service node first queries a preset list of login-free protocols for the currently parsed message number. This list is loaded from a configuration file when the access service node starts up and records all protocol numbers that allow normal access without client login. Login-free protocols typically include the login request protocol itself, as sending a login request before the client is logged in is a reasonable and necessary process; it also includes connection heartbeat protocol packets, as heartbeats need to be continuously sent before or during login to maintain connection activity; and it may also include protocols for querying public information, depending on business needs. The design of the login-free protocol list allows the access service node to distinguish which requests require login and which requests are allowed to be sent by unlogged-in clients, achieving protocol-level access control granularity. If the access service node finds the current message number in the aforementioned login-free protocol list, it means that the protocol corresponding to that message number belongs to the login-free protocol range. The access service node skips the login state verification and directly submits the protocol packet to the subsequent processing flow for routing and forwarding. Skipping login state verification means that even if the client has not completed the login process, the protocol packet it sends will still be processed normally. This design ensures the smooth progress of the login process itself, because if the login request is intercepted by login state verification before it is processed, it will form an infinite loop where a login state must be present before a login request can be made.

[0059] If the access service node cannot find the current message number in the aforementioned list of login-free protocols, it means that the protocol corresponding to the message number does not belong to the scope of login-free protocols. Access to this protocol requires the client to have already logged in and hold a valid login state. After determining that the message number does not belong to the list of login-free protocols, the access service node checks whether the client has logged-in access permissions. After the client connection is established, the access service node maintains a login state record, which is stored in the local memory of the access service node, using the client's connection identifier as the index key. When the client successfully completes the login process, the access service node marks the client's login state as logged in in this memory record. During login state verification, the access service node queries the client's login state record in its local memory using the current client's connection identifier as the index. If the found login state is logged in, the verification passes, and the access service node continues to execute subsequent routing and forwarding steps. If the found login state is not logged in, or the client does not have a corresponding login state record in memory, the verification fails, the access service node rejects the protocol packet, will not forward it to the business server, and can return an error response to the client or directly disconnect the connection according to a preset policy. By implementing a protocol-level differentiated authentication mechanism that combines a list of login-free protocols with login status verification at the access layer, access control is brought forward to the access layer. All non-login-free business requests are intercepted or allowed before reaching the business server, effectively reducing the processing burden of authentication on the business server and enabling the access layer to have security protection capabilities independent of the business.

[0060] Additionally, the step of forwarding the message body to the corresponding business server via the internal HTTP protocol according to the message number when it is determined that the client has access rights based on the verification result includes: The call address of the business server corresponding to the message number is determined by querying the preset routing mapping table based on the message number. Obtain the connection identifier of the client and the unique node identifier of the access service node, and add the connection identifier and the unique node identifier to the request header of the internal HTTP request; An internal HTTP request carrying the connection identifier and the unique identifier of the node is sent to the calling address so that the business server can process the request and perform link tracing based on the connection identifier and the unique identifier of the node.

[0061] After completing the login status verification and confirming the client's access permissions, the access service node needs to accurately forward the client's business request to the business server capable of handling it. The access service node first queries a pre-defined routing table based on the parsed message number. This routing table is stored in the access service node's memory, loaded from the configuration file upon node startup, and supports dynamic updates via a configuration hot-update mechanism. The routing table records the correspondence between message numbers and business server call addresses; each message number corresponds to a specific business server address. Different message numbers represent different business operation types; for example, login-related message numbers map to the login business service, chat-related message numbers map to the chat business service, and activity-related message numbers map to the activity business service. The design of the routing table enables the access service node to have message number-driven dynamic routing capabilities. When the business server address changes or a new business service type is added, only the mapping entries in the routing table need to be updated without modifying the access service node's code logic. The access service node performs a lookup operation in the routing table using the parsed message number as the key. If the lookup is successful, it obtains the business server call address corresponding to that message number. If the lookup fails, it means that the current message number has not yet been configured with the corresponding business service in the routing table. The access service node can record the error log and adopt the preset default processing strategy, such as returning an error response that the business is unreachable to the client.

[0062] After obtaining the call address of the business server, the access service node needs to construct an internal HTTP request and forward the client's message body to that address. When constructing the internal HTTP request, in addition to using the parsed message body as the HTTP request body, the access service node also needs to add additional tracking information to the HTTP request header. The access service node retrieves the client's connection identifier and its own node unique identifier from its local memory. The connection identifier is assigned by the access service node and bound to the TCP long connection when the client connection is established, while the node unique identifier is generated when the access service node starts and remains unchanged. The access service node adds the connection identifier and node unique identifier to the HTTP request header as predefined field names. These two identifiers are sent along with the request as standard HTTP header fields. The connection identifier allows the business server to know which client connection the request originated from, and the node unique identifier allows the business server to identify which access service node is handling the client connection.

[0063] After constructing the HTTP request, the access service node sends an internal HTTP request carrying a connection identifier and a unique node identifier to the aforementioned calling address. Upon receiving this HTTP request, the business server first extracts the values ​​of the connection identifier and unique node identifier fields from the HTTP request header. The business server uses the connection identifier as the link tracing anchor for this request and records it in the business log during request processing, establishing an association between the business log and the client connection. When the business server needs to actively push messages to the client or perform a kick-out operation during processing, the connection identifier is also used to specify the target client to the access service node. The unique node identifier allows the business server to perceive the specific access service node where the client connection resides. When it needs to send a message to the client, the business server can send the message to the corresponding access service node based on the unique node identifier. Through this request header pass-through mechanism, the request link between the client, access service node, and business server is linked through the connection identifier and unique node identifier, achieving lightweight end-to-end tracing capabilities. The business server can clearly know which client connection and access service node the request originated from when processing any request.

[0064] Furthermore, after the step of sending the internal HTTP request carrying the connection identifier and the unique identifier of the node to the calling address, so that the business server can perform request processing and link tracing based on the connection identifier and the unique identifier of the node, the method further includes: Obtain the request identifier corresponding to the HTTP response and the connection identifier of the client, and generate a protocol log containing the request identifier, the connection identifier, the message number, and processing time information; The protocol logs are sent to the log producer via the User Datagram Protocol (UDP), and the log producer writes the protocol logs into the log system.

[0065] After receiving the HTTP response from the business server and encapsulating the response result to write back to the client, the access service node completes a full client request processing flow. Following this process, the access service node also needs to record and report protocol logs to support subsequent operation and maintenance monitoring and troubleshooting. The access service node obtains the request identifier and the client's connection identifier corresponding to this HTTP response. The request identifier is generated when the access service node receives the client's protocol packet and is used to uniquely identify this request. This identifier can be generated when the access service node constructs the forwarding request and is continuously tracked until the response is returned. The connection identifier is a globally unique identifier for the client's TCP long connection and is used for all requests during the connection's lifetime. Based on the request identifier, connection identifier, message number corresponding to this request, and the complete processing time from receiving the client's protocol packet to the completion of the response write-back, the access service node generates a structured protocol log.

[0066] The protocol log is organized in a structured format, such as JSON or key-value pairs, facilitating subsequent automated parsing and retrieval. The log includes a request identifier to uniquely identify the entire processing chain of the request, a connection identifier to associate the log with a specific client connection, a message number to identify the business operation type corresponding to the request, and processing time information for performance analysis and slow request troubleshooting. After generating the protocol log, the access service node sends it to the log producer via the User Datagram Protocol (UDP). The log producer then writes the received protocol log into the log system. UDP is a connectionless transport layer protocol; its sending operation does not require establishing a connection with the receiving end or waiting for acknowledgment. The sender considers the operation complete simply by sending the datagram. The access service node's use of UDP for log sending ensures that the log sending operation has virtually no performance impact on the main business processing chain. Even if the log producer experiences temporary processing slowdowns or network fluctuations, the access service node's log sending operation will not be blocked, and the request processing and response write-back process of the main business chain remains unaffected. The log producer, acting as an independent service process or cluster, is responsible for receiving protocol log data from multiple access service nodes and writing the received log data into the log system according to a preset format. This log system can employ mature log processing architectures such as the Kafka distributed message queue or the ELK (Elasticsearch, Logstash, Kibana, an open-source log analysis platform composed of Elasticsearch, Logstash, and Kibana) log stack. After being written to the log system, the protocol logs can be quickly retrieved and filtered using a log retrieval platform based on fields such as request identifier, connection identifier, or message number. When troubleshooting request processing issues for specific players, connections, or message numbers, operations personnel can use the request identifier or connection identifier as an index to retrieve the complete request processing chain log from the log system, quickly pinpointing the stage and cause of the problem.

[0067] Furthermore, you can also view Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the connection and request processing method for access service nodes according to the present invention. Figure 3 The connection and request processing method for the access service node is applied to the client and includes steps S80~S130: Step S80: Send an access address acquisition request to the business server; Step S90: Receive the address information of the target access service node returned by the service server. The address information includes at least the IP address and service port of the target access service node. Step S100: Establish a TCP long connection with the target access service node based on the address information, and send a login protocol packet to the target access service node, wherein the login protocol packet carries a login key; Step S110: Based on the TCP long connection, send connection heartbeat protocol packets to the target access service node at preset heartbeat intervals to maintain the active state of the TCP long connection; Step S120: Send a custom binary protocol packet to the target access service node. The custom binary protocol packet contains a fixed-length header, and the header contains at least a message number and a packet body length. Step S130: Receive the response result returned by the target access service node. The response result is the data written back by the target access service node after encapsulating the HTTP response returned by the business server according to the packet body format of the custom binary protocol.

[0068] When a client launches the game and needs to establish communication with the game server, it first needs to obtain an available access server node address. The client sends an access address acquisition request to the business server, requesting the allocation of a suitable access server node. The business server is the core processor of the game's business logic, responsible for client login verification, player data management, and processing of various game services. It also bears the responsibility of allocating access server nodes to clients. When initiating the access address acquisition request, the client can include its own relevant information in the request, such as client version number, channel identifier, and player identifier. This information serves as the basis for the business server to select nodes and make canary routing decisions. After receiving the request, the business server executes the access server node filtering and allocation logic, selecting a target access server node from the currently healthy access server node list according to a preset strategy, and returning the address information of that node to the client. The client receives the target access server node address information returned by the business server. This address information includes at least the target access server node's IP address and service port. The IP address is used to locate the machine where the target access service node is located at the network layer, and the service port is used to locate the service process on the target access service node that is listening for client connections at the transport layer. In addition to the IP address and service port, the above address information may also include auxiliary information such as protocol type indication and connection timeout parameters to help the client better establish and manage the connection with the access service node.

[0069] After obtaining the address information of the target access server node, the client establishes a long TCP connection with the node based on the IP address and service port. Long TCP connections are connection-oriented, reliable transport protocols. The connection establishment process involves a three-way handshake, and once established, a bidirectional, reliable data transmission channel is established between the client and the access server node. Compared to short connections, long connections avoid the overhead of re-establishing a connection for each request, making them particularly suitable for scenarios like games that require frequent bidirectional communication. After the long TCP connection is successfully established, the client sends a login protocol packet to the target access server node, carrying a login key. The login key is generated by the client using a preset algorithm based on the player identifier and the server key. The server key is a shared key agreed upon between the business server and the client, stored only locally on the business server and the client, and not transmitted over the network. When calculating the login key, the client uses the player identifier and the server key as input parameters, employing a hash algorithm or symmetric encryption algorithm to generate a fixed-length key string. The client then inserts this login key into the body data of the login protocol packet, encapsulates it into a complete login protocol packet according to a custom binary protocol format, and sends it to the access server node. After receiving the login protocol packet, the access service node forwards it to the business server for login verification. The business server recalculates the login key using the same algorithm and shared key and compares it with the login key reported by the client. If they match, it means that the client's identity is legitimate and the login is successful. The business server notifies the access service node to establish a login state for the client so that its subsequent business requests can pass the login state verification.

[0070] After establishing a TCP long connection and completing the login process, the client needs to continuously maintain the connection's active state to prevent it from being mistakenly identified as an invalid connection and disconnected due to prolonged network idle time. Based on the established TCP long connection, the client periodically sends connection heartbeat protocol packets to the target access service node at preset heartbeat intervals. The heartbeat interval needs to strike a balance between network overhead and connection keep-alive effectiveness. If the heartbeat interval is too short, a large number of heartbeat packets will consume network bandwidth and access service node processing resources; if the heartbeat interval is too long, connection interruption cannot be detected in a timely manner. The client's heartbeat sending timer is triggered periodically according to the preset heartbeat interval. Each time it is triggered, the client constructs a connection heartbeat protocol packet. The message number of this protocol packet is different from the message number of the business request. When the access service node receives this heartbeat protocol packet, it can identify it as a heartbeat packet based on the message number, thus distinguishing it from a normal business request. The client sends the connection heartbeat packet to the access server node via a persistent TCP connection. Upon receiving the heartbeat packet, the access server node records the client's latest heartbeat time in a Sorted Set structure in the Redis registry for subsequent heartbeat timeout detection and disconnection cleanup. By periodically sending heartbeat packets, the client continuously demonstrates to the access server node that the persistent TCP connection remains active, and can also use the round-trip time of the heartbeat packets to estimate the current network latency.

[0071] When a client needs to perform a business operation, it sends a custom binary protocol packet to the target access service node. This custom binary protocol packet serves as the communication protocol carrier between the client and the access service node, and all business requests are transmitted through this packet. The custom binary protocol packet contains a fixed-length header, which includes at least two core fields: a message number and a packet length. The message number identifies the specific business operation type represented by the packet; different business operations correspond to different message numbers, such as login requests, chat message sending, and activity participation. The packet length indicates the number of bytes in the packet body, allowing the receiver to accurately extract the complete packet body data from the data stream. When constructing the custom binary protocol packet, the client first determines the corresponding message number based on the business operation to be performed. Then, it serializes the specific parameter data required for the business operation into binary format as the packet body data, calculates the number of bytes in the packet body data as the packet length, and finally fills the message number and packet length into the header according to the field order of the fixed-length header. The packet body data is then appended to the header to form the complete custom binary protocol packet. The client sends the protocol packet to the access service node via a TCP long connection. After receiving the protocol packet, the access service node parses it according to the same protocol format, extracts the message number and message body, performs subsequent processing such as login status verification, route mapping and request forwarding, and finally encapsulates the processing result returned by the business server into a response protocol packet and returns it to the client.

[0072] After sending the aforementioned custom binary protocol packet, the client enters a waiting state until it receives a response from the target access server node. This response is data written back by the target access server node after encapsulating the HTTP response returned by the business server according to the packet body format of the custom binary protocol. Upon receiving the HTTP response from the business server, the access server node extracts the processing result data returned by the business server from the HTTP response body, uses this processing result data as the packet body content of the custom binary protocol packet, constructs the corresponding protocol header, assembles it into a complete response protocol packet, and then sends it to the client through the previously established TCP long connection. Upon receiving this response protocol packet, the client extracts the message number and packet length from the packet header according to the custom binary protocol format, extracts the packet body data based on the packet body length, and reconstructs the processing result returned by the business server from the packet body data, completing a complete client request processing loop. The process involves the client constructing and sending a request, the access server parsing and authenticating the request, the access server forwarding the request to the business server, the business server processing the request and returning a response, and the access server encapsulating the response and writing it back to the client. In the above process, the client acts as the initiator of the request and the receiver of the response, together with the access server node and the business server, forming a complete game service communication system.

[0073] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the connection and request processing methods of the access service node in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0074] This application provides a connection and request processing device for an access service node. The connection and request processing device for an access service node includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the connection and request processing method for the access service node in the first embodiment described above.

[0075] The following is for reference. Figure 4 This diagram illustrates a structural schematic of a connection and request processing device suitable for implementing the access service node in the embodiments of this application. The connection and request processing device for the access service node in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 4 The connection and request processing device for the access service node shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0076] like Figure 4As shown, the connection and request processing device of the access service node may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the connection and request processing device of the access service node. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the access service node's connection and request processing equipment to exchange data wirelessly or via wired communication with other devices. Although the figure shows access service node connection and request processing equipment with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems may be implemented alternatively.

[0077] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0078] The access service node connection and request processing device provided in this application, employing the access service node connection and request processing method in the above embodiments, can solve the technical problem of state fragmentation and service interruption caused by the lack of a unified dynamic management mechanism in the game access layer. Compared with the prior art, the beneficial effects of the access service node connection and request processing device provided in this application are the same as those of the access service node connection and request processing method provided in the above embodiments, and other technical features in the access service node connection and request processing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0079] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0080] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0081] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon. The computer-readable program instructions are used to execute the connection and request processing method of the access service node in the above embodiments.

[0082] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0083] The aforementioned computer-readable storage medium may be included in the connection and request processing equipment of the access service node; or it may exist independently and not assembled into the connection and request processing equipment of the access service node.

[0084] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the connection and request processing device of the access service node, the connection and request processing device of the access service node implements the technical content of the connection and request processing method embodiment of the access service node as shown above.

[0085] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0086] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0087] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0088] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the connection and request processing method of the access service node described above. This solves the technical problem of state fragmentation and service interruption caused by the lack of a unified dynamic management mechanism in the game access layer. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the connection and request processing method of the access service node provided in the above embodiments, and will not be elaborated upon here.

Claims

1. A method for connection and request processing of an access service node, characterized in that, Applied to access service nodes, the connection and request processing method for the access service nodes includes the following steps: After the access service node starts, it sends a startup configuration retrieval request to the remote configuration storage terminal, receives the configuration file returned by the remote configuration storage terminal, and loads the configuration items in the configuration file as the running parameters of the access service node. Generate node information, which includes a unique node identifier, IP address, service port, current connection count, and version information; write the node information into the Redis registry and set a first expiration time; periodically rewrite the current node information into the Redis registry and refresh the first expiration time according to a preset first heartbeat interval; The system periodically sends configuration retrieval requests to the remote configuration storage. When it is determined that the version of the configuration file currently loaded locally is inconsistent with the version of the configuration file stored remotely, the system loads the configuration items in the remote configuration file and applies them. Based on the TCP long connection established between the access service node and the client, the connection heartbeat protocol packets sent by the client at regular intervals are received, and the latest heartbeat time of the client is recorded in the Sorted Set structure of the Redis registry. The Sorted Set is scanned at regular intervals, and the connection of clients whose latest heartbeat time exceeds the preset second expiration time is disconnected, and the corresponding login status and access permissions are cleared. In response to the custom binary protocol packet sent by the client, the message body and message number are parsed from the header of the custom binary protocol packet to verify whether the client has logged-in access rights; When it is determined that the client has access rights based on the verification result, the message body is forwarded to the corresponding business server via the internal HTTP protocol according to the message number; The system receives the HTTP response returned by the service server, encapsulates the response result into the packet body format of the custom binary protocol, and writes it back to the client.

2. The connection and request processing method for access service nodes as described in claim 1, characterized in that, The node information also includes the current number of connections of the access service node. The step of periodically rewriting the current node information to the Redis registry and refreshing the first expiration time according to a preset first heartbeat interval includes: Each time the node information is rewritten, the current connection count in the node information is updated to the actual connection count of the access service node at the current moment, so that the service server can select a load balancing node based on the current connection count in the node information.

3. The connection and request processing method for access service nodes as described in claim 1, characterized in that, After the step of receiving the configuration file returned by the remote configuration storage terminal and loading the configuration items in the configuration file as the running parameters of the access service node, the method further includes: Responding to node query requests sent by the business server; The system returns to the business server all node information of all access service nodes currently stored in the Redis registry center and the first expiration time of each node, so that the business server can filter healthy nodes according to the first expiration time and return the address of the filtered target access service node to the client.

4. The connection and request processing method for access service nodes as described in claim 3, characterized in that, After the step of returning to the business server the node information of all access service nodes currently stored in the Redis registry and the first expiration time corresponding to each node, the method further includes: After determining that the client has disconnected, a connection disconnection notification is sent to the service server. The connection disconnection notification carries the client's connection identifier, so that the service server can clear the client's online status and related service data based on the connection identifier.

5. The connection and request processing method for access service nodes as described in claim 1, characterized in that, The step of responding to the custom binary protocol packet sent by the client, parsing the message body and message number from the header of the custom binary protocol packet, and verifying whether the client has logged-in access permissions includes: Obtain the fixed-length header of the custom binary protocol packet, and extract the message number and packet body length from the header; Data corresponding to the packet body length is extracted from the custom binary protocol packet according to the packet body length and used as the message body. Search for the message number in the preset list of login-free protocols; If the message number belongs to a protocol number in the list of login-free protocols, then the login status verification is skipped; If the message number does not belong to the protocol number in the list of login-free protocols, then verify whether the client has logged-in access permissions.

6. The connection and request processing method for access service nodes as described in claim 5, characterized in that, The step of forwarding the message body to the corresponding business server via the internal HTTP protocol according to the message number when it is determined that the client has access rights based on the verification result includes: The call address of the business server corresponding to the message number is determined by querying the preset routing mapping table based on the message number. Obtain the connection identifier of the client and the unique node identifier of the access service node, and add the connection identifier and the unique node identifier to the request header of the internal HTTP request; An internal HTTP request carrying the connection identifier and the unique identifier of the node is sent to the calling address so that the business server can process the request and perform link tracing based on the connection identifier and the unique identifier of the node.

7. The connection and request processing method for access service nodes as described in claim 6, characterized in that, After the step of sending the internal HTTP request carrying the connection identifier and the node's unique identifier to the calling address, so that the business server can perform request processing and link tracing based on the connection identifier and the node's unique identifier, the method further includes: Obtain the request identifier corresponding to the HTTP response and the connection identifier of the client, and generate a protocol log containing the request identifier, the connection identifier, the message number, and processing time information; The protocol logs are sent to the log producer via the User Datagram Protocol (UDP), and the log producer writes the protocol logs into the log system.

8. A method for connection and request processing of an access service node, characterized in that, Applied to the client, the connection and request processing method for the access service node includes the following steps: Send an access address retrieval request to the business server; Receive the address information of the target access service node returned by the service server, wherein the address information includes at least the IP address and service port of the target access service node; A long TCP connection is established with the target access service node based on the address information, and a login protocol packet is sent to the target access service node, the login protocol packet carrying a login key; Based on the TCP long connection, connection heartbeat protocol packets are periodically sent to the target access service node at preset heartbeat intervals to maintain the active state of the TCP long connection; Send a custom binary protocol packet to the target access service node. The custom binary protocol packet contains a fixed-length header, and the header contains at least a message number and a packet body length. The system receives a response from the target access service node. The response is data that the target access service node writes back after encapsulating the HTTP response returned by the business server according to the packet body format of the custom binary protocol.

9. A connection and request processing device for an access service node, characterized in that, The connection and request processing device of the access service node stores a computer program, which, when executed by a processor, implements the connection and request processing method of the access service node as described in any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the connection and request processing method for the access service node as described in any one of claims 1-8.

Images