A single-port multi-protocol database access method, system, and medium

Abstract

This invention discloses a single-port multi-protocol database access method, system, and medium, belonging to the field of database access technology. It addresses the technical problems of high latency and low throughput of application-layer proxies, and the complexity of operation and maintenance and limited protocol extension of independent port kernel solutions during the migration of heterogeneous databases to the PostgreSQL ecosystem. The method includes: receiving client connection requests through a listening socket and creating a corresponding socket file descriptor; reading preset bytes from the socket buffer as a protocol fingerprint probe using a mounted kernel interceptor; performing protocol state machine matching based on the protocol fingerprint probe to determine the target protocol state machine; transferring read / write control of the socket file descriptor to the target protocol state machine and performing identity authentication; and returning a successful authentication message for the corresponding protocol to the client after successful authentication, completing client access.

Description

Technical Field

[0001] This invention relates to the field of database access technology, and in particular to a single-port multi-protocol database access method, system, and medium. Background Technology

[0002] In modern distributed enterprise information systems, relational databases and client applications rely on dedicated application-layer network communication protocols to complete data interaction. When enterprises migrate heterogeneous databases to PostgreSQL, traditional methods require changing database drivers and rewriting connection logic. This is extremely costly for large-scale microservices and legacy closed-source systems. Protocol-level transparent compatibility has become a core requirement for database modernization.

[0003] Currently, there are two main technical approaches to achieving multi-protocol compatible access: one is a middleware solution based on application-layer proxies, which deploys an independent proxy cluster outside the database. After receiving client connections, it unpacks packets in user space, parses SQL and translates the format, and then establishes a secondary connection with PostgreSQL to forward packets; the other is a kernel fork or dialect plug-in solution based on independent ports, which achieves protocol compatibility at the PostgreSQL kernel level, but requires binding multiple physical ports to listen to different protocols, and some solutions modify the kernel network module through hard coding.

[0004] Proxy layer solutions increase network hop count, frequently involve kernel-to-user context switching and memory copying, leading to a sharp increase in query latency, limited throughput, and an inability to handle kernel-level transactions and locking mechanisms, which can easily cause data inconsistencies. Dedicated port kernel solutions require multiple physical ports, significantly increasing the complexity of cloud-native environment operation and maintenance configuration. Hard forks disrupt the native PostgreSQL code structure, making it difficult to merge with upstream community branches and limiting protocol extensibility. Summary of the Invention

[0005] This invention provides a single-port multi-protocol database access method, system, and medium to solve the following technical problems: during the migration of heterogeneous databases to the PostgreSQL ecosystem, application layer proxies suffer from high latency and low throughput, while independent port kernel solutions are complex to maintain and have limited protocol expansion.

[0006] The embodiments of the present invention adopt the following technical solutions: On one hand, embodiments of the present invention provide a single-port multi-protocol database access method, the method comprising: Receive client connection requests by listening to the socket and create the corresponding socket file descriptor; The mounted kernel interceptor reads preset bytes from the socket buffer as a protocol fingerprint probe. The target protocol state machine is determined by matching the protocol state machine using the protocol fingerprint probe. The read / write control of the socket file descriptor is transferred to the target protocol state machine, and identity authentication is performed; After successful authentication, a success message corresponding to the protocol is returned to the client, completing the client access process.

[0007] In one feasible implementation, a corresponding socket file descriptor is created by receiving client connection requests through a listening socket, specifically including: When the PostgreSQL database starts, a listening socket is created in the underlying service process to listen for client connection requests in real time. When the listening socket receives a client connection request, a socket file descriptor is created in the underlying service process; The underlying service process calls the fork() function to create a backend worker process and completely copies the socket file descriptor, which is then cached in the socket buffer. The standard execution flow of the backend worker process will enter the ProcessStartupPacket processing function.

