Memory database communication method based on RoCE network and related equipment

Abstract

The invention discloses a memory database communication method based on an RoCE network and related equipment, and relates to the technical field of communication, the method comprises the following steps: establishing a socket connection with a client through a TCP protocol, receiving a gid of an RoCE network card sent by the client, sending the gid of a server to the client after successful authentication, and sending the gid of the server to the client; establishing an RDMA connection of the RoCE based on the gid of the client and the gid of the server; and after the RDMA connection is established, receiving an SQL request sent by the client through the RDMA connection, and returning an SQL execution result through the RDMA connection. According to the invention, the problem that the network delay is too high during traditional pure TCP communication is effectively solved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a memory database communication method and related equipment based on RoCE networks. Background Technology

[0002] In-memory databases, with their extremely high memory access speed, are widely used in systems such as telecommunications billing and real-time online transactions. However, this high speed is limited to access within the same host. When the application system and the in-memory database are not on the same host, cross-host access to the in-memory database becomes commonplace. A method must be found to reduce the time consumption of such cross-host network access; otherwise, the high-speed memory access advantage of in-memory databases cannot be fully utilized in distributed deployments.

[0003] Currently, when the application system and the in-memory database server are not on the same host, a TCP connection is typically used over Ethernet to complete data access. This method utilizes the TCP protocol to establish a socket connection between the client and the server, and transmits SQL requests and SQL execution results through this connection, thereby achieving cross-host data communication.

[0004] Due to the complexity and inherent high latency of the TCP protocol, the communication time spent on the network for a single SQL query far exceeds the memory access time, preventing in-memory databases from fully utilizing their high-speed memory access advantages. Traditional TCP-based network data transmission has become a major bottleneck restricting the performance of cross-host in-memory databases. Summary of the Invention

[0005] The technical problem to be solved by this invention is to address the shortcomings of existing technologies, specifically by providing a memory database communication method and related equipment based on RoCE networks, as detailed below: 1) In a first aspect, the present invention provides a memory database communication method based on RoCE network, the specific technical solution of which is as follows: Establish a socket connection with the client via TCP protocol, receive the GID of the RoCE network card sent by the client, and after successful authentication, send the GID of the server to the client to establish an RDMA connection of RoCE based on the client's GID and the server's GID. After the RDMA connection is established, the SQL request sent by the client is received through the RDMA connection, and the SQL execution result is returned through the RDMA connection.

[0006] The beneficial effects of the RoCE-based memory database communication method provided by this invention are as follows: By combining the TCP protocol with RoCE's RDMA connection, the problem of excessive network latency in traditional pure TCP communication is effectively solved. The socket connection established based on the TCP protocol is responsible for reliable connection establishment and status monitoring, while the RoCE RDMA connection established based on the GID of the switched RoCE network card is dedicated to transmitting SQL requests and SQL execution results. This division of labor fully utilizes the low latency and high bandwidth characteristics of the RoCE network, significantly reducing the time spent in the entire communication process from the client sending an SQL request to the server returning the SQL execution result. This allows the in-memory database deployed across hosts to truly leverage its high-speed memory access advantages. Simultaneously, the continuous reliability guarantee of the TCP connection allows the server to promptly perceive the client's status, avoiding resource congestion caused by abnormal client exits and ensuring system robustness.

[0007] Based on the above scheme, the memory database communication method based on RoCE network of the present invention can be further improved as follows.

[0008] Furthermore, it also includes: monitoring the client's status by checking the status of the socket connection while waiting to receive SQL requests.

[0009] The beneficial effects of adopting the above-mentioned further solution are: by monitoring the client's status through checking the socket connection status, the in-memory database server can perceive the health status of the client connection in real time while waiting to receive SQL requests. This technical feature allows the server to immediately detect abnormal socket connection status when a client exits abnormally, thereby promptly triggering the termination of the RoCE RDMA connection and the cleanup of the corresponding database transactions. This avoids the problem of the server process being unable to reclaim resources due to prolonged blocking and waiting, ensuring the effective utilization of system resources and data consistency, and improving the reliability and robustness of the entire communication process.

[0010] Furthermore, while waiting to receive SQL requests, the client's status is monitored by checking the socket connection status, including: while waiting to receive SQL requests via the RDMA connection, non-blocking timeout polling of the file descriptor used to receive RDMA event notifications; after each polling timeout, checking the status of the socket connection established via the TCP protocol; if the socket connection status is normal, the client status is determined to be normal, and the next polling continues; if the socket connection status is abnormal, the client status is determined to be abnormal, and the operation of terminating the RDMA connection and cleaning up the corresponding database transaction is executed.

[0011] The beneficial effects of adopting the above-mentioned further solution are: it enables the server to periodically and with low overhead verify client liveness while efficiently waiting for SQL requests. By relying on the reliable state judgment of the TCP protocol connection, the server can accurately distinguish between situations where the client has no requests and situations where the client has exited abnormally. When the socket connection state is determined to be abnormal, the server can immediately perform operations to terminate the RDMA connection and clean up the corresponding database transactions, thereby effectively preventing the problem of long-term server resource occupation and inconsistency between the database state caused by the unexpected termination of the client process.

[0012] Furthermore, it also includes: after establishing the RoCE RDMA connection based on the client's gid and the server's gid, it also includes setting the file descriptor used to receive RDMA event notifications to non-blocking mode.

[0013] The beneficial effects of adopting the above further solution are: setting the file descriptor used to receive RDMA event notifications to non-blocking mode prevents the server process from being blocked indefinitely while waiting to receive SQL requests via the RDMA connection. This setting allows for subsequent non-blocking timeout polling operations, enabling the server to periodically perform other necessary checks during the waiting period. Combined with status checks on the socket connections established via the TCP protocol, the server can maintain efficient waiting while possessing the ability to promptly detect the client's liveness status. This provides the necessary preconditions for quickly releasing RDMA connection resources and cleaning up database transactions when the client encounters an anomaly, improving the overall system responsiveness and resource management efficiency.

[0014] 2) In a second aspect, the present invention also provides a memory database communication system based on RoCE network, the specific technical solution of which is as follows: This includes a connection establishment module and a send / receive module; The connection establishment module is used to: establish a socket connection with the client via the TCP protocol, receive the GID of the RoCE network card sent by the client, and after successful authentication, send the GID of the server to the client to establish a RoCE RDMA connection based on the client's GID and the server's GID. The send / receive module is used to: receive SQL requests sent by the client through the RDMA connection after the RDMA connection is established, and return the SQL execution result through the RDMA connection.

[0015] Based on the above scheme, the memory database communication system based on RoCE network of the present invention can be further improved as follows.

[0016] Furthermore, it also includes a monitoring module, which is used to monitor the client's status by checking the status of the socket connection while waiting to receive SQL requests.

[0017] Furthermore, the monitoring module is specifically used to: perform non-blocking timeout polling of the file descriptor used to receive RDMA event notifications while waiting to receive SQL requests via the RDMA connection; after each polling timeout, check the status of the socket connection established via the TCP protocol; if the socket connection status is normal, determine that the client status is normal and continue to the next polling; if the socket connection status is abnormal, determine that the client status is abnormal and perform the operation of terminating the RDMA connection and cleaning up the corresponding database transaction.

[0018] Furthermore, it also includes a settings module, which is used to: after establishing a RoCE RDMA connection based on the client's gid and the server's gid, also set the file descriptor used to receive RDMA event notifications to non-blocking mode.

[0019] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor, so as to enable the electronic device to implement any of the above-mentioned memory database communication methods based on RoCE networks.

[0020] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described memory database communication methods based on RoCE networks.

[0021] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is one of the flowcharts illustrating a memory database communication method based on a RoCE network according to an embodiment of the present invention; Figure 2 This is a second schematic flowchart of a memory database communication method based on a RoCE network according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a memory database communication system based on RoCE network according to an embodiment of the present invention. Detailed Implementation

[0023] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0024] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0025] like Figure 1 As shown in the figure, an embodiment of the present invention provides a memory database communication method based on a RoCE network, comprising the following steps: S1. Establish a socket connection with the client via TCP protocol, receive the GID of the RoCE network card sent by the client, and after successful authentication, send the server's GID to the client to establish a RoCE RDMA connection based on the client's GID and the server's GID; the specific implementation process is as follows: 1) The client initiates a connection request, and the server receives this request through the accept system call, thereby establishing a reliable TCP socket connection with the client. This TCP socket connection will serve as the channel for subsequent control information.

[0026] 2) After the TCP socket connection is established, the server receives data sent from the client through this connection. This data includes the GID information of the client's RoCE network interface card (NIC). The server parses the received data according to a predefined application layer protocol format to extract the GID of the client's RoCE NIC. Subsequently, the server performs authentication verification on the client, which may include verifying the username, password, or other credentials. If authentication fails, the server returns an error message through the TCP socket connection and closes the connection. If authentication succeeds, the server prepares for the next step.

[0027] 3) After successful authentication, the server needs to obtain its own RoCE network interface card (NIC) gid. The server queries available RoCE NIC devices locally by calling the RoCE network programming interface and obtains the gid of the specified NIC. After obtaining the server's gid, the server encapsulates the server's gid information into a data packet according to a predefined format and sends it to the client through the established TCP socket connection. At this point, both the client and server have exchanged the network identification information necessary for establishing a direct memory access connection through a reliable TCP channel.

[0028] 4) The server and client use the exchanged GID information to establish a RoCE RDMA connection. The server calls the RDMA programming interface to create a protection domain and register a memory region for communication. Next, the server creates a completion queue, a send queue, and a receive queue, which together form a queue pair. The server uses its own GID and the client's GID obtained from the client as the target parameters for establishing the connection, initiating a request to establish an RDMA connection. The server and client's RDMA stacks exchange connection parameters over the network, ultimately establishing a point-to-point channel at the RoCE network layer that supports direct remote memory access—the RoCE RDMA connection. After this connection is established, the server and client can directly read and write each other's registered memory regions, thus achieving low-latency data transmission.

[0029] 5) After a successful RDMA connection is established in RoCE, the server performs an additional configuration. The server obtains a file descriptor for receiving RDMA connection event notifications and sets the file descriptor's operating mode to non-blocking mode. This setting is to facilitate subsequent monitoring of the client's status.

[0030] The RoCE network interface card (NIC) is a dedicated network interface card that implements the RoCE protocol. The RoCE protocol allows RDMA technology to run on standard Ethernet infrastructure. This NIC has the ability to encapsulate RDMA operation commands and data into Ethernet frames for transmission and reception. Simultaneously, its hardware offload engine can directly handle the relevant operations of the RDMA protocol stack, reducing the intervention of the central processing unit, thereby achieving high-bandwidth and low-latency network communication.

[0031] In RoCE network interface cards (NICs), the gid is a globally unique identifier used to uniquely identify a network endpoint in a RoCE network environment. This identifier is similar to an IP address in a traditional network, but it is designed for addressing in RDMA communication derived from the InfiniBand architecture. When establishing a RoCE RDMA connection, both communicating parties must exchange and use each other's gids to accurately locate each other within the network and establish a direct, point-to-point data transmission channel.

[0032] In RoCE, the RDMA connection is a logical communication link established over the RoCE network. This connection is created based on the gid exchanged between the two parties, enabling RDMA operation. Through this connection, applications can bypass the operating system's kernel network protocol stack and directly access the remote host's memory area to read or write data. This communication method significantly reduces communication latency and improves throughput because the overhead of context switching and data copying during data transmission is greatly reduced.

[0033] In another feasible approach, the specific implementation process for authentication is as follows: 1) The server receives the login request message sent by the client through the established TCP socket connection. This message contains the client's preset identity identifier and the GID information of the client's RoCE network card. The server parses the message, extracts the client's preset identity identifier and GID, and calls the security module to generate a cryptographically random number based on the identity identifier as a dynamic challenge token for this authentication. Specifically: The server receives the login request message sent by the client through an established TCP socket connection. The server invokes a read system call to retrieve network data from the file descriptor of the TCP socket connection. This data is a byte stream encapsulated according to a predefined application layer protocol format. The server's in-memory database communication module unpacks the received byte stream and extracts two key information units based on the field boundaries defined by the protocol format. The first information unit is the client's preset identity identifier, a unique string or number sequence pre-assigned and agreed upon by the system to identify the client. The second information unit is the client's RoCE network card's global identifier information. After extracting the client's preset identity identifier, the server immediately invokes a separate security module. Based on the input client preset identity identifier, the server's security module accesses a cryptographically secure random number generator. This random number generator produces a sufficiently long and unpredictable cryptographic random number. The server marks this cryptographic random number as a dynamic challenge token specific to this session. This dynamic challenge token is temporarily bound to the client's identity for subsequent verification.

[0034] 2) The server sends the generated dynamic challenge token to the client through the same TCP socket connection. Simultaneously, the server uses the client's GID information and a pre-stored server key to calculate an expected standard response value using a hardware security module or encryption library. This standard response value, the client's GID, and the challenge token are then temporarily associated and stored in the server's memory. Specifically: The server sends the dynamic challenge token generated by its security module to the client via the same TCP socket connection. The server encapsulates the dynamic challenge token into a new network packet according to the same predefined application layer protocol format. The server invokes a write system call to send the encapsulated packet data through the file descriptor of the TCP socket connection. Simultaneously, after sending the dynamic challenge token, the server immediately begins calculating an expected standard response value. The server's security module performs the calculation, which requires three input parameters. The first parameter is the dynamic challenge token just sent to the client. The second parameter is the global identifier of the client's RoCE network card extracted from the client's login request message. The third parameter is a pre-stored server key, which is secret information held only by the server. The server, through its hardware security module or software encryption library, uses a predefined cryptographic algorithm, such as a hash-based message authentication code algorithm, to process these three input parameters, generating a fixed-length digest value, which is the expected standard response value. After the calculation is complete, the server creates a temporary data structure in memory to associate and store the expected standard response value, the global identifier of the client's RoCE network card, and the dynamic challenge token. It also sets a reasonable timeout timer to prepare for waiting for the client's response.

[0035] 3) The server receives the authentication response message returned by the client via a TCP socket connection. The client's response message is generated locally by the client using the hardware features or security elements of its RoCE network card to perform a joint signature operation on the received dynamic challenge token and its own GID. The server parses this response message to obtain the actual response value calculated by the client, specifically: The server continues to wait for and receive the authentication response message returned by the client through the TCP socket connection. Within the set timeout period, the server reads the file descriptor of the TCP socket connection again. Upon receiving the dynamic challenge token, the client performs local computation to generate a response. The client's computation utilizes the hardware features of its RoCE network card or its integrated security element. Specifically, the client combines the received dynamic challenge token with its own RoCE network card's global identifier and performs digital signature computation using a key or certificate stored in the hardware, ultimately generating a unique actual response value. The client encapsulates this actual response value into an authentication response message and sends it back. After successfully reading this response message, the server unpacks the message and strictly parses out the actual response value data carried within according to the protocol. This actual response value represents the client's response to the server's challenge.

[0036] 4) The server compares the received actual response value from the client with the temporarily stored expected standard response value. If the two response values ​​match perfectly, the client's authentication is successful, and the provided GID is confirmed to be genuine and valid. The server then executes the subsequent process, sending its own RoCE network card's GID to the client via a TCP socket connection. If the response values ​​do not match or a response is not received within the predetermined time, authentication fails. The server returns an error message via the TCP socket connection and terminates the connection. Specifically: The server retrieves the previously calculated and saved expected standard response value from the temporary storage data structure. The server then compares the actual response value, parsed from the client's authentication response message, byte-by-byte with the retrieved expected standard response value. If every byte of the two response values ​​matches exactly, the server determines that the client's authentication was successful and confirms that the global identifier of the RoCE network card provided by the client in the login request is genuine and has not been tampered with. After successful authentication, the server clears the relevant data in the temporary storage and immediately executes the subsequent process: sending its own RoCE network card's global identifier to the client in a predefined format via the same TCP socket connection. If the two response values ​​do not match, or if the server does not receive the client's authentication response message within the predetermined timeout period, the server determines that the authentication has failed. After authentication failure, the server also clears the data in the temporary storage, then sends an error message indicating authentication failure to the client via the TCP socket connection, and subsequently calls the close system call to terminate the TCP socket connection, without proceeding with the subsequent RoCE RDMA connection establishment process.

[0037] S2. After the RDMA connection is established, the SQL request sent by the client is received through the RDMA connection, and the SQL execution result is returned through the RDMA connection. The specific implementation process is as follows: 1) To prepare for receiving data via the RoCE RDMA connection, the server pre-registers a contiguous buffer in memory, called the receive buffer. The server encapsulates the address, length, and access key of this receive buffer into a structure called a work request and publishes it to the receive queue of the RoCE RDMA connection. This operation signifies that the server is informing its network stack that it is ready to receive data from the RoCE RDMA connection, and that the data should be placed directly into the designated receive buffer. The server can pre-publish multiple such work requests to the receive queue, continuously preparing to receive subsequent SQL requests in a pipelined manner.

[0038] 2) Since the file descriptor used to receive RDMA event notifications has been set to non-blocking mode, the server employs a polling mechanism with a timeout to wait for events. The server calls system calls such as poll or epoll to monitor the aforementioned file descriptor and sets a timeout, for example, 1 second. The server process is suspended here until one of the following two conditions occurs: either an interrupt is received from the RoCE network card within the timeout period, indicating that data has arrived or work has been completed; or the timeout period expires.

[0039] 3) If the polling times out, it means that no new SQL request has been received through the RoCE RDMA connection within the set time. The server then checks the status of the socket connection previously established via the TCP protocol. The server can determine whether the TCP connection is still alive by checking the error status of the socket file descriptor or attempting a small non-blocking read. If the TCP connection is normal, the server determines that the client is still online but has no requests at the moment, and thus returns to step two to start the next timeout polling. If an abnormal TCP connection status is found, such as a broken connection, the server determines that the client status is abnormal. The server then terminates the RoCE RDMA connection and cleans up the corresponding database transactions, and then terminates the service to this client.

[0040] 4) If the polling does not time out, but returns due to an event occurring on the RoCE RDMA connection, the server learns from the event that a receive job request has been completed. The server queries the completion queue of the RoCE RDMA connection to determine which receive buffer was filled with data. The server then directly reads the raw byte stream delivered over the network from the corresponding receive buffer. This byte stream is the complete network packet of the SQL request sent by the client. The server unpacks this packet according to the application layer protocol and parses out the complete SQL request content contained within.

[0041] 5) The server-side in-memory database engine receives the parsed SQL request. The in-memory database engine performs a series of processes on the SQL request, including lexical analysis, syntax analysis, permission verification, and query optimization. Next, the in-memory database engine accesses in-memory data tables, indexes, and other structures to execute the data operations defined in the SQL request, such as data querying, inserting, updating, or deleting. After execution, the in-memory database engine generates the corresponding SQL execution result based on the execution status. This SQL execution result is then delivered to the server-side process responsible for communication.

[0042] 6) The SQL execution result is returned via the RoCE RDMA connection. The server process encapsulates the SQL execution result into a network packet according to the application layer protocol. This packet data is filled into another buffer registered in memory by the server, namely the send buffer. The server creates a send request, which includes information such as the address and length of the send buffer, and publishes this request to the send queue of the RoCE RDMA connection. The RoCE network card hardware automatically processes this request without much central processing unit involvement, sending the data in the send buffer directly and at high speed to the client over the network. The client directly obtains the SQL execution result from its pre-registered receive buffer. After the transmission is complete, the server receives a notification that transmission is complete. Afterward, the server can loop back to the first or second step above to prepare to receive the next SQL request.

[0043] An SQL request is a Structured Query Language (SQuery Language) instruction sent by the client to the in-memory database server. This instruction is expressed as a text string and encapsulated within a network message at the application layer. An example SQL request is `SELECT employee_id, name FROM employees WHERE department = 'Sales';`. This request instructs the database to retrieve the `employee_id` and `name` fields for all employees in the `employees` table whose department is 'Sales'. The SQL request defines the specific data manipulation commands the client expects the server to execute.

[0044] The SQL execution result is the response data returned by the in-memory database server to the client after processing an SQL request. This result is also encapsulated in the application layer network message. For a query request, the SQL execution result typically includes the operation status and the result dataset. For example, for the query request mentioned above, the SQL execution result might include a success status code and a set of several rows of data, each containing the specific values ​​of an employee's employee_id and name. If the SQL request fails, the SQL execution result will include an error status code and text information describing the reason for the error.

[0045] Optionally, the above technical solution also includes: While waiting to receive SQL requests, the client's status is monitored by checking the socket connection status. Specifically, while waiting to receive SQL requests via the RDMA connection, the file descriptor used to receive RDMA event notifications is polled non-blockingly with a timeout. After each polling timeout, the status of the socket connection established via the TCP protocol is checked. If the socket connection status is normal, the client is considered to be in good condition, and the next polling continues. If the socket connection status is abnormal, the client is considered to be in bad condition, and the RDMA connection is terminated and the corresponding database transaction is cleaned up. The specific implementation process is as follows: 1) After successfully establishing a RoCE RDMA connection and setting the file descriptor used to receive RDMA event notifications to non-blocking mode, the server enters the main loop waiting to receive SQL requests. The server prepares to perform polling operations. The server creates an array of polling structures containing the file descriptors to be monitored. In this scenario, the primary monitoring object is the file descriptor used to receive RDMA event notifications. The server sets the event type of interest in the polling structure to readable events, indicating its concern about whether RDMA event notifications have arrived. Simultaneously, the server sets a timeout value, such as 1000 milliseconds, which specifies the maximum waiting time for a single polling call.

[0046] 2) The server initiates a system call to perform a polling operation. The server passes the prepared polling structure array to the operating system kernel and calls the polling interface. At this time, the execution state of the server process depends on the polling result. Since the file descriptor used to receive RDMA event notifications is in non-blocking mode and a timeout is set, this call will not cause the process to wait indefinitely. The operating system kernel monitors the specified file descriptor. If, within the timeout period, the RoCE network card driver sends an event notification to the file descriptor due to a new work request completing on the RDMA connection, the kernel will immediately wake up the server process and inform it that an event has occurred. If no event occurs within the entire timeout period, the operating system kernel will wake up the server process after the timeout and return a timeout indicator.

[0047] 3) The server handles different situations based on the return value of the polling operation. The return value of the polling operation indicates the number of file descriptors where events occurred or the timeout status. If the return value is greater than zero, it indicates that a readable event occurred on the file descriptor used to receive RDMA event notifications before the timeout. This means that data has arrived on the RoCE RDMA connection, i.e., a new SQL request has been delivered. The server then exits this monitoring loop and proceeds to handle the specific process of receiving SQL requests and generating SQL execution results. If the return value is equal to zero, it indicates that no event occurred on any monitored file descriptor within the set timeout period, i.e., no new SQL request was received through the RoCE RDMA connection. This situation is called polling timeout.

[0048] 4) When a polling timeout occurs, the server performs a client status check. The server needs to check the status of the socket connection established via the TCP protocol to determine if the client is still alive. The server obtains the status information of the TCP socket connection through system calls. One method is to attempt a non-blocking, zero-length read operation on the socket connection. Since the TCP protocol is connection-oriented, if the client maintains the connection normally, this operation will return immediately, indicating that there is no data to read but the connection is normal. If the client process has crashed or the network has been disconnected, the operating system kernel will detect the abnormal termination of the TCP connection, and this read operation will return an error, or it will know that the connection has been incorrectly broken by obtaining the socket options.

[0049] 5) If the check results indicate that the socket connection established via the TCP protocol is normal, the server determines that the client's state is normal. The client may simply be temporarily not sending new SQL requests. The server's logic will return to the first step, prepare again, and start the next non-blocking timeout polling, continuing to wait for possible SQL requests. If the check results indicate that the socket connection established via the TCP protocol is abnormal, the server determines that the client's state is abnormal. This usually means that the client has unexpectedly exited or the network connection is unreliable.

[0050] 6) Upon determining that the client's state is abnormal, the server performs resource cleanup and connection termination operations. Specifically, the server first executes the process of terminating the RoCE RDMA connection, including releasing related queue pairs, protection domains, and registered memory buffers. Next, the server performs cleanup operations on the corresponding database transactions. The server's in-memory database engine rolls back or terminates all uncommitted database transactions in the client session based on the client's connection identifier, releasing the locks, memory, and log resources occupied by these transactions to ensure database state consistency. After completing these cleanup tasks, the server closes the socket connection established via the TCP protocol and terminates the service session for that client.

[0051] RDMA event notifications are signals sent by the RoCE network card or its underlying driver to the application when specific RDMA-related events occur. When a data transfer is completed via a RoCE RDMA connection—for example, a receive job request is filled with data, or a send job request is completed—the network hardware or driver generates an event. This event is passed to the operating system, ultimately notifying the waiting application process that it can safely read the data or perform subsequent operations without requiring continuous active queries from the application.

[0052] The RDMA event notification file descriptor is an abstract handle provided by the operating system to applications for accessing and managing the RDMA event notification channel. One or more such file descriptors are typically obtained when initializing the RoCE RDMA connection context. By reading, monitoring, or polling this file descriptor, applications can detect asynchronous events occurring on the associated RoCE RDMA connection, thus implementing an event-driven communication model and avoiding busy waiting that consumes CPU resources.

[0053] Non-blocking timeout polling is a mechanism that combines non-blocking input / output with timed waiting. An application sets one or more file descriptors to non-blocking mode, meaning that when performing read or wait operations on them, it will immediately return instead of suspending the process if the condition is not met. Polling refers to the application requesting the operating system kernel to monitor the state changes of a set of file descriptors for a period of time via a system call. The timeout parameter specifies the maximum monitoring time. Non-blocking timeout polling allows applications to efficiently wait for multiple input / output events while avoiding indefinite waiting, and allows them to execute other logic after the timeout, such as checking the status of backup communication channels.

[0054] In a database system, a database transaction is a sequence of operations that constitutes a single logical unit of work. A typical database transaction may include a start identifier, one or more SQL statements for reading, writing, or modifying data, and a commit or rollback identifier. Database transactions possess the characteristics of atomicity, consistency, isolation, and durability. In the context of this invention, a client connection may initiate one or more database transactions to execute SQL requests. Cleaning up the corresponding database transactions means that when a client disconnects abnormally, the server needs to ensure that these incomplete transactions are properly terminated, releasing all resources they hold and reversing any uncommitted modifications to the database state to maintain data integrity and consistency.

[0055] In another possible implementation, while waiting to receive SQL requests, the client's status is monitored by checking the socket connection status, including: 1) After exchanging global identifier information with the client via a TCP socket connection, the server enables the connection health monitoring function provided by the underlying network protocol stack for that TCP socket connection. The server configures monitoring parameters so that the TCP protocol stack can continuously track the packet transmission delay and acknowledgment patterns on this connection and maintain an internal status score. Specifically: After successfully exchanging global identifier information with the client via a TCP socket connection, the server immediately enables the connection health monitoring function provided by the underlying network protocol stack for that TCP socket connection. The server invokes a system call to set socket options, activating specific socket options on the file descriptor of the TCP socket connection. This option instructs the operating system kernel's TCP protocol stack to begin deep monitoring of the connection. The server simultaneously configures a series of monitoring parameters, including but not limited to the maximum allowed round-trip time sample size, the time window for determining connection lag, and the expected heartbeat interval baseline. Once configured, the operating system's TCP protocol stack begins continuously tracking all data packet transmissions on the TCP socket connection. The stack records the delay between each data packet transmission and its corresponding acknowledgment, analyzes the patterns and frequency of data packet retransmissions, and observes the changing patterns of the sliding window. Based on these real-time network metrics, the TCP protocol stack internally runs an evaluation algorithm to dynamically calculate and maintain an internal state score reflecting the current connection path quality and stability. This score is a comprehensive numerical value; a higher score indicates a healthier connection.

[0056] 2) When the server enters the loop waiting to receive SQL requests and begins polling the file descriptor used to receive RDMA event notifications, it synchronously initiates an asynchronous query for the health status of the TCP socket connection. The server calls a non-blocking system call to request the operating system kernel to return the real-time health status score of the current TCP socket connection and the timestamp of the most recently observed activity. Specifically: While the server enters its main loop to wait for SQL requests and begins timeout polling of the file descriptors used to receive RDMA event notifications, it simultaneously initiates an asynchronous query regarding the health status of the aforementioned TCP socket connection. Instead of directly blocking and waiting for the query result, the server prepares to initiate a non-blocking I / O operation. The server calls a system call interface that supports asynchronous I / O, such as a queue-based asynchronous I / O interface. Through this system call, the server submits a query request to the operating system kernel. The target of this query request is the file descriptor of the TCP socket connection for which health monitoring was previously enabled. The request retrieves the real-time health status score of the connection maintained by the kernel's TCP protocol stack, as well as the latest timestamp of any packet activity on the connection most recently observed by the kernel. This system call returns immediately, indicating that the query request has been submitted, while the actual query work is performed by the operating system kernel in the background.

[0057] 3) At the end of each polling cycle for the file descriptor used to receive RDMA event notifications, the server checks whether the asynchronous query results are ready, regardless of whether a timeout has occurred. The server compares the obtained TCP socket connection health status score with several preset thresholds and calculates the silence duration since the last valid activity by combining it with the activity timestamp. Specifically: After each polling cycle of the file descriptor used to receive RDMA event notifications, the server immediately performs a check, regardless of whether the poll returned due to receiving an RDMA event notification or due to a timeout. The server checks if the result of the asynchronous query for the TCP socket connection's health status is ready. The server obtains the result by checking the completion status provided by the asynchronous input / output system call interface. If the query is complete, the server receives a structure containing the requested data. From this structure, the server extracts two key pieces of data: the first is the real-time health status score of the TCP socket connection, and the second is the timestamp of the most recently observed activity. The server compares the obtained real-time health status score with several preset thresholds. These preset thresholds include a normal threshold indicating a healthy connection and an abnormal threshold indicating a potential problem with the connection. Simultaneously, the server calls a function to obtain the current time, subtracting the extracted activity timestamp from the current time to calculate the silent duration of the TCP socket connection since the kernel last observed valid packet activity.

[0058] 4) The server determines the client's status based on a comprehensive analysis of the health status score and the silence duration. If the score is higher than the normal threshold and the silence duration is within a reasonable range, the client is considered to be in a normal state, and the next monitoring cycle continues. If the score remains below the abnormal threshold or the silence duration exceeds the maximum allowable limit, the client is considered to be in an abnormal state, and the server immediately terminates the RoCE RDMA connection and cleans up the corresponding database transactions. Specifically: The server comprehensively analyzes the acquired data to determine the client's status. The determination logic combines a health status score and a calculated silence duration. The server checks if the real-time health status score is higher than a preset normal threshold and simultaneously checks if the silence duration is less than a preset maximum allowable range. If both conditions are met, the server determines the client's status is normal. This means the TCP connection quality is good and the client has recently had network activity; the client may simply be in a request interval. After determining normal status, the server cleans up the current asynchronous query results and initiates a new asynchronous query for the TCP socket connection health status, preparing for the next monitoring cycle. Then, the server continues its main loop waiting to receive SQL requests. If the health status score is lower than a preset abnormal threshold and persists for a certain number of check cycles, or if the silence duration exceeds the preset maximum allowable limit, the server determines the client's status is abnormal. Upon abnormal determination, the server immediately performs a series of resource cleanup and connection termination operations. The server first calls the RDMA programming interface to terminate the RoCE RDMA connection with this client, releasing related queue pairs, protection fields, and registered memory buffers. Next, the server instructs the in-memory database engine to clean up all database transactions corresponding to this client session, roll back uncommitted changes, and release lock resources. Finally, the server closes the TCP socket connection used for monitoring and exits the service session for this client.

[0059] Optionally, the above technical solution further includes: after establishing the RoCE RDMA connection based on the client's GID and the server's GID, it also includes setting the file descriptor used to receive RDMA event notifications to non-blocking mode, as detailed below: 1) After successfully establishing a RoCE RDMA connection based on the client's and server's GIDs, the server needs to obtain a file descriptor associated with this connection for receiving RDMA event notifications. This file descriptor is an integer value provided by the underlying RoCE network programming interface during the creation and initialization of the RoCE RDMA connection context and completion event channel. It serves as a handle for interaction between the operating system kernel and the application, specifically used to notify the server process of asynchronous events on this particular RoCE RDMA connection, such as the completion of a work request. The server obtains this file descriptor from the established connection object or associated event channel structure by calling a specific function in the RDMA library.

[0060] 2) After obtaining the file descriptor used to receive RDMA event notifications, the server prepares to modify its attributes. The server needs to change the file descriptor's operating mode from the default blocking mode to non-blocking mode. The server achieves this modification using file control functions provided by the operating system. The server calls this function, passing the file descriptor to be set as a parameter. In this function call, the server specifies an operation command indicating whether to get or set the file descriptor's status flags. The server first obtains all the current status flags of the file descriptor and saves them to a variable.

[0061] 3) The server adds a non-blocking mode flag to the existing status flags. This non-blocking flag is a predefined constant that tells the operating system kernel that subsequent input / output operations on the file descriptor, such as reading event notifications, should be performed in a non-blocking manner. The server uses a logical OR operation to merge the non-blocking flag into the previously obtained file descriptor status flag set, forming a new flag set.

[0062] 4) The server applies the new set of flags to the file descriptor used to receive RDMA event notifications. The server calls the file control function again, using the flag-setting command and passing the new set of status flags, including the non-blocking flag, as a parameter. Upon receiving this request, the operating system kernel updates the internal state of the file descriptor, officially putting it into non-blocking mode. After this system call succeeds, the attributes of the file descriptor used to receive RDMA event notifications are modified.

[0063] 5) The server can choose to verify the settings to ensure they take effect. Verification is done by immediately attempting to read data from the file descriptor set to non-blocking mode. Since there may not be any new event notifications arriving on the RoCE RDMA connection at this time, in non-blocking mode, this read operation will immediately return a specific error code. This error code indicates that no data is currently readable, but the operation does not block the process; instead, control is immediately returned to the application. This behavior confirms that the file descriptor is in non-blocking mode. If the read operation does not return immediately but suspends the process, it indicates that the settings may have failed, and the server needs to handle the error. After successful verification, this file descriptor in non-blocking mode, used for receiving RDMA event notifications, can be used in subsequent non-blocking timeout polling operations.

[0064] Non-blocking mode is a working state attribute of a file descriptor or socket. When a file descriptor is set to non-blocking mode, input / output system calls executed on that descriptor will exhibit different behaviors. If the requested operation cannot be completed immediately—for example, when no event has occurred while reading from a file descriptor used to receive RDMA event notifications, or writing data to a socket with a full buffer—the system call will not put the calling process into a sleep state. Instead, the call will return immediately, setting a specific error code to indicate that the operation needs to be retried or the condition is not ready. This mode allows the application to continue performing other tasks instead of being blocked by a potentially time-consuming input / output operation, thereby improving the program's responsiveness and the ability to efficiently manage multiplexed input / output. In this invention, setting the file descriptor used to receive RDMA event notifications to non-blocking mode is a fundamental prerequisite for subsequently implementing timeout polling and client state monitoring combined with TCP connections.

[0065] In this invention, the entire connection process and data reception mechanism begin with the server starting execution and initiating a TCP socket listener to enter a connection-waiting state. Simultaneously, the client begins execution and connects to the network address and port specified by the server via the TCP protocol. Upon detecting a client connection request, the server accepts the connection, thus establishing a reliable TCP socket control channel. Subsequently, the client will use this TCP... The client sends login information and the GID of its RoCE network interface card to the server via the TCP socket control channel. Upon receiving the login request, the server authenticates the client and, upon successful authentication, sends its own GID to the client via the same TCP socket control channel. After successfully exchanging network identifiers, both parties use the client's and server's GIDs to call the RoCE network programming interface to initialize queue pairs, protection domains, and memory areas, thus successfully establishing a point-to-point RoCE RDMA connection. Once the connection is established, the client's SQL requests are sent directly to the server via the RoCE connection, and the SQL execution results are received through this connection. Due to RoCE's low latency, the time from sending the SQL request to receiving the SQL execution result is significantly reduced, only 50% of that of the TCP protocol. When transmitting data via RoCE, the server has two handling methods while waiting for the client to send SQL requests: the first method is to continuously scan the receive buffer, which continuously consumes CPU time, keeping the server busy even if the client does not send any SQL requests; the second method is to use the even... In the first method, the process is blocked until data is received. Therefore, this invention uses the second event method. However, the event method provided by RoCE has a drawback: if no data is received, the process will be blocked, and even if the client exits, the server will not be aware of it, causing the corresponding database transaction to remain unreleased. This invention will combine TCP connection with RoCE's RDMA mechanism to solve the above problem. First, during connection initialization, the file descriptor used to receive RDMA event notifications for blocking processes in the event method is set to non-blocking. Then, while waiting to receive SQL requests, the file descriptor is polled using a timeout method, for example, setting a timeout of 1 second. If no SQL request is received within 1 second, the current TCP connection is checked. If it is normal, the next poll is performed. If it is not normal, it means that the client has exited. The socket based on the TCP protocol is oriented towards reliable connections. Once the client exits, the server can immediately detect it. At this time, the server can close the connection and clean up the corresponding database transaction, thereby avoiding being blocked indefinitely.Specifically, while maintaining a persistent connection, the client encapsulates SQL commands into application-layer messages and writes them directly to the server's pre-registered memory area via the established RoCE RDMA connection. The server, sensing data arrival through polling or an event mechanism, reads and receives the SQL commands from the corresponding buffer. The in-memory database engine then parses and executes the SQL commands, generating result datasets or status information. The SQL execution results are then encapsulated and written to the client's pre-registered memory area via the RoCE RDMA connection. The client receives the SQL execution results via the RoCE RDMA connection. To efficiently manage connection states and avoid resource consumption, the server enters a detection loop while waiting for a client to send an SQL request. This detection is achieved by non-blocking timeout polling of the file descriptor set to receive RDMA event notifications (with a 1-second timeout), using the poll system call to monitor the file descriptor. If no SQL request is received within the polling timeout period (i.e., the poll returns a timeout indication), the server immediately determines whether the socket connection established via the TCP protocol is normal. Specifically, this is done by checking the TCP... The server determines the client's activity by checking for errors in the socket's status or attempting non-blocking reads. If the TCP connection is normal, the server determines the client is in a normal state but has no requests temporarily, and then continues to wait for the next non-blocking timeout poll. If the TCP connection is abnormal, such as a disconnected connection, the server determines the client is in an abnormal state. At this time, the server can sequentially execute operations such as closing the RoCE RDMA connection, closing the TCP socket connection, and terminating and cleaning up the corresponding database transactions, thereby releasing all associated resources. If an SQL request is detected and polling returns due to an RDMA event notification, the server immediately locates the buffer in the completion queue and receives the SQL command. Subsequently, the database engine processes the command and generates a response. Finally, the processing result is sent through the RoCE RDMA connection, thus forming a complete data transmission and status monitoring closed loop. This ensures that while enjoying the low latency advantages of RoCE to achieve high-speed data exchange, the reliability of the TCP connection can promptly detect the client's status and reclaim resources in case of anomalies. This allows the in-memory database to achieve both high performance and system robustness when deployed across hosts. Figure 2 As shown.

[0066] In telecommunications billing scenarios, the billing processing server, acting as a client, needs to frequently and with low latency access an in-memory database deployed on a separate server to query user balances and update call records. The following example illustrates the technical solution for this scenario. Specifically, it includes the following steps: 1) After the billing processing server starts, it establishes a reliable socket connection with the in-memory database server via the TCP protocol. The billing processing server sends login authentication information through this socket connection, and at the same time sends the GID of its local RoCE network card to the in-memory database server.

[0067] 2) After receiving the login request, the in-memory database server verifies the identity of the billing processing server. Upon successful authentication, the in-memory database server sends its RoCE network interface card's GID to the billing processing server via the established TCP socket connection.

[0068] 3) The two communicating parties use the exchanged GID information—namely, the GID of the billing processing server and the GID of the memory database server—to call RoCE network library functions to establish a dedicated RoCE RDMA connection. This connection provides a physical channel for subsequent high-speed data transmission.

[0069] 4) After the RoCE RDMA connection is successfully established, the memory database server performs a crucial setting: the file descriptor used to receive RDMA event notifications for this connection is set to non-blocking mode. This setting lays the foundation for efficient waiting and monitoring subsequently.

[0070] 5) When a call occurs, the billing server needs to query the user's balance from the in-memory database. The billing server sends the SQL request for the balance query directly to the in-memory database server through the established RoCE RDMA connection.

[0071] 6) While waiting to receive SQL requests, the in-memory database server enters a monitoring loop. The server performs timeout polling on file descriptors set to non-blocking mode for receiving RDMA event notifications, for example, setting the maximum waiting time for each poll to 1 second.

[0072] 7) If an RDMA event notification is received within 1 second, it indicates that the billing processing server has sent an SQL request. The in-memory database server immediately receives the SQL request through the RoCE RDMA connection, quickly completes the balance query in memory, and returns the SQL execution result, including the balance result, to the billing processing server via the same RoCE RDMA connection. Due to the low latency of RoCE, the entire process takes very little time, meeting the real-time requirements of the billing system.

[0073] 8) If the polling times out (i.e., no SQL request is received within 1 second), the in-memory database server checks the status of the TCP socket connection with the billing processing server. The server determines whether the connection is alive by checking the socket error code or performing non-blocking read probes.

[0074] 9) If the check finds that the TCP socket connection status is normal, the server determines that the billing processing server is only temporarily without new billing events to process, and then returns to step 6 above to start the next polling wait. At this time, the server process will not consume a lot of CPU resources.

[0075] 10) If the check finds an abnormal TCP socket connection status, such as a disconnected connection, the server determines that the billing processing server may have malfunctioned or exited abnormally. The server immediately terminates the RDMA connection of RoCE associated with the client and cleans up all incomplete database transactions in the session, such as rolling back call records that are being updated, thereby ensuring the consistency of billing data and releasing system resources.

[0076] Through the above steps, in high-concurrency real-time transaction scenarios for telecommunications billing, the technical solution achieves extremely fast data access through RoCE's RDMA connection, and reliably ensures the system's self-cleaning and robust operation in the event of client anomalies through the combination of TCP connection and non-blocking polling.

[0077] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0078] like Figure 3 As shown, an embodiment of the present invention provides a memory database communication system 200 based on a RoCE network, which includes a connection establishment module 201 and a sending and receiving module 202. The connection establishment module 201 is used to: establish a socket connection with the client via the TCP protocol, receive the GID of the RoCE network card sent by the client, and after successful authentication, send the GID of the server to the client to establish an RDMA connection of RoCE based on the client's GID and the server's GID. The sending and receiving module 202 is used to: receive SQL requests sent by the client through the RDMA connection after the RDMA connection is established, and return the SQL execution result through the RDMA connection.

[0079] Optionally, the above technical solution also includes a monitoring module, which is used to monitor the client's status by checking the status of the socket connection while waiting to receive SQL requests.

[0080] Optionally, in the above technical solution, the monitoring module is specifically used to: perform non-blocking timeout polling on the file descriptor used to receive RDMA event notifications while waiting to receive SQL requests via the RDMA connection; after each polling timeout, check the status of the socket connection established via the TCP protocol; if the socket connection status is normal, determine that the client status is normal and continue to the next polling; if the socket connection status is abnormal, determine that the client status is abnormal and perform the operation of terminating the RDMA connection and cleaning up the corresponding database transaction.

[0081] Optionally, the above technical solution also includes a setting module, which is used to: after establishing the RDMA connection of RoCE based on the client's gid and the server's gid, set the file descriptor used to receive RDMA event notifications to non-blocking mode.

[0082] It should be noted that the beneficial effects of the RoCE network-based memory database communication system 200 provided in the above embodiments are the same as those of the RoCE network-based memory database communication method described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0083] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned memory database communication methods based on RoCE networks.

[0084] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described memory database communication methods based on a RoCE network.

[0085] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0086] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A memory database communication method based on RoCE network, characterized in that, include: Establish a socket connection with the client via TCP protocol, receive the GID of the RoCE network card sent by the client, and after successful authentication, send the GID of the server to the client to establish an RDMA connection of RoCE based on the client's GID and the server's GID. After the RDMA connection is established, the SQL request sent by the client is received through the RDMA connection, and the SQL execution result is returned through the RDMA connection.

2. The memory database communication method based on RoCE network according to claim 1, characterized in that, Also includes: While waiting to receive SQL requests, the client's status is monitored by checking the status of the socket connection.

3. The memory database communication method based on RoCE network according to claim 2, characterized in that, While waiting to receive an SQL request, the client's status is monitored by checking the status of the socket connection. This includes: while waiting to receive an SQL request through the RDMA connection, performing non-blocking timeout polling on the file descriptor used to receive RDMA event notifications; after each polling timeout, checking the status of the socket connection established via the TCP protocol; if the socket connection status is normal, determining that the client's status is normal and continuing with the next poll; if the socket connection status is abnormal, determining that the client's status is abnormal and performing operations to terminate the RDMA connection and clean up the corresponding database transactions.

4. The memory database communication method based on RoCE network according to claim 3, characterized in that, Also includes: After establishing a RoCE RDMA connection based on the client's GID and the server's GID, it also includes setting the file descriptor used to receive RDMA event notifications to non-blocking mode.

5. A memory database communication system based on RoCE network, characterized in that, This includes a connection establishment module and a send / receive module; The connection establishment module is used to: establish a socket connection with the client via the TCP protocol, receive the GID of the RoCE network card sent by the client, and after successful authentication, send the GID of the server to the client to establish an RDMA connection of RoCE based on the client's GID and the server's GID. The sending and receiving module is used to: after the RDMA connection is established, receive the SQL request sent by the client through the RDMA connection, and return the SQL execution result through the RDMA connection.

6. A memory database communication system based on a RoCE network according to claim 5, characterized in that, It also includes a monitoring module, which is used to monitor the status of the client by checking the status of the socket connection while waiting to receive an SQL request.

7. A memory database communication system based on a RoCE network according to claim 6, characterized in that, The monitoring module is specifically used to: perform non-blocking timeout polling of the file descriptor used to receive RDMA event notifications while waiting to receive SQL requests through the RDMA connection; and check the status of the socket connection established through the TCP protocol after each polling timeout. If the socket connection is in a normal state, the client is determined to be in a normal state, and the next polling continues; if the socket connection is in an abnormal state, the client is determined to be in an abnormal state, and the operation of terminating the RDMA connection and clearing the corresponding database transaction is performed.

8. A memory database communication system based on a RoCE network according to claim 7, characterized in that, It also includes a settings module, which is used to: after establishing a RoCE RDMA connection based on the client's gid and the server's gid, set the file descriptor used to receive RDMA event notifications to non-blocking mode.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the memory database communication method based on any one of claims 1 to 4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the memory database communication method based on a RoCE network as described in any one of claims 1 to 4.

Images