A method for RPC connection management based on multiplexing and state decoupling

Abstract

The application discloses a kind of RPC connection management methods based on multiplexing and state decoupling, comprising: when receiving multiple interactive mode request messages, multiple interactive mode request messages are distributed to at least one physical connection of physical connection pool, and multiple interactive mode request messages are mounted using at least one physical connection, and are sent to RPC server;RPC client applies a QID for each stateful request message, generates state information in state management layer through QID, and associates QID with its physical connection;RPC client merges stateful request messages and stateless request messages mounted by at least one physical connection, and then sends them to RPC server in batches, and then starts timer;RPC client executes corresponding business callback processing or removes information of all request messages that have timed out according to the timing of timer and the response of each request message from RPC server.

Description

Technical Field

[0001] This invention relates to the field of distributed system communication technology, and in particular to connection management technology in the Remote Procedure Call (RPC) framework, specifically an RPC connection management method based on multiplexing and state decoupling. Background Technology

[0002] In microservices, cloud-native, and large-scale distributed system architectures, inter-service communication is the cornerstone of system construction. Remote Procedure Call (RPC) is one of the most core communication paradigms, widely used in high-performance, high-concurrency scenarios such as e-commerce transactions, financial services, social networks, and real-time data stream processing, including:

[0003] High-concurrency online services: For example, an e-commerce product details page may instantly call dozens of backend services such as inventory, price, and user reviews. Each call requires an independent connection in the traditional model. During peak periods such as "Double Eleven", tens of thousands or even hundreds of thousands of concurrent connections may be established between the client and the service cluster, putting enormous pressure on operating system resources (ports, file descriptors, memory) and server mounting capabilities.

[0004] Long-running queries and data streams: For example, in real-time monitoring, big data analytics, or message push systems, there are numerous M:N (multiplexed) or streaming RPC calls. After a client initiates a query, the server may continuously return data streams for minutes or even hours. These requests monopolize a connection for extended periods, causing a sharp decrease in the number of available connections in the connection pool.

[0005] Hybrid Communication Modes: Modern applications often use a mix of interaction modes, such as synchronous request-response (1:1), asynchronous notification (1:0), and publish-subscribe (M:N). Traditional frameworks often design different connection management strategies for different modes, resulting in high system complexity and difficulty in coordinating and optimizing resources.

[0006] Traditional RPC frameworks face significant challenges in connection management:

[0007] 1. High connection exclusivity and resource consumption: Each request (even a momentary query) typically needs to bind to and exclusively occupy a physical connection until a response is received. In high-concurrency scenarios or when server-side response latency is slow (such as deadlock), this can easily lead to the rapid exhaustion of the client's connection pool, causing system-level blocking.

[0008] 2. State Coupling and Reuse Difficulties: For query-type requests that require long waiting times (such as M:N subscriptions and streaming queries), the business processing state is strongly coupled with the underlying transport connection. The connection is occupied for a long time and cannot be released for other requests to reuse even if there is no data transmission, resulting in resource waste.

[0009] 3. Poor fault tolerance: Misoperation at the business layer (such as sending the same response repeatedly) can directly damage the state machine of the underlying connection, causing the connection to become unavailable and making it difficult to isolate and recover from errors.

[0010] 4. Low transmission efficiency: Each request is written to the network independently, resulting in multiple write system calls. Furthermore, the traditional protocol header design is redundant (e.g., up to 79 bytes), reducing the effective utilization of network bandwidth.

[0011] Existing technologies such as Dubbo's Future and gRPC's deadline mechanism mainly optimize the timeout control of individual requests, but they do not solve the fundamental problem of deep coupling between connection resources and business logic state from an architectural perspective, and cannot achieve efficient reuse of connections and exception isolation. Summary of the Invention

[0012] This invention proposes an RPC connection management method based on multiplexing and state decoupling, aiming to completely solve the problems of high connection resource consumption, complex state maintenance and low transmission efficiency in traditional frameworks.

[0013] The present invention provides an RPC connection management method based on multiplexing and state decoupling, comprising:

[0014] When the RPC client RPC-cli-thread receives a request message for multiple interaction modes, it allocates the request message to at least one physical connection in the physical connection pool, and uses the at least one physical connection to mount the request message for multiple interaction modes and send it to the RPC server RPCsvrthread.

[0015] The RPC client requests a QID for each stateful request message, generates state information in the state management layer using the QID, and associates the QID with its physical connection, wherein the QID is the request ID;

[0016] The RPC client merges stateful and stateless request messages attached to at least one physical connection and sends them in batches to the RPC server, then starts a timer.

[0017] The RPC client executes corresponding business callback processing or removes information from all timed-out request messages based on the timer's timing and the response from the RPC server to each request message.

[0018] Preferably, the physical connection pool is a minimal physical connection pool established by the RPC client and includes multiple physical connections; when a physical connection sends a batch of attached request messages to the RPC server, the RPC client immediately releases the physical connection back to the minimal physical connection pool and saves the sent request records.

[0019] Preferably, the RPC client sends the concurrent request packets attached to a physical connection to the RPC server in batches according to the concurrent request limit (shareConnLimit) of the multiple interaction mode requests attached to a certain physical connection.

[0020] Preferably, when the number of concurrent requests for multiple interaction modes attached to a physical connection is equal to the concurrency limit, the RPC client sends the concurrent request messages attached to the physical connection to the RPC server in batches.

[0021] Preferably, when the number of concurrent requests for multiple interaction modes mounted on a physical connection exceeds the concurrency limit, the RPC client obtains a new physical connection from the minimum physical connection pool, and then uses the obtained new physical connection to mount the interaction mode requests.

[0022] Preferably, when the RPC client receives a new request, it selects the physical connection with the fewest mounting requests and which has not reached the concurrency limit to mount the new request.

[0023] Preferably, when sending request messages in batches, the client merges multiple request messages to be processed on the same physical connection to form a batch data packet. The protocol header of the batch data packet includes port sequence numbers seqID and QID for accurate matching of requests and responses.

[0024] Preferably, the RPC client executes corresponding business callback processing based on the timer's timing and the RPC server's response to each request, including: if the QID in the RPC server's response is not 0, then processing is performed according to the state information stored in the state management layer, and the event loop thread dispatches the request message to the state management layer to execute the corresponding business callback; if the QID in the RPC server's response is 0, then the corresponding business callback is directly executed according to the port sequence number seqID in the response.

[0025] Preferably, the RPC client releases the state information of the QID stored in the state management layer based on the timer's timing and the response from the RPC server to each request message, including: when the timer exceeds the fallback timeout parameter readTimeout and the RPC server does not return a response to the request message, the client notifies the business side to directly clean up the timed-out stateless requests, clean up the related requests of the QID, and release the state information of the QID stored in the state management layer.

[0026] Preferably, clearing stateful and stateless requests includes releasing the concurrency limit quota occupied by timed-out requests on the corresponding physical connection.

[0027] Compared with the prior art, the present invention has the following beneficial technical effects:

[0028] Creatively improves connection reuse and significantly reduces resource consumption: By allowing a single physical connection to concurrently handle multiple logical requests (controlled by shareConnLimit), the traditional one-to-one model is transformed into a many-to-one model. This reduces the number of physical connections required between the client and the cluster by one to three orders of magnitude (e.g., from tens of thousands to hundreds), fundamentally solving the connection pool exhaustion problem.

[0029] Completely decouple connection state from business state to enhance system robustness: By using QID, seqID, and an independent state machine, the lifecycle management of requests is separated from the transmission function of TCP connections. Misoperations such as duplicate responses and abnormal terminations in the business layer only affect the corresponding QID state, without polluting or interrupting the underlying physical connection, greatly enhancing the system's fault tolerance.

[0030] Achieve unified scheduling of multiple message modes: Innovatively, four typical RPC interaction modes, namely 1:1 (request-response), 1:0 (one-way notification), M:N (streaming / subscription), and 1:0 / 1 (optional response), are scheduled and managed under a unified reusable architecture, which improves the versatility and simplicity of the framework.

[0031] Optimize transmission performance and reduce system load: Employing writev for batch writing reduces the number of system calls, and simplifying the protocol header reduces network overhead. Combined with a significant reduction in the number of connections, this drastically reduces the number of active sockets that need to be scheduled in the operating system kernel, significantly improving network processing efficiency. Overall transmission performance is expected to improve by more than 30%.

[0032] It has dynamic self-healing capabilities: The dynamic timeout mechanism with pressure awareness enables the system to automatically remove zombie requests when under high load or when the backend is abnormal, preventing local failures from spreading into global deadlocks and ensuring the overall availability of the system. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the architecture for implementing the RPC connection management method based on multiplexing and state decoupling of the present invention;

[0034] Figure 2 This is a schematic diagram illustrating the merging and receiving of request messages between the RPC client and RPC server of this invention;

[0035] Figure 3 This is a schematic diagram of an RPC connection management method based on multiplexing and state decoupling according to the present invention. Detailed Implementation

[0036] The core idea of ​​this invention is to construct a unified, decoupled, and adaptive connection management system. By introducing a unified multi-mode connection reuse mechanism, a single physical connection can concurrently carry requests of multiple interaction modes, and an adaptive routing algorithm ensures load balancing, thereby significantly reducing the number of physical connections required. Simultaneously, a decoupling mechanism between query state and connection is designed, managing the request lifecycle through an independent state machine and a unique ID, ensuring that the connection serves only as a stateless transmission channel, achieving immediate release of connection resources and complete isolation of business anomalies. Furthermore, dynamic timeout culling and fallback strategies are integrated, intelligently triggering timeout detection and resource reclamation based on system pressure to prevent deadlock propagation. Finally, message sending and receiving optimization is implemented at the transport layer, employing batch writing and simplified protocol header technology to significantly reduce system overhead and improve network throughput. Through the above systematic innovations, this solution achieves optimal utilization of connection resources, fundamentally enhanced system stability, and a leapfrog improvement in overall performance under ultra-high concurrency scenarios.

[0037] See Figure 1 and Figure 2 After receiving a send / receive request, the RPC client RPC-cli-thread first retrieves the currently used connection from the min-heap. If the number of requests attached to that connection has not yet reached the maximum (shareConnLimit), then that connection is used directly for send / receive processing. If the number of requests attached to the first connection in the min-heap has exceeded shareConnLimit, then a new connection is retrieved from the connection pool and used for send / receive processing. The min-heap consists of currently used connections, with the first element being the connection with the fewest send / receive requests.

[0038] After each event loop is triggered, as many requests as possible are attached to the available connection port socket, merged into a batch, and then sent to the other end.

[0039] In order to completely decouple stateful messages from physical connections, a state mechanism was invented, the mechanism of which is as follows.

[0040] 1. Stateful requests (such as queries) request a request ID, or QID, from the RPC client. The RPC client internally sets up state management for this QID.

[0041] 2. The business side uses this QID to register its status with the RPC.

[0042] 3. After receiving a QID-related request, RPC generates state information on the state manager, associates it with the physical connection, and then merges and sends the messages, just like other stateless messages.

[0043] 4. After receiving the response related to QID, RPC looks up the relevant status in the status management through QID, generates a callback, and submits it to the upper-layer business logic.

[0044] 5. The upper-layer business logic then releases the relevant states registered with the QID through the release interface.

[0045] The timeout detection of this invention has two detection methods:

[0046] The first detection method involves each connection (conn) having a timer. After a request is sent to a conn, this timer is either started or reset. If no response is received within a certain time, the request list on the conn is iterated through, timed-out requests are removed, and the business logic is notified. Specifically: For requests with a QID of 0 (stateless requests), the business logic is directly notified. For requests with a QID other than 0, all requests related to that QID need to be cleared, all state information registered on the thread needs to be cleared, and the business logic is notified.

[0047] The second detection method is used when a thread needs to send more requests but cannot obtain a connection. The number of requests on the currently used connections is equal to the shareConnLimit, and the number of established connections has exceeded the threshold. In this case, the in-user-conn heap (the connection pool that is currently sending and receiving requests) is actively detected, and the requests are processed in the same way as the first detection method.

[0048] This invention consists of the following four closely synergistic innovative mechanisms and modes, which form the technological foundation for realizing the aforementioned overall solution:

[0049] 1. Unified multi-mode connection multiplexing and adaptive routing mechanism

[0050] This mechanism abandons the traditional practice of allocating independent connections for different request types, and instead establishes a unified physical connection pool. All connections in the pool have their maximum concurrent request capacity defined by the `shareConnLimit` parameter (default 10, configurable up to 512). The system maintains a min-heap with the current load of a connection (i.e., the number of requests already attached) as the key. When a new request arrives (whether in 1:1, 1:0, M:N, or 1:0 / 1 mode), the adaptive routing algorithm automatically selects the lightest-loaded connection from the top of the heap that has not reached the `shareConnLimit` limit for binding.

[0051] This mechanism enables the mixed scheduling and unified reuse of four heterogeneous RPC interaction modes within the same connection pool. It also breaks the model of "one request occupies one connection" and avoids hot connections through intelligent load balancing, so that a very small number of physical connections (such as reducing from tens of thousands to hundreds) can support massive concurrency, thus solving the connection pool exhaustion problem at its root.

[0052] 2. Decoupling mechanism for querying state and connection based on independent state machine and unique ID.

[0053] This mechanism pre-assigns a globally unique ID (QID) to each issued request (especially M:N queries that require long wait times). This QID, along with context information such as the request's callback function, is bound and managed in a connection-independent state machine. The physical connection is only responsible for carrying the QID for data transmission; once data sending or receiving is complete, the connection is immediately released back to the in-user-conn heap. When the query ends, state cleanup is completed by actively releasing the QID.

[0054] This approach achieves complete decoupling of the request's business logic state from the underlying transport connection. Long queries no longer occupy physical connections for extended periods, allowing connection resources to be reused instantly; erroneous operations at the business layer (such as duplicate responses) only affect the state of a specific QID without damaging the connection itself, greatly enhancing the system's fault tolerance and resource utilization efficiency.

[0055] 3. Dynamic timeout removal and fallback strategy for stress perception

[0056] The system monitors connection pool pressure in real time and defines explicit triggering conditions (e.g., when the total number of active requests exceeds 1 / 4 of the total connection pool capacity). Once the condition is met, a background detection thread is automatically started. This thread scans all incomplete requests based on the fallback timeout parameter readTimeout (default 128 seconds) and forcibly releases timed-out requests: triggering their error callbacks in an independent state machine and releasing the shareConnLimit quota they occupied on the corresponding connection.

[0057] This strategy can proactively identify and "eliminate" zombie requests caused by server delays or deadlocks, promptly reclaim occupied critical resources, effectively prevent the spread of local failures that could lead to system-wide avalanches, ensure the overall availability and stability of the system under high load, and realize an anomaly self-healing mechanism that has evolved from fixed timeouts to dynamic and pressure-sensitive mechanisms.

[0058] 4. Batch writing to the transport layer and protocol optimization

[0059] During the data transmission phase, multiple requests pending processing on the same physical connection are merged into a single batch data packet, which is then submitted to the kernel in one go using the `writev` system call, replacing the traditional multiple `write` calls. Simultaneously, a streamlined binary protocol header is designed and implemented, which must include the `seqID` and `QID` fields for accurate matching of requests and responses.

[0060] Batch writing significantly reduces the number of system calls and context switching; streamlined protocol headers (such as reducing them from 79 bytes) improve the effective utilization of network bandwidth; and the mandatory seqID fundamentally eliminates the problem of duplicate responses caused by network retransmission or misuse of services, ensuring the accuracy and reliability of communication, significantly reducing system overhead and improving transmission efficiency.

[0061] Compared with the prior art, the present invention has the following significant advantages:

[0062] 1. Creatively improves connection reuse and significantly reduces resource consumption: By allowing a single physical connection to concurrently handle multiple logical requests (controlled by shareConnLimit), the traditional one-to-one model is transformed into a many-to-one model. This reduces the number of physical connections required between the client and the cluster by one to three orders of magnitude (e.g., from tens of thousands to hundreds), fundamentally solving the connection pool exhaustion problem.

[0063] 2. Completely decouple connection state from business state, enhancing system robustness: By using QID, seqID, and an independent state machine, the lifecycle management of requests is separated from the transmission function of TCP connections. Misoperations such as duplicate responses and abnormal terminations in the business layer only affect the corresponding QID state, without polluting or interrupting the underlying physical connection, greatly enhancing the system's fault tolerance.

[0064] 3. Achieve unified scheduling of multiple message modes: Innovatively, four typical RPC interaction modes, namely 1:1 (request-response), 1:0 (one-way notification), M:N (streaming / subscription), and 1:0 / 1 (optional response), are scheduled and managed under a unified reusable architecture, which improves the versatility and simplicity of the framework.

[0065] 4. Optimize transmission performance and reduce system load: Employing writev for batch writing reduces the number of system calls and simplifies the protocol header to reduce network overhead. Combined with a significant reduction in the number of connections, this drastically reduces the number of active sockets that need to be scheduled in the operating system kernel, significantly improving network processing efficiency. Overall transmission performance is expected to improve by more than 30%.

[0066] 5. Possesses dynamic self-healing capabilities: The pressure-aware dynamic timeout mechanism enables the system to automatically remove zombie requests when under high load or when the backend is abnormal, preventing local failures from spreading into global deadlocks and ensuring the overall availability of the system.

[0067] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0068] Example 1

[0069] This embodiment describes the implementation process in a typical high-concurrency microservice scenario.

[0070] 1. System initialization: Start the RPC client, initialize a connection pool containing 10 physical connections, and set the shareConnLimit (concurrency limit) of each connection to 50 and readTimeout to 120s.

[0071] 2. Request Processing: When 1000 query requests flood in instantly, the routing decision-maker (maintaining a min-heap with connection load as the key) distributes the first 500 requests evenly across 10 physical connections (each physical connection can hold a maximum of sharedConnLimit requests). The remaining 500 requests require new physical connections to complete. For each new physical connection created, 50 requests are attached to it (assuming an initial value of 0, evenly distributed).

[0072] 3. Status Recording: Generate a unique QID (such as UUID or monotonically increasing ID) for each query request and register it in the status management layer. Set an additional sequence number seqId for each message (incrementing sequentially on a single socket). The QID is used to decouple the query from the physical connection, and the seqId is to prevent a single non-query message from receiving a duplicate response.

[0073] 4. Bulk Sending: The transport layer of each physical connection collects approximately 50 requests attached to it, merges the protocol headers (each header is approximately 16 bytes after simplification), and sends them in bulk through a single writev call.

[0074] 5. Asynchronous Processing and Response: After a request is sent, the physical connection immediately becomes available to accept new requests. Server responses are returned sequentially. If the QID is not 0, it indicates a stateful message, and processing is performed according to the state registered on the QID. The event loop thread dispatches the message to the state management layer to execute the corresponding business callback. If the QID is 0, the corresponding business callback is executed directly based on the seqID in the response.

[0075] 6. Timeout fallback: If a server node fails, causing 20 requests to remain unresponsive after 125 seconds, the system detects an increase in the overall timeout rate, triggers forced timeout logic, cleans up the status of these requests, and returns a timeout error to the client application.

[0076] Example 2

[0077] This embodiment describes the implementation process in a hybrid interaction mode.

[0078] 1. The client needs to send: 300 1:1 API calls, 50 1:0 log reporting events, and 5 M:N data stream subscription requests simultaneously.

[0079] 2. All requests enter a unified scheduling queue. The routing decision-maker does not distinguish between modes, but only allocates requests based on the current load of the connection.

[0080] 3. For M:N subscription requests, after a QID is assigned, its long-lived data stream is transmitted through the assigned physical connection, but this connection can still simultaneously transmit other 1:1 or 1:0 request messages. The subscription state is maintained by the QID at the state management layer and is independent of the connection.

[0081] 4. When the subscription ends, the state management layer cleans up the QID, and the "one concurrent seat" it occupied is released on the corresponding physical connection, restoring the connection capacity to serve new requests.

[0082] In summary, this invention proposes a method as follows: Figure 3 The method shown is an RPC connection management method based on multiplexing and state decoupling, which includes:

[0083] When the RPC client RPC-cli-thread receives a request message for multiple interaction modes, it allocates the request message to at least one physical connection in the physical connection pool, and uses the at least one physical connection to mount the request message for multiple interaction modes and send it to the RPC server RPCsvrthread.

[0084] The RPC client requests a QID for each stateful request message, generates state information in the state management layer using the QID, and associates the QID with its physical connection, wherein the QID is the request ID;

[0085] The RPC client merges stateful and stateless request messages attached to at least one physical connection and sends them in batches to the RPC server, then starts a timer.

[0086] The RPC client executes corresponding business callback processing or removes information from all timed-out request messages based on the timer's timing and the response from the RPC server to each request message.

[0087] The physical connection pool is the smallest physical connection pool established by the RPC client and includes multiple physical connections. When a physical connection sends a batch of attached request messages to the RPC server, the RPC client immediately releases the physical connection back to the smallest physical connection pool and saves the sent request records.

[0088] Specifically, the RPC client sends the concurrent request packets attached to a physical connection to the RPC server in batches according to the concurrent request limit (shareConnLimit) among the multiple interaction mode requests attached to a certain physical connection.

[0089] Specifically, when the number of concurrent requests for multiple interaction modes attached to a physical connection equals the concurrency limit, the RPC client sends the concurrent request messages attached to that physical connection to the RPC server in batches.

[0090] When the number of concurrent requests for multiple interaction modes attached to a certain physical connection exceeds the concurrency limit, the RPC client obtains a new physical connection from the minimum physical connection pool, and then uses the obtained new physical connection to attach the interaction mode requests.

[0091] When an RPC client receives a new request, it selects the physical connection with the fewest mounting requests and that has not reached the concurrency limit to mount the new request.

[0092] When sending request messages in batches, the client merges multiple request messages to be processed on the same physical connection to form a batch data packet. The protocol header of the batch data packet includes port sequence numbers seqID and QID for precise matching of requests and responses.

[0093] Specifically, the RPC client executes corresponding business callback processing based on the timer's timing and the RPC server's response to each request. This includes: if the QID in the RPC server's response is not 0, processing is performed according to the state information stored in the state management layer, and the event loop thread dispatches the request message to the state management layer to execute the corresponding business callback; if the QID in the RPC server's response is 0, the corresponding business callback is directly executed based on the port sequence number seqID in the response.

[0094] Specifically, the RPC client releases the state information of the QID stored in the state management layer based on the timer's timing and the response from the RPCsvrthread to each request message. This includes: when the timer exceeds the fallback timeout parameter readTimeout and the RPC server does not return a response to the request message, the client notifies the business side to directly clean up the timed-out stateless requests, clean up the related requests for the QID, and release the state information of the QID stored in the state management layer.

[0095] This includes clearing stateful and stateless requests, which involves releasing the shareConnLimit quota held by timed-out requests on the corresponding physical connection.

[0096] This invention has the following technical features:

[0097] 1. Deep connection reuse model for logical requests: The sharedConnLimit parameter is proposed, which defines the “N:1” mounting relationship between physical connections and logical requests, breaking through the traditional “1:1” exclusive model.

[0098] 2. The QID-based global state decoupling mechanism completely separates stateful request states from TCP connections and associates them through globally unique QIDs, thereby isolating business anomalies from transmission channel failures.

[0099] 3. Supports a unified scheduling strategy that integrates multiple modes: For the first time, four heterogeneous RPC interaction modes are incorporated into the same reuse and scheduling framework, which simplifies system design and improves resource utilization.

[0100] 4. Pressure-adaptive dynamic timeout rejection system: This system links timeout detection with overall system pressure, enabling an evolution from "static timeout" to "dynamic circuit breaker," thus enhancing the system's self-healing capabilities.

[0101] Although the present invention has been described in detail above, it is not limited thereto, and those skilled in the art can make various modifications based on the principles of the present invention. Therefore, all modifications made in accordance with the principles of the present invention should be understood to fall within the protection scope of the present invention.

Claims

1. An RPC connection management method based on multiplexing and state decoupling, comprising: When the RPC client RPC-cli-thread receives a request message for multiple interaction modes, it allocates the request message to at least one physical connection in the physical connection pool, and uses the at least one physical connection to mount the request message for multiple interaction modes and send it to the RPC server RPCsvrthread. The RPC client requests a QID for each stateful request message, generates state information in the state management layer using the QID, and associates the QID with its physical connection, wherein the QID is the request ID; The RPC client merges stateful and stateless request messages attached to at least one physical connection and sends them in batches to the RPC server, then starts a timer. The RPC client, based on the timer's timing and the response from the RPC server to each request message, executes corresponding business callback processing or removes information from all timed-out request messages; The physical connection pool is the smallest physical connection pool established by the RPC client and includes multiple physical connections. When a physical connection sends a batch of attached request messages to the RPC server, the RPC client immediately releases the physical connection back to the smallest physical connection pool and saves the sent request records.

2. The RPC connection management method according to claim 1, wherein the RPC client sends the concurrent request packets attached to a physical connection to the RPC server in batches according to the concurrent limit of the number of concurrent requests among the multiple interaction mode requests attached to a certain physical connection, shareConnLimit.

3. The RPC connection management method according to claim 2, wherein when the number of concurrent requests for multiple interaction modes attached to a certain physical connection is equal to the concurrency limit, the RPC client sends the concurrent request messages attached to the physical connection to the RPC server in batches.

4. The RPC connection management method according to claim 3, wherein when the number of concurrent requests for multiple interaction modes mounted on a certain physical connection exceeds the concurrency limit, the RPC client obtains a new physical connection from the minimum physical connection pool, and then uses the obtained new physical connection to mount the interaction mode requests.

5. The RPC connection management method according to claim 2, wherein when the RPC client receives a new request, it selects the physical connection with the fewest mounting requests and which has not reached the concurrency limit to mount the new request.

6. The RPC connection management method according to claim 2, wherein when sending request messages in batches, the client merges multiple request messages to be processed on the same physical connection to form a batch data packet, and the protocol header of the batch data packet includes port sequence numbers seqID and QID for precise matching of requests and responses.

7. The RPC connection management method according to claim 6, wherein the RPC client executes corresponding business callback processing based on the timer's timing and the RPC server's response to each request, including: If the QID in the RPC server response is not 0, it will be processed according to the state information stored in the state management layer. The event loop thread will dispatch the request message to the state management layer and execute the corresponding business callback. If the QID in the RPC server response is 0, then the corresponding business callback will be executed directly based on the port sequence number seqID in the response.

8. The RPC connection management method according to claim 6, wherein the RPC client releases the state information of the QID stored in the state management layer based on the timer's timing and the RPC server's response to each request message, including: When the timer exceeds the fallback timeout parameter readTimeout and the RPC server does not return a response to the request message, the business side is notified to directly clean up the timed-out stateless requests, clean up the related requests for QID, and release the state information of the QID stored in the state management layer.

9. The RPC connection management method according to claim 8, wherein clearing stateful and stateless requests includes releasing the concurrency limit quota occupied by timed-out requests on the corresponding physical connection.

Images