[0008] In one feasible implementation, a preset byte is read from the socket buffer as a protocol fingerprint probe via a mounted kernel interceptor, specifically including: A kernel interceptor is attached to the worker node of the ProcessStartupPacket processing function; The kernel interceptor calls the recv() function to non-destructively read the first N bytes from the socket receive buffer as the protocol fingerprint probe based on the MSG_PEEK flag. The MSG_PEEK flag ensures that the probe data remains in the socket receive buffer after reading, avoiding byte loss.

[0009] In one feasible implementation, protocol state machine matching is performed based on the protocol fingerprint probe to determine the target protocol state machine, specifically including: The built-in multi-protocol fingerprint matching engine is invoked to dynamically match the state machine in multiple protocol matching branches based on the read protocol fingerprint probes, thereby determining the target protocol state machine. The multiple protocol matching branches include: TDS protocol matching branch, MySQL protocol matching branch, and native PostgreSQL protocol transition branch. The target protocol state machine is either a TDS state machine, a MySQL state machine, or a native PostgreSQL state machine.

[0010] In one feasible implementation, the built-in multi-protocol fingerprint matching engine is invoked to perform dynamic state machine matching across multiple protocol matching branches based on the read protocol fingerprint probes, thereby determining the target protocol state machine. Specifically, this includes: In the TDS protocol matching branch, if the protocol fingerprint probe contains a type identifier and corresponding packet length specification unique to the TDS protocol, then the client type is determined to be a SQL Server client, and the target protocol state machine is the TDS state machine. In the MySQL protocol matching branch, if no legitimate MySQL protocol startup packet bytes actively sent by the client are detected within the set preset time window, and the port does not experience timeout interruption, then a binary handshake message conforming to the MySQL network standard is actively pushed to the client, and the MySQL server enters the listening state; if a MySQL protocol message is detected, then the target protocol state machine is the MySQL state machine. In the native PostgreSQL protocol flow branch, if the standard PostgreSQL protocol startup package length and protocol version number constant are detected, the client type is determined to be a native client, and the target protocol state machine is the native PostgreSQL state machine.

[0011] In one feasible implementation, the read / write control of the socket file descriptor is transferred to the target protocol state machine, and identity authentication is performed, specifically including: The read / write control of the socket file descriptor is transferred to the target protocol state machine via function pointer redirection; Intercept the identity credential information provided by the client; wherein, the identity credential information includes at least the username and the encrypted hash credential; The identity credential information is formatted and encapsulated, and then passed to the AuthSource API at the PostgreSQL kernel level for cross-comparison. If the comparison matches, the client's identity is legitimate; otherwise, the identity is illegitimate.

[0012] In one feasible implementation, after successful authentication, an authentication success message corresponding to the protocol is returned to the client to complete client access, specifically including: After verifying the client's identity, an authentication success message corresponding to the currently used protocol is constructed and returned to the client.

[0013] In one feasible implementation, after successful authentication, an authentication success message corresponding to the protocol is returned to the client. After the client access is completed, the method further includes: After authentication is completed, the underlying setsockopt interface is called to dynamically adjust the preset kernel parameters of the listening socket; Before the database connection is ready to enter the query execution loop, a dedicated state structure is allocated in the memory context of the current worker process, and the global unified configuration variables of the current session are explicitly set; wherein, the global unified configuration variables are used for the subsequent data operation execution process of the execution layer.

[0014] On the other hand, embodiments of the present invention also provide a single-port multi-protocol database access system, the system comprising: The socket listening module is used to receive client connection requests by listening to the socket and create the corresponding socket file descriptor; The protocol feature extraction module is used to read preset bytes from the socket buffer as a protocol fingerprint probe through the mounted kernel interceptor; The multi-protocol state machine matching module is used to perform protocol state machine matching based on the protocol fingerprint probe to determine the target protocol state machine. The identity authentication module is used to transfer the read and write control of the socket file descriptor to the target protocol state machine and perform identity legitimacy authentication; after successful authentication, it returns the corresponding protocol authentication success message to the client to complete the client access.

[0015] Finally, this embodiment of the invention also provides a storage medium, which is a non-volatile computer-readable storage medium storing at least one program, each program including instructions, which, when executed by a terminal, cause the terminal to execute the single-port multi-protocol database access method.

[0016] Compared with the prior art, the single-port multi-protocol database access method, system, and medium provided in this invention have the following beneficial effects: This invention, during the initialization of a database service process to read connection requests, utilizes a single physical TCP listening port and employs non-destructive probe reading technology to perform real-time multi-dimensional feature fingerprint comparison of the network packet buffer for the TDS protocol, MySQL protocol, and native PG protocol suite. This avoids the network resource and operational complexity brought about by multi-port architectures. Furthermore, upon the probe detecting heterogeneous protocol characteristics, without disconnecting and reconnecting, it directly transfers the underlying network file descriptor to the corresponding heterogeneous protocol state machine plugin by overriding the kernel callback function. This completely eliminates the context switching latency and memory copy overhead inherent in application-layer proxy architectures. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart of a single-port multi-protocol database access method provided in an embodiment of the present invention; Figure 2 This invention provides a flowchart illustrating the specific execution process of single-port multi-protocol database access in an embodiment of the invention. Figure 3 This is a schematic diagram of a single-port multi-protocol database access system provided in an embodiment of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0019] This invention provides a single-port multi-protocol database access method, such as... Figure 1 As shown, the single-port multi-protocol database access method specifically includes steps S101-S104: S101. Receive client connection requests through the listening socket and create the corresponding socket file descriptor; read preset bytes from the socket buffer as a protocol fingerprint probe through the mounted kernel interceptor.

[0020] Specifically, when the PostgreSQL database starts, a listening socket is created in the underlying service process to listen for client connection requests in real time. When the listening socket receives a client connection request, a socket file descriptor is created in the underlying service process.

[0021] Furthermore, the fork() function is called in the underlying service process to create a backend worker process, and the socket file descriptor is completely copied and cached in the socket buffer; the standard execution flow of the backend worker process will enter the ProcessStartupPacket processing function.

[0022] Furthermore, a kernel interceptor is mounted on the worker node of the ProcessStartupPacket processing function. The kernel interceptor calls the recv() function to non-destructively read the first N bytes from the socket receive buffer as a protocol fingerprint probe based on the MSG_PEEK flag; the MSG_PEEK flag ensures that the probe data remains in the socket receive buffer after reading, avoiding byte loss.

[0023] As a feasible implementation method, Figure 2 A flowchart illustrating the specific execution process of single-port multi-protocol database access provided in this embodiment of the invention is as follows: Figure 2 As shown, after the database starts, a listening socket is created in the underlying service process to listen for client connection requests in real time. When a client initiates a connection request to the database through a single TCP listening port, a TCP handshake message is automatically sent to that port. Upon receiving the client connection request, the listening socket spawns a backend process based on the Postmaster main process using fork() or a thread pool mechanism. The standard execution flow of the backend process enters the ProcessStartupPacket processing function. To achieve non-intrusive protocol sniffing, this invention attaches a kernel interceptor at this lifecycle node. The interceptor calls the network-level recv() function and, in conjunction with the MSG_PEEK flag, non-destructively reads the first N bytes from the socket's receive buffer as a protocol fingerprint probe. The MSG_PEEK flag ensures that the probe data remains in the kernel buffer after reading, preventing subsequent real protocol parsing failures due to byte loss.

[0024] S102. Match the protocol state machine according to the protocol fingerprint probe to determine the target protocol state machine.

[0025] Specifically, the built-in multi-protocol fingerprint matching engine is invoked, and the state machine is dynamically matched in multiple protocol matching branches based on the read protocol fingerprint probe to determine the target protocol state machine. The multiple protocol matching branches include: TDS protocol matching branch, MySQL protocol matching branch and native PostgreSQL protocol transition branch; the target protocol state machine is either a TDS state machine, a MySQL state machine or a native PostgreSQL state machine.

[0026] As a feasible implementation method, the built-in multi-protocol fingerprint matching engine is invoked. Based on the read protocol fingerprint probe, dynamic state machine matching is performed in multiple protocol matching branches to determine the target protocol state machine, specifically including: In the TDS protocol matching branch, if the protocol fingerprint probe contains a type identifier and corresponding packet length specification unique to the TDS protocol, then the client type is determined to be a SQL Server client, and the target protocol state machine is a TDS state machine. In the MySQL protocol matching branch, if no legitimate MySQL protocol startup packet bytes are detected from the client within the preset time window and the port does not time out, a binary handshake message conforming to the MySQL network standard is actively pushed to the client, and the MySQL server enters the listening state; if a MySQL protocol message is detected, the target protocol state machine is the MySQL state machine. In the native PostgreSQL protocol flow branch, if the standard PostgreSQL protocol startup package length and protocol version number constants are detected, the client type is determined to be a native client, and the target protocol state machine is a native PostgreSQL state machine.

[0027] In one embodiment, such as Figure 2 As shown, after extracting the protocol fingerprint probe, dynamic matching of multi-protocol state machines is performed based on the probe, simultaneously matching the state machines of three branches. If the detected packet header contains a type identifier unique to the TDS protocol (e.g., the first byte is 0x12, representing a Pre-login request) and a specific packet length specification, the engine determines it to be a SQL Server client. A characteristic of the MySQL Wire Protocol is that the server actively sends a handshake initialization packet to the client after the connection is established. If the system does not detect any legitimate startup packet bytes actively sent by the client or detects a specific SSL handshake request within a set small time window, and the port does not experience a timeout interruption, the system actively pushes a binary handshake packet conforming to the MySQL network standard to the client, thus seamlessly switching the connection into the MySQL server listening state. If a standard PostgreSQL protocol startup packet length and protocol version number constant (e.g., 0x00030000 corresponds to the v3 protocol) are detected, it proves to be a native client. At this time, the system immediately releases the interceptor and safely bypasses the execution flow to the kernel's native protocol processing main loop, without interfering with subsequent communication. This step completely eliminates the need for a separate port at the physical network level, effectively preventing the native kernel from throwing exceptions such as "incomplete startup packet" and disconnecting due to its inability to recognize heterogeneous packets.

[0028] S103. Transfer the read / write control of the socket file descriptor to the target protocol state machine and perform identity authentication.

[0029] Specifically, the read and write control of the socket file descriptor is transferred to the target protocol state machine via function pointer redirection.

[0030] Furthermore, the system intercepts the client's identity credentials, which include at least a username and a cryptographic hash credential. This credentials are then formatted, encapsulated, and passed to the AuthSource API at the PostgreSQL kernel level for cross-checking. If the check matches, the client's identity is valid; otherwise, it is invalid.

[0031] As a feasible implementation, after control is transferred to the specific heterogeneous protocol state machine, since PostgreSQL's native access control and dictionary system cannot be disrupted or bypassed, the system intercepts the username and encrypted hash credentials provided by the heterogeneous client, such as MySQL's SHA1 cryptographic hash or the TDS protocol's NTLM credentials. These credentials are extracted, formatted, and encapsulated before being passed to the AuthSource API at the PostgreSQL database kernel level for cross-comparison. Internally, the system transparently executes an equivalent encrypted salt verification algorithm. After verifying the identity, the system constructs and returns an authentication success message for the corresponding protocol to the client, such as the TDS protocol's LoginAck message or the PostgreSQL protocol's AuthenticationOk message.

[0032] S104. After successful authentication, return a successful authentication message of the corresponding protocol to the client to complete the client access.

[0033] Specifically, after verifying the client's identity, an authentication success message corresponding to the currently used protocol is constructed and returned to the client.

[0034] Furthermore, after authentication, the underlying setsockopt interface is called to dynamically adjust the preset kernel parameters of the listening socket. Before the database connection enters the query execution loop, a dedicated state structure is allocated in the memory context of the current worker process, and the global unified configuration variables for the current session are explicitly set; these global unified configuration variables are used in the subsequent data operation execution process of the execution layer.

[0035] As a feasible implementation, heterogeneous applications often rely on long-running connection pools. To prevent these long connections from being silently blocked by intermediate network devices, this invention synchronously takes over the TCP connection-level heartbeat configuration after authentication. By calling the underlying setsockopt interface, it dynamically adjusts kernel parameters such as tcp_keepalives_idle and client_connection_check_interval of the socket, enabling rapid detection of dead connections. More importantly, before the connection is ready to enter the query execution loop, the system immediately allocates a dedicated state structure in the memory context of the current working process and explicitly sets the global unified configuration variable (Grand Unified Configuration, GUC) for the current session. For example, the compatible_mode parameter is set to mysql or sqlserver based on the sniffing results. This global unified configuration variable will become the sole criterion for subsequent system triggering of abstract syntax tree dynamic routing, implicit data type derivation matrix, and system dictionary table virtualization hijacking behavior, thereby achieving end-to-end linkage from the network protocol layer to the SQL syntax layer and then to the execution layer.

[0036] In addition, embodiments of the present invention also provide a single-port multi-protocol database access system, such as... Figure 3 As shown, the single-port multi-protocol database access system 300 specifically includes: The socket listening module 310 is used to receive client connection requests by listening to the socket and create corresponding socket file descriptors; The protocol feature extraction module 320 is used to read preset bytes from the socket buffer as a protocol fingerprint probe through the mounted kernel interceptor; The multi-protocol state machine matching module 330 is used to perform protocol state machine matching based on the protocol fingerprint probe to determine the target protocol state machine; The identity authentication module 340 is used to transfer the read and write control of the socket file descriptor to the target protocol state machine and perform identity legitimacy authentication; after successful authentication, it returns the corresponding protocol authentication success message to the client to complete the client access.

[0037] Finally, this embodiment of the invention also provides a storage medium, which is a non-volatile computer-readable storage medium storing at least one program, each program including instructions, which, when executed by a terminal, cause the terminal to perform: Receive client connection requests by listening to the socket and create the corresponding socket file descriptor; The mounted kernel interceptor reads preset bytes from the socket buffer as a protocol fingerprint probe. The target protocol state machine is determined by matching the protocol state machine using the protocol fingerprint probe. The read / write control of the socket file descriptor is transferred to the target protocol state machine, and identity authentication is performed; After successful authentication, a success message corresponding to the protocol is returned to the client, completing the client access process.

[0038] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0039] The foregoing has described specific embodiments of the present invention. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0040] The above description is merely an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations can be made to the embodiments of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the embodiments of the present invention should be included within the protection scope of the present invention.

Claims

1. A single-port multi-protocol database access method, characterized in that, The method includes: Receive client connection requests by listening to the socket and create the corresponding socket file descriptor; The mounted kernel interceptor reads preset bytes from the socket buffer as a protocol fingerprint probe. The target protocol state machine is determined by matching the protocol state machine using the protocol fingerprint probe. The read / write control of the socket file descriptor is transferred to the target protocol state machine, and identity authentication is performed; After successful authentication, a success message corresponding to the protocol is returned to the client, completing the client access process.

2. The single-port multi-protocol database access method according to claim 1, characterized in that, By receiving client connection requests through the listening socket, a corresponding socket file descriptor is created, specifically including: When the PostgreSQL database starts, a listening socket is created in the underlying service process to listen for client connection requests in real time. When the listening socket receives a client connection request, a socket file descriptor is created in the underlying service process; The underlying service process calls the fork() function to create a backend worker process and completely copies the socket file descriptor, which is then cached in the socket buffer. The standard execution flow of the backend worker process will enter the ProcessStartupPacket processing function.

3. The single-port multi-protocol database access method according to claim 2, characterized in that, The mounted kernel interceptor reads preset bytes from the socket buffer as a protocol fingerprint probe, specifically including: A kernel interceptor is attached to the worker node of the ProcessStartupPacket processing function; The kernel interceptor calls the recv() function to non-destructively read the first N bytes from the socket receive buffer as the protocol fingerprint probe based on the MSG_PEEK flag. The MSG_PEEK flag ensures that the probe data remains in the socket receive buffer after reading, avoiding byte loss.

4. The single-port multi-protocol database access method according to claim 1, characterized in that, The target protocol state machine is determined by matching the protocol state machine based on the protocol fingerprint probe, specifically including: The built-in multi-protocol fingerprint matching engine is invoked to dynamically match the state machine in multiple protocol matching branches based on the read protocol fingerprint probes, thereby determining the target protocol state machine. The multiple protocol matching branches include: TDS protocol matching branch, MySQL protocol matching branch, and native PostgreSQL protocol transition branch. The target protocol state machine is either a TDS state machine, a MySQL state machine, or a native PostgreSQL state machine.

5. A single-port multi-protocol database access method according to claim 4, characterized in that, The built-in multi-protocol fingerprint matching engine is invoked. Based on the read protocol fingerprint probe, dynamic state machine matching is performed across multiple protocol matching branches to determine the target protocol state machine. Specifically, this includes: In the TDS protocol matching branch, if the protocol fingerprint probe contains a type identifier and corresponding packet length specification unique to the TDS protocol, then the client type is determined to be a SQL Server client, and the target protocol state machine is the TDS state machine. In the MySQL protocol matching branch, if no legitimate MySQL protocol startup packet bytes actively sent by the client are detected within the set preset time window, and the port does not experience timeout interruption, then a binary handshake message conforming to the MySQL network standard is actively pushed to the client, and the MySQL server enters the listening state; if a MySQL protocol message is detected, then the target protocol state machine is the MySQL state machine. In the native PostgreSQL protocol flow branch, if the standard PostgreSQL protocol startup package length and protocol version number constant are detected, the client type is determined to be a native client, and the target protocol state machine is the native PostgreSQL state machine.

6. The single-port multi-protocol database access method according to claim 1, characterized in that, The read / write control of the socket file descriptor is transferred to the target protocol state machine, and identity authentication is performed, specifically including: The read / write control of the socket file descriptor is transferred to the target protocol state machine via function pointer redirection; Intercept the identity credential information provided by the client; wherein, the identity credential information includes at least the username and the encrypted hash credential; The identity credential information is formatted and encapsulated, and then passed to the AuthSourceAPI at the PostgreSQL kernel level for cross-comparison. If the comparison matches, the client's identity is legitimate; otherwise, the identity is illegitimate.

7. A single-port multi-protocol database access method according to claim 6, characterized in that, After successful authentication, a success message corresponding to the corresponding protocol is returned to the client, completing the client access process. This includes: After verifying the client's identity, an authentication success message corresponding to the currently used protocol is constructed and returned to the client.

8. A single-port multi-protocol database access method according to claim 1, characterized in that, After successful authentication, an authentication success message corresponding to the protocol is returned to the client. After the client access is completed, the method further includes: After authentication is completed, the underlying setsockopt interface is called to dynamically adjust the preset kernel parameters of the listening socket; Before the database connection is ready to enter the query execution loop, a dedicated state structure is allocated in the memory context of the current worker process, and the global unified configuration variables of the current session are explicitly set; wherein, the global unified configuration variables are used for the subsequent data operation execution process of the execution layer.

9. A single-port multi-protocol database access system, characterized in that, The system includes: The socket listening module is used to receive client connection requests by listening to the socket and create the corresponding socket file descriptor; The protocol feature extraction module is used to read preset bytes from the socket buffer as a protocol fingerprint probe through the mounted kernel interceptor; The multi-protocol state machine matching module is used to perform protocol state machine matching based on the protocol fingerprint probe to determine the target protocol state machine. The identity authentication module is used to transfer the read and write control of the socket file descriptor to the target protocol state machine and perform identity legitimacy authentication; after successful authentication, it returns the corresponding protocol authentication success message to the client to complete the client access.

10. A storage medium, characterized in that, The storage medium is a non-volatile computer-readable storage medium that stores at least one program, each program including instructions that, when executed by a terminal, cause the terminal to perform a single-port multi-protocol database access method according to any one of claims 1-8.

Images