Multi-protocol message processing method, device, equipment, medium and program product

Abstract

The invention provides a multi-protocol message processing method and device, equipment, a medium and a program product. Relates to the technical field of data processing. The method is applied to a database kernel and comprises the following steps: acquiring network connection requests of different protocols by monitoring a plurality of preset ports; loading a corresponding protocol interface according to a protocol type corresponding to the obtained network connection request; in response to a protocol message sent by the client and received through the message receiving interface, calling a message analysis interface to analyze the protocol message according to a message format of a corresponding protocol to obtain a message analysis result; and calling the command execution interface to execute the protocol command based on a message analysis result, and generating a response message of a corresponding protocol through a response message construction interface. According to the method provided by the invention, unified processing of multiple protocols is realized in the kernel layer of the database, the problems of poor protocol compatibility and high operation and maintenance cost in the prior art are solved, and an efficient and safe solution is provided for a mixed service scene.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a multi-protocol message processing method, apparatus, device, medium, and program product. Background Technology

[0002] In enterprise-level database applications, the diverse needs of business systems have driven the diversification of database protocols. Traditional relational databases, such as MySQL and SQL Server's SQL protocol, and NoSQL databases, such as MongoDB's document protocol, differ fundamentally in their data models, query syntax, and protocol formats. To adapt to the needs of upper-layer business applications, different language drivers for different databases may be used. However, deploying multiple databases not only increases management costs but also reduces data processing efficiency.

[0003] Currently, database protocol compatibility is mainly achieved through two technical paths. The first is to use a single-protocol database instance. Traditional databases only support their own proprietary protocols. By deploying multiple independent instances, such as MySQL or MongoDB instances, each listening on a corresponding port, the requirements for multi-protocol access can be met. The second is to introduce protocol proxy middleware. This middleware receives requests from different protocols, converts them to a unified protocol supported by the target database, and then forwards them, enabling the integration of multiple protocols with a single database instance and covering some cross-protocol interaction scenarios.

[0004] However, multi-instance deployment leads to severe resource redundancy, a surge in operational complexity and management costs, and difficulty in guaranteeing data consistency across instances. The middleware's protocol conversion process incurs additional performance overhead and increases processing latency. Summary of the Invention

[0005] The multi-protocol message processing method, apparatus, device, medium, and program products provided in this application embodiment are used to realize a method that can process multiple protocol messages with a single database kernel.

[0006] In a first aspect, embodiments of this application provide a multi-protocol message processing method, the method being applied to a database kernel, the method comprising:

[0007] By listening to multiple preset ports, network connection requests using different protocols are obtained;

[0008] The corresponding protocol interface is loaded according to the protocol type of the obtained network connection request. The protocol interface includes a message receiving interface, a message parsing interface, a command execution interface, and a response message construction interface.

[0009] In response to receiving a protocol message sent by the client through the message receiving interface, the message parsing interface is called to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result;

[0010] Based on the message parsing result, the command execution interface is invoked to execute the protocol command, and the response message construction interface is used to generate the corresponding protocol response message.

[0011] In one possible implementation, the step of calling the message parsing interface to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result includes:

[0012] The protocol message is split into multiple fields according to a predefined protocol message format;

[0013] Extract the corresponding information based on the identifier of each field;

[0014] The information corresponding to each field is stored in the corresponding structure to obtain the message parsing result.

[0015] In one possible implementation, the protocol command is a NoSQL protocol command, and the step of calling the command execution interface to execute the protocol command based on the message parsing result includes:

[0016] Extract the operation information of the NoSQL protocol commands from the message parsing results;

[0017] Based on a preset bidirectional mapping rule, the operation information is subjected to a semantic equivalence mapping from NoSQL operations to SQL operations to obtain the corresponding SQL statement;

[0018] Invoke the SQL execution engine to execute the SQL statement, and receive the execution result returned by the SQL execution engine;

[0019] According to the response format of the NoSQL protocol, the execution result is reverse-mapped into a document result in the corresponding format.

[0020] In one possible implementation, the protocol interface further includes a result acquisition interface and a message sending interface, wherein generating a response message for the corresponding protocol through the response message construction interface includes:

[0021] In response to the command execution interface completing the execution of the protocol command, the execution result is obtained through the result acquisition interface and sent to the message construction interface;

[0022] The execution result is filled into the corresponding protocol's response message structure using the response message construction interface.

[0023] The message sending interface is invoked to generate a response message of the corresponding protocol based on the response message structure;

[0024] The sending strategy is determined based on the protocol characteristics, and the response message is sent to the client according to the sending strategy.

[0025] In one possible implementation, the protocol interface further includes a startup message processing interface and an authentication interface. After loading the corresponding protocol interface according to the protocol type corresponding to the obtained network connection request, the method further includes:

[0026] The startup message is received through the startup message processing interface. The startup message includes connection initialization information, pre-authentication data, and protocol negotiation parameters.

[0027] The relevant information in the startup message is parsed so that the database is initialized according to the relevant information;

[0028] The authentication interface calls the corresponding authentication algorithm interface of each protocol to verify the user's identity information.

[0029] In one possible implementation, the protocol interface further includes an error handling interface, and the method further includes:

[0030] In response to an error occurring at any stage of message processing, the error handling interface is invoked;

[0031] The error information is received through the error handling interface and converted into the standard error format of the corresponding protocol. The error information includes the error code, error description, error occurrence stage, and current connection protocol type.

[0032] The output channel is determined based on the error level and database configuration, and the output channel includes client and database logs.

[0033] Secondly, embodiments of this application provide a multi-protocol message processing apparatus, comprising:

[0034] The acquisition module is used to acquire network connection requests of different protocols by listening to multiple preset ports.

[0035] The loading module is used to load the corresponding protocol interface according to the protocol type of the obtained network connection request. The protocol interface includes a message receiving interface, a message parsing interface, a command execution interface, and a response message construction interface.

[0036] The calling module is used to respond to receiving a protocol message sent by the client through the message receiving interface, and to call the message parsing interface to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result;

[0037] The calling module is also used to call the command execution interface to execute protocol commands based on the message parsing result;

[0038] The generation module is used to generate a response message for the corresponding protocol through the response message construction interface.

[0039] Thirdly, embodiments of this application provide a multi-protocol message processing device, including: a memory and a processor;

[0040] The memory stores computer-executed instructions;

[0041] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0042] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0043] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0044] The multi-protocol message processing method, apparatus, device, medium, and program products provided in this application embodiment, by listening to multiple preset ports, enable a single database kernel to simultaneously receive network connection requests from different protocols. This ensures compatibility with various common protocols, greatly expanding the application scope and compatibility of the database and meeting the needs of different clients and applications interacting with the database using different protocols. Furthermore, it allows the database kernel to flexibly configure the listening ports and corresponding protocols according to actual needs, facilitating deployment and adjustment in different network environments and application scenarios. The processing functions of different protocols are abstracted into independent protocol interfaces, including interfaces for message reception, parsing, command execution, and response message construction, making each interface functionally singular and clear, facilitating development, maintenance, and expansion. The corresponding protocol interface is loaded when establishing a connection, ensuring compatibility with different protocol processing within a single database kernel's processing flow. Different protocols typically have their own message formats with their own characteristics and specifications; the message parsing interface parses the received protocol messages according to the corresponding protocol's message format, accurately extracting various information from the messages. The command execution interface executes the corresponding protocol commands based on the message parsing results to complete various database operations. Different protocol commands can be executed through a unified interface, improving code reusability. The response message construction interface generates a response message that conforms to the protocol format based on the command execution results and the specifications of the corresponding protocol, ensuring that the generated response message meets the requirements of the corresponding protocol and guaranteeing normal communication between the client and the database. Attached Figure Description

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

[0046] Figure 1 An application scenario diagram of a multi-protocol message processing method provided in this application;

[0047] Figure 2 A flowchart illustrating a multi-protocol message processing method provided in an embodiment of this application;

[0048] Figure 3 A flowchart illustrating a multi-protocol message processing method provided in another embodiment of this application;

[0049] Figure 4 A schematic diagram of the structure of a multi-protocol message processing apparatus provided in an embodiment of this application;

[0050] Figure 5 This is a schematic diagram of the structure of a multi-protocol message processing device provided in an embodiment of this application.

[0051] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0053] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0054] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0055] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0056] In enterprise-level database applications, the diversification of business scenarios has led to a diverse range of database protocols. Traditional relational databases, such as MySQL and SQL Server, follow the SQL protocol, which differs significantly from the document protocol used by NoSQL databases in data model design, query syntax rules, and protocol transmission formats. To meet the access needs of different upper-layer businesses, the front end often needs to adapt to the corresponding language drivers of multiple databases. However, the parallel deployment of multiple databases not only significantly increases enterprise management costs but also leads to a decrease in data processing efficiency. Currently, database protocol compatibility mainly relies on two technical solutions. The first is single-protocol database instance deployment. Traditional databases only support their own proprietary protocols, requiring the deployment of multiple independent database instances, each listening on its corresponding protocol port, to achieve multi-protocol access. The second is the introduction of protocol proxy middleware. This middleware receives various protocol requests, converts them into a unified protocol supported by the target database, and then forwards them, thereby achieving the interface between multiple protocols and a single database instance, covering some cross-protocol interaction scenarios. However, multi-instance deployment mode will cause serious resource redundancy, which will not only increase the complexity of operation and maintenance and management costs, but also make it difficult to guarantee the consistency of cross-instance data; while protocol proxy middleware will generate additional performance overhead when performing protocol conversion, significantly increasing data processing latency and failing to meet the high-efficiency operation requirements of business systems.

[0057] Therefore, to address the technical challenges of existing technologies and eliminate the issues of fragmented instance deployments and disjointed protocol processing links in multi-protocol compatibility scenarios, a unified multi-protocol processing mechanism is adopted at a single database kernel layer. Upon receiving network connection requests from different protocols, the corresponding protocol interface is directly loaded and a standardized processing flow is initiated, achieving seamless compatibility of multiple protocols within a single database instance kernel. This avoids resource dispersion and operational complexity issues caused by multi-instance deployments. To resolve the additional performance overhead introduced by protocol proxy middleware, dedicated protocol interfaces are dynamically loaded based on protocol type. Adaptation logic is only invoked when processing requests for the corresponding protocol, eliminating the secondary protocol conversion step of the middleware, reducing ineffective parsing and encapsulation overhead, and improving message processing efficiency. To address the poor scalability caused by fragmented processing logic for different protocols, a standardized interface link for message reception, parsing, command execution, and response construction is abstracted within the database kernel. The processing flow for various protocols is unified into this link, avoiding the need to develop full processing logic separately for each protocol, ensuring the consistency and scalability of the kernel architecture. To address the difficulty in parsing and adapting due to differences in protocol formats, the message parsing interface splits message fields according to the native format of the corresponding protocol and stores the parsing results in a structured manner. This ensures that the parsing results of different protocols can be uniformly invoked by subsequent command execution interfaces, avoiding execution logic confusion caused by format differences and accurately adapting to the processing needs of various protocols. To ensure that multi-protocol response results are compatible with the front-end native driver, a protocol-specific response message construction strategy is adopted. The command execution results are encapsulated into response messages according to the format of the corresponding protocol, avoiding parsing failures caused by format incompatibility in the front-end driver and ensuring the compatibility and stability of multi-protocol interactions.

[0058] Figure 1 An application scenario diagram illustrating the multi-protocol message processing method provided in this application is shown below. Figure 1 As shown in the diagram, the scenario corresponding to the multi-protocol message processing method provided in this application includes: a terminal device 101 and a server 102. The multi-protocol message processing device can be integrated within the server 102.

[0059] Specifically, users can initiate a network connection request by entering their account password and other information in the visual interface of terminal device 101. Server 102 listens to multiple preset ports to obtain network connection requests for different protocols; when a request is received on any port, server 102 loads the corresponding protocol interface according to the protocol type of the obtained network connection request. After the network connection is established, server 102 listens for messages sent by the client in real time. In response, upon receiving a protocol message sent by the client through the message receiving interface, it calls the message parsing interface to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result. Then, based on the message parsing result, it calls the command execution interface to execute the protocol command and generates a response message of the corresponding protocol through the response message construction interface. Server 102 sends the response message to the user through terminal device 101 for the user to view.

[0060] The technical solution of this application and how the technical solution of this application 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 this application will be described below with reference to the accompanying drawings.

[0061] Figure 2 A flowchart illustrating a multi-protocol message processing method provided in an embodiment of this application is shown below. Figure 2 As shown, the execution entity in this embodiment is a multi-protocol message processing device. This device can be implemented through a computer program, such as deployed in a database kernel, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc. Alternatively, it can be implemented through a physical device that integrates or installs the relevant computer program, such as a chip or a multi-protocol message processing device. The multi-protocol message processing device can be a server, a server cluster, etc. The multi-protocol message processing method provided in this embodiment includes the following steps:

[0062] S201. Obtain network connection requests for different protocols by listening to multiple preset ports.

[0063] The default port refers to the network port that the database kernel pre-configures and binds to, corresponding to a specific database protocol, such as port 3306 for the MySQL protocol and port 27017 for the MongoDB protocol.

[0064] Specifically, when the database kernel starts, it reads a pre-configured protocol and port mapping table. This mapping table can be set through a configuration file or kernel initialization parameters, such as `extension_protocol_port`, which opens a port for each protocol. Based on the mapping table, it binds all preset ports. The kernel then calls the operating system's network interface to associate each preset port with the kernel's network listening process, setting the port's listening mode to passive listening. Each port only accepts connection requests for its corresponding protocol, and the listening processes for multiple ports operate independently. When a port detects a TCP three-way handshake request initiated by a front-end client, the listening thread first verifies the request's validity. If the verification is successful, the TCP three-way handshake is completed, establishing a network communication link between the front-end and the kernel.

[0065] Optionally, after the network link is established, the kernel extracts the listening port number corresponding to the request from the established connection, and determines the database protocol type corresponding to the connection request by reverse matching through the protocol and port mapping table. A unique connection ID is assigned to the connection, recording metadata such as protocol type, connection establishment time, and client information, which is used for subsequent protocol interface loading and end-to-end request processing association.

[0066] S202. Load the corresponding protocol interface according to the protocol type of the obtained network connection request. The protocol interface includes message receiving interface, message parsing interface, command execution interface and response message construction interface.

[0067] Among them, the protocol interface refers to the standardized set of functional modules that the database kernel pre-abstracts and implements for different database protocols. Each protocol interface contains the core functional units required to complete the entire process of the protocol and follows a unified interface calling specification, only adapting to the characteristics of the corresponding protocol in the specific implementation logic.

[0068] The message receiving interface is used to receive protocol messages sent by the front-end client based on the established network connection, and is responsible for ensuring the integrity and timing of message reception.

[0069] The message parsing interface is used to split and extract core business information from messages according to the native message format rules of the corresponding protocol, and convert unstructured binary messages into structured data that the kernel can recognize.

[0070] The command execution interface is used to execute protocol commands obtained after message parsing, such as SQL queries and MongoDB document operations, and can reuse the execution engine capabilities of the underlying kernel.

[0071] The response message construction interface is used to encapsulate the command execution result into a response message that conforms to the front-end driver parsing standard, according to the response format requirements of the corresponding protocol.

[0072] Understandably, during the database kernel initialization phase, the pre-registration process for all protocol interfaces to be supported is completed. The kernel reads the mapping configuration between protocol types and interface implementation classes, registers the implementation logic for message reception, parsing, command execution, and response construction interfaces corresponding to various protocols such as MySQL and MongoDB to the kernel's interface management module, and assigns a unique identifier to each protocol interface.

[0073] Specifically, after identifying the protocol type corresponding to the network connection request, the kernel uses that protocol type as a search keyword to match the set of protocol interfaces that completely correspond to that protocol type from the pre-registered interface set. Once an interface match is successful, the kernel initiates the dynamic interface loading process, allocating an independent interface runtime context for the current network connection. Then, it calls the implementation logic of the corresponding protocol interface, loads the interface into that context environment, and initializes the basic resources required for the interface to run.

[0074] Optionally, the kernel records the interface loading information corresponding to the connection in the global interface status table, including loading time, interface version, and runtime context identifier. If the connection is broken or times out, the kernel automatically triggers the interface unloading process, releasing the memory, CPU, and other resources occupied by the interface, and updating the interface status to unloaded. At the same time, the kernel periodically checks the running status of loaded interfaces, and if an interface abnormality is found, it automatically restarts the interface and records the abnormality log.

[0075] S203. In response to receiving a protocol message sent by the client through the message receiving interface, the message parsing interface is called to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result.

[0076] Among them, the protocol message refers to the binary data packet sent by the front-end client based on the established network connection and in accordance with the corresponding database protocol format, which contains core content such as business request information, protocol identifier, and data length.

[0077] Among them, the message parsing result refers to the structured data obtained by the message parsing interface after splitting, extracting and verifying the protocol message according to the protocol format rules. It includes core information that the kernel can directly recognize, such as protocol command type, operation object, parameter information and data content.

[0078] Specifically, the message receiving interface continuously listens for established network connections. When it detects a protocol message sent by a client, it reads the length field in the message based on the message format rules of the corresponding protocol to determine the boundaries of the complete message. Then, it receives all message data within the range indicated by the length field and stores it in a dedicated message buffer.

[0079] Furthermore, after the message is received, the kernel calls the message parsing interface and synchronizes the complete message data in the message buffer and the protocol type information of the current connection to the message parsing interface. The message parsing interface, according to the native message format rules corresponding to the protocol, first splits the message header to extract basic control information such as the protocol version, message type, and sequence number; then it splits the command area to identify the command identifier according to the protocol rules; and then it splits the data area, extracting the operation objects, such as table names, set names, query conditions, and data to be operated, according to the field order and separation rules specified by the protocol. Simultaneously, it converts different types of field data into a kernel-compatible data format according to the protocol rules.

[0080] Furthermore, after extracting all field information, the message parsing interface encapsulates it into a protocol-specific parsing result structure according to a unified structured data specification. After encapsulation, the message parsing interface marks the parsing result as successful and synchronizes the structure to the kernel's result cache. Simultaneously, it triggers the call signal of the subsequent command execution interface, completing the connection between the parsing and execution processes.

[0081] S204. Based on the message parsing result, call the command execution interface to execute the protocol command, and generate the corresponding protocol response message through the response message construction interface.

[0082] Protocol commands refer to the specific business operation instructions parsed from the protocol messages. They are the core requirement carriers of the front-end client and correspond to the native operations of different database protocols, such as SQL query commands for MySQL and document update commands for MongoDB.

[0083] The response message refers to the binary data packet generated by the database kernel after executing the protocol command, according to the response format specification of the corresponding protocol. It contains information such as the command execution result, execution status code, and protocol identifier.

[0084] Specifically, after retrieving the structured message parsing results from the result cache, the kernel extracts the command identifier and protocol type information, and loads the corresponding command adaptation rules based on the protocol type. For example, for SQL protocol commands, it directly matches the command parsing logic of the kernel's SQL execution engine; for NoSQL protocol commands, it loads the preset document operation and SQL operation mapping rules.

[0085] For example, if it is an SQL protocol command, the command execution interface will parse the SQL statement and parameters in the result and pass them directly to the kernel's SQL execution engine. The engine's underlying capabilities such as syntax validation, query optimization, transaction management, and index matching will be reused to perform data query, CRUD and other operations. After the execution is completed, a structured execution result will be obtained.

[0086] Optionally, if it's an anonymous connection in the MongoDB protocol, clients are allowed to connect without specifying a username and password, and can execute some commands after connection, such as viewing version information; however, for other commands involving data operations, authentication is required before execution. Executing such a command on an anonymous connection will result in an error indicating that authentication is required. Users can then complete the authentication process for a specific user using auth-type commands on the anonymous connection.

[0087] Furthermore, after the command execution is complete, the kernel synchronizes the execution result to the response message construction interface and transmits additional information such as the protocol type and message sequence number of the current connection. The response message construction interface loads the response format template for the corresponding protocol and, according to the protocol format template, fills the execution result and additional information into the corresponding fields of the response message one by one. After filling, the interface concatenates the data of each field in the order required by the protocol to form a complete binary response message.

[0088] The multi-protocol message processing method provided in this application embodiment allows a single database kernel to simultaneously receive network connection requests from different protocols by listening to multiple preset ports. This ensures compatibility with various common protocols, greatly expanding the application scope and compatibility of the database and meeting the needs of different clients and applications interacting with the database using different protocols. Furthermore, it allows the database kernel to flexibly configure the listening ports and corresponding protocols according to actual needs, facilitating deployment and adjustment in different network environments and application scenarios. The processing functions of different protocols are abstracted into independent protocol interfaces, including interfaces for message reception, parsing, command execution, and response message construction. This makes each interface functionally singular and clear, facilitating development, maintenance, and expansion. The corresponding protocol interface is loaded when establishing a connection, ensuring compatibility with different protocol processing within a single database kernel's processing flow. Different protocol message formats typically have their own characteristics and specifications. The message parsing interface parses the received protocol messages according to the corresponding protocol's message format, accurately extracting various information from the messages. The command execution interface executes the corresponding protocol commands based on the message parsing results, completing various database operations. Different protocol commands can be executed through a unified interface, improving code reusability. The response message construction interface generates a response message that conforms to the protocol format based on the result of command execution and the specifications of the corresponding protocol, ensuring that the generated response message meets the requirements of the corresponding protocol and guaranteeing normal communication between the client and the database.

[0089] As an optional implementation, based on the above embodiments, the message parsing interface is called to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result, including:

[0090] The protocol message is split into multiple fields according to a predefined protocol message format;

[0091] Extract the corresponding information based on the identifier of each field;

[0092] The information corresponding to each field is stored in the corresponding structure to obtain the message parsing result.

[0093] Among them, the predefined protocol message format refers to the set of format rules that the database kernel predefines for each supported database protocol, which are completely consistent with the native message specification of that protocol.

[0094] Specifically, after the message parsing interface is invoked, it loads the corresponding predefined protocol message format from the kernel's protocol rule library based on the protocol type of the current connection, and initializes the basic rules for message splitting. It reads the complete protocol message from the message buffer and splits the message segment by segment according to the loaded splitting rules. After message splitting is complete, the interface iterates through all the split fields, identifies the unique identifier for each field, and for explicit identifier fields, directly reads the identifier and matches it with the preset field type, then extracts the core information within the field based on the field type. For implicit identifier fields, the interface matches the corresponding field type based on the field's position in the message, then extracts the field's numerical or character information.

[0095] Furthermore, based on the current protocol type, the interface calls a preset protocol-specific structure template and, according to the mapping relationship between data items and message fields in the structure template, fills the extracted field information into the corresponding positions of the structure one by one. After all information is filled in, the interface adds a parsing status flag to the structure and stores the structure as the final message parsing result in the kernel's result cache. At the same time, it sends a parsing completion signal to the subsequent command execution interface, completing the entire parsing process.

[0096] The multi-protocol message processing method provided in this application addresses the significant differences in message formats between different protocols. By predefined format splitting and structure storage, a protocol plug-in architecture can be implemented. When adding a new protocol, only its message format and structure template need to be defined, without modifying the core parsing logic, which conforms to the open / closed principle. After storing field information in the structure, the command execution interface can directly access the data through the field name, reducing the overhead of repeated parsing.

[0097] As an optional implementation, based on the above embodiments, the protocol command is a NoSQL protocol command, and the protocol command is executed by calling the command execution interface based on the message parsing result, including:

[0098] Extract operation information of NoSQL protocol commands from message parsing results;

[0099] Based on the preset bidirectional mapping rules, the operation information is semantically mapped from NoSQL operations to SQL operations to obtain the corresponding SQL statements;

[0100] It calls the SQL execution engine to execute SQL statements and receives the execution results returned by the SQL execution engine;

[0101] According to the response format of the NoSQL protocol, the execution result is reverse-mapped into a document result in the corresponding format.

[0102] Among them, NoSQL protocol commands specifically refer to the native operation commands of non-relational databases, such as MongoDB. They take documents as the core operation objects and include types such as query, insert, update, and delete. Their syntax and operation logic are fundamentally different from SQL protocol commands.

[0103] Among them, the preset bidirectional mapping rules refer to the set of rules pre-defined by the database kernel to achieve semantic equivalence conversion between NoSQL operations and SQL operations.

[0104] Semantic equivalence mapping refers to maintaining the core business logic of the operation unchanged during the mapping process, only converting the data representation and instruction format. For example, MongoDB's query operation on a specified field in a collection is mapped to the SQL SELECT operation on a specified field FROM table WHERE condition.

[0105] Specifically, the command execution interface accurately extracts the full operation information of the NoSQL protocol command from the structured structure of the message parsing result, including the operation type, target object, data content, filtering conditions, and additional rules. After extraction, it loads the forward mapping rules from the preset bidirectional mapping rules to map the NoSQL collection name to the SQL table name; and matches the corresponding SQL statement template according to the operation type, such as mapping the MongoDB find operation to the SQL SELECT statement.

[0106] Furthermore, the command execution interface passes the transformed SQL statement and parameters to the kernel's native SQL execution engine, which performs data operations according to standard SQL logic. After execution, the SQL engine returns a structured execution result, including execution status and business results. The interface loads the reverse mapping rules from the preset bidirectional mapping rules, converts the SQL execution result into the native document format of the NoSQL protocol, adds protocol-specific identifiers to the document result according to the NoSQL protocol response specifications, and encapsulates the document result into binary BSON format.

[0107] The multi-protocol message processing method provided in this application ensures that the semantics of NoSQL operations are fully preserved in SQL through preset bidirectional mapping rules. It directly calls existing SQL execution engines, eliminating the need to develop a separate storage engine for NoSQL protocols. The SQL execution results are reverse-mapped to the document format of the NoSQL protocol, ensuring that clients can continue to use it without modification. This enables the same database to simultaneously support access via SQL and NoSQL protocols, with consistent result formats.

[0108] As an optional implementation, based on the above embodiments, the protocol interface further includes a result acquisition interface and a message sending interface, and generates a response message for the corresponding protocol through a response message construction interface, including:

[0109] In response to the command execution interface completing the execution of the protocol command, the execution result is obtained through the result acquisition interface and then sent to the message construction interface;

[0110] The execution result is filled into the response message structure of the corresponding protocol by constructing the interface using the response message;

[0111] The message sending interface is invoked to generate a response message for the corresponding protocol based on the response message structure;

[0112] The sending strategy is determined based on the protocol characteristics, and the response message is sent to the client according to the sending strategy.

[0113] The result acquisition interface is used to extract standardized execution result data from the execution result buffer of the command execution interface, and to perform preliminary verification and unified encapsulation of the result format.

[0114] The message sending interface is used to convert the response message structure into a binary response message that conforms to the corresponding protocol specification, and to formulate a sending strategy based on the protocol characteristics to send the message to the client through the network link.

[0115] The response message structure refers to the memory data structure that the database kernel pre-sets for each protocol and corresponds to the response message format.

[0116] Among them, the sending strategy refers to the message sending rules formulated for the interaction characteristics of different protocols, covering the sending sequence, fragmentation strategy, retransmission mechanism, etc.

[0117] Specifically, after the command execution interface completes the execution of the protocol command, it writes the execution result to a dedicated execution result buffer and triggers the call signal of the result retrieval interface. After the result retrieval interface is triggered, it first verifies the integrity of the execution result in the buffer and filters out redundant execution logs and other irrelevant data; it then encapsulates the execution result in a unified format, extracts the core content, and after encapsulation, the result retrieval interface synchronizes the processed execution result to the response message construction interface and transmits additional information such as the protocol type and message sequence number of the current connection.

[0118] Furthermore, after receiving the execution result, the response message construction interface loads the corresponding response message structure template according to the protocol type and initializes the structure's memory space. Data is then filled in one by one according to the mapping relationship between the fields in the template and the execution result. After all fields are filled, the interface recalculates the total message length and updates the message header length field of the structure, completing the full filling of the response message structure. After receiving the filled response message structure, the message sending interface initiates the binary message generation process, converting the structured data in the structure into a continuous binary byte stream. After the conversion is complete, a complete binary response message is generated.

[0119] Optionally, in addition to the execution result, there may be message sequence numbers and other content that is unrelated to the result but needs to be included in the response message. These should also be constructed in the response message construction interface.

[0120] Furthermore, for single-message response protocols, a one-time transmission strategy is adopted, directly sending the complete binary response message to the client through the established network link. For multi-message sequential response protocols, a phased transmission strategy is adopted, generating and sending multiple response messages sequentially according to the interaction sequence specified in the protocol. The next message is sent only after the previous message has been sent and confirmed by the client. For large-message response protocols, a fragmentation transmission strategy is adopted, splitting the binary response message into multiple fixed-size fragments and sending them sequentially according to their fragment sequence numbers. The total number of fragments and the current fragment sequence number are marked in the message. After receiving the message, the client can reassemble it into a complete message according to the sequence numbers.

[0121] Optionally, during the sending process, the interface monitors the network status in real time. If an abnormality such as link disconnection or sending timeout occurs, the error handling interface is triggered to record the sending failure log and decide whether to retry or close the connection according to the protocol rules. After successful sending, the connection status is updated to "response sent", completing this response process.

[0122] The multi-protocol message processing method provided in this application splits response message processing into three independent interfaces, each focusing on a single responsibility. This allows each module to be developed, tested, and optimized independently, reducing code coupling. When adding support for a new protocol, only the corresponding response message structure and sending strategy need to be implemented for the new protocol, without modifying the core logic. Regardless of whether the protocol command is SQL or NoSQL, the execution result is transmitted in a unified format through the result retrieval interface, masking the differences in execution results between different protocols. The message construction interface selects the corresponding response message structure template according to the protocol type, fills the template with the general execution result, and generates a protocol-specific response format, ensuring that the generated message strictly conforms to the protocol specification. The sending strategy is dynamically adjusted according to protocol characteristics to respond to actual protocol requirements.

[0123] As an optional implementation, based on the above embodiments, the protocol interface further includes a startup message processing interface and an authentication interface. After loading the corresponding protocol interface according to the protocol type corresponding to the obtained network connection request, it also includes:

[0124] The startup message is received through the startup message processing interface. The startup message includes connection initialization information, pre-authentication data, and protocol negotiation parameters.

[0125] Parse the relevant information in the startup message so that the database can be initialized based on the relevant information;

[0126] The authentication interface calls the corresponding authentication algorithm interface of each protocol to verify the user's identity information.

[0127] The startup message processing interface is used to receive and parse the first protocol message sent by the client or server after the network connection is established, namely the startup message.

[0128] Pre-authentication data refers to lightweight authentication-related data transmitted in advance in the startup message, such as client identifier, encryption algorithm negotiation parameters, and temporary credentials.

[0129] The authentication interface is used to integrate the authentication logic of various protocols, providing a unified authentication call entry point that can adapt to the authentication process of different protocols.

[0130] Among them, the authentication algorithm interface refers to the dedicated authentication algorithm module that the kernel pre-implements for each protocol, such as the mysql_native_password algorithm for MySQL.

[0131] Specifically, after the protocol interface is loaded, the kernel immediately activates the startup message processing interface. This interface binds to the currently established network connection and enters a continuous listening state. For protocols where the client sends the startup message first, when a binary data packet sent by the client is detected, it confirms that it is the startup message of that protocol, receives the complete message, and stores it in the startup message buffer. For protocols where the server sends the startup message first, the interface actively constructs a startup message conforming to the protocol specification, sends it to the client, and then receives the acknowledgment startup message returned by the client.

[0132] Furthermore, the startup message processing interface performs layered parsing on the startup message in the buffer, extracting connection initialization information, pre-authentication data, and protocol negotiation parameters. Based on the parsing results, the kernel initializes core resources for the current connection, including allocating a connection ID, binding protocol-specific interaction rules, and initializing the state machine. After connection initialization is complete, the kernel activates the authentication interface and initiates the authentication process. The authentication interface reads the protocol type from the connection context, loads the corresponding authentication algorithm interface from the kernel's authentication algorithm library (e.g., MySQL loads the mysql_native_password algorithm interface, MongoDB loads the SCRAM-SHA-256 algorithm interface), and simultaneously reads the pre-authentication data from the startup message as input parameters for the authentication algorithm.

[0133] Optionally, during the startup message parsing phase, an SSL handshake is performed according to the database configuration or negotiation protocol to ensure that startup message interactions and subsequent interactions are all encrypted to guarantee security.

[0134] Optionally, for a single-round authentication protocol, the authentication interface receives identity credentials sent by the client, such as username, password hash, and client certificate, and calls the authentication algorithm interface to verify the credentials, such as comparing the client's password hash with the hash value stored in the kernel and verifying the legality of the certificate chain. For a multi-round authentication protocol, the authentication interface, according to the algorithm requirements, first sends a challenge value to the client, receives the response value returned by the client, and then calls the authentication algorithm interface to complete the challenge and response verification. During this process, the pre-authentication data in the startup message is reused to reduce the number of interactions.

[0135] Optionally, if the SSL handshake is completed during the startup message phase, the server can perform certificate authentication for the client in the authentication interface according to the configuration, thereby improving the SSL security level.

[0136] Optionally, if the MongoDB protocol allows users to log in anonymously, the authentication interface can be considered to have completed authentication based on the actual situation of the front-end message. In the subsequent command execution interface, it can be determined whether the MongoDB protocol command needs to be authenticated before execution and whether the current connection has completed authentication.

[0137] The multi-protocol message processing method provided in this application abstracts the connection initialization logic of each protocol through a startup message processing interface, unifying the handshake process of different protocols into a standard flow. It processes connection establishment requests through a single set of interfaces, reducing code duplication. The authentication interface calls the authentication algorithm interfaces corresponding to each protocol, achieving protocol-authentication logic matching while ensuring both compatibility and security.

[0138] As an optional implementation, based on the above embodiments, the protocol interface further includes an error handling interface, and the method further includes:

[0139] In response to an error occurring at any stage of message processing, the error handling interface is invoked;

[0140] Error information is received through the error handling interface and converted into the standard error format of the corresponding protocol. The error information includes the error code, error description, stage of error occurrence, and protocol type of the current connection.

[0141] The output channels are determined based on the error level and database configuration. The output channels include client logs and database logs.

[0142] The error handling interface is used to handle expected errors that occur in any stage of the database kernel, such as message reception, parsing, command execution, response construction, and message sending. It provides a unified error handling entry point and implements functions such as error format conversion, output channel decision-making, and process termination.

[0143] Error information refers to a standardized data set generated by the kernel after capturing an error, including the error code, error description, and the stage at which the error occurred.

[0144] Error levels refer to the kernel's classification of errors based on their scope and severity. For example, a minor error only affects a single operation; a moderate error affects the current connection; and a severe error affects kernel resources.

[0145] Database configuration refers to the error handling rules that are set in advance in the database kernel, such as minor errors needing to be reported to the client, and major errors only being written to the log.

[0146] Specifically, during any message processing stage—including message reception, parsing, command execution, response construction, message sending, initiation of message processing, and authentication—if the database kernel detects an expected error, such as an invalid format during message parsing or insufficient permissions when executing a command, the kernel immediately terminates the current processing flow and generates standardized error information containing the error code, error description, stage of error occurrence, and protocol type. The kernel then uses this error information as input parameters to call a globally unified error handling interface.

[0147] Furthermore, after receiving the error information from the kernel, the error handling interface initiates a format conversion process. Based on the protocol type of the current connection in the error information, it loads the standard error format rules for the corresponding protocol from the kernel's protocol error rule library, mapping the kernel's unified error code to the native error code of the corresponding protocol. It then adjusts the language and format of the error description according to the protocol specification. Finally, the converted error code and description, combined with the additional fields required by the protocol, are encapsulated into the standard error data format for that protocol.

[0148] Furthermore, the error handling interface determines the output channel for the error information based on the error level in the error message and the pre-configured database error handling rules. For example, if the error level is minor or moderate, and the database configuration requires that this type of error be reported back to the client, then the response message construction interface is called to fill the error data in the standard protocol format into the response message structure of the corresponding protocol, and then the message sending interface is called to send the error response message to the client according to the message sending strategy of the protocol.

[0149] Optionally, the error level is set to severe, or the database configuration requires that only logs be recorded and no feedback be sent to the client; according to the database log specification, the error information is organized into standardized log entries and written to the specified database log file.

[0150] The multi-protocol message processing method provided in this application can invoke the error handling interface when an error occurs at any stage of message processing, ensuring that the system will not crash or behave unpredictably due to unhandled errors, thus guaranteeing the overall stability of the system. The received error information is converted into the standard error format of the corresponding protocol, enabling different modules and systems to follow a unified standard when handling errors.

[0151] Figure 3 A flowchart illustrating a multi-protocol message processing method provided in another embodiment of this application is shown below. Figure 3 As shown, the multi-protocol message processing method provided in this embodiment is a specific implementation of the NoSQL protocol. Therefore, the multi-protocol message processing method provided in this embodiment includes the following steps:

[0152] S301: Obtain network connection requests for different protocols by listening to multiple preset ports.

[0153] S302. Load the corresponding protocol interface according to the protocol type of the obtained network connection request. The protocol interface includes the interface for processing startup messages, the interface for receiving authentication messages, the interface for parsing messages, the interface for executing commands, the interface for constructing response messages, the interface for obtaining results, and the interface for sending messages.

[0154] S303. Receive a startup message through the startup message processing interface. The startup message includes connection initialization information, pre-authentication data, and protocol negotiation parameters.

[0155] S304. Parse the relevant information in the startup message so that the database can be initialized according to the relevant information.

[0156] S305. Verify user identity information by calling the authentication algorithm interface corresponding to each protocol through the authentication interface.

[0157] S306. In response to receiving a protocol message sent by the client through the message receiving interface, the protocol message is split into multiple fields according to the predefined protocol message format.

[0158] S307. Extract the corresponding information based on the identifier of each field.

[0159] S308. Store the information corresponding to each field in the corresponding structure to obtain the message parsing result.

[0160] S309. Extract the operation information of NoSQL protocol commands from the message parsing results.

[0161] S310. Based on the preset bidirectional mapping rules, perform a semantic equivalence mapping from NoSQL operations to SQL operations on the operation information to obtain the corresponding SQL statement.

[0162] S311. Call the SQL execution engine to execute the SQL statement and receive the execution result returned by the SQL execution engine.

[0163] S312. According to the response format of the NoSQL protocol, the execution result is reverse-mapped to the corresponding document result format.

[0164] S313. In response to the command execution interface completing the execution of the protocol command, obtain the execution result through the result acquisition interface and send the execution result to the message construction interface.

[0165] S314. Use the response message construction interface to fill the execution result into the response message structure of the corresponding protocol.

[0166] S315. Call the message sending interface to generate a response message of the corresponding protocol based on the response message structure.

[0167] S316. Determine the sending strategy based on the protocol characteristics and send the response message to the client according to the sending strategy.

[0168] In this embodiment, the implementation method and technical effect of S301-S316 are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0169] Figure 4 A schematic diagram of the structure of the multiprotocol message processing apparatus provided in this application is shown below. Figure 4 As shown, the multi-protocol message processing device 40 provided in this embodiment includes: an acquisition module 41, a loading module 42, a calling module 43, and a generation module 44.

[0170] The system includes: an acquisition module 41, used to acquire network connection requests of different protocols by listening to multiple preset ports; a loading module 42, used to load the corresponding protocol interface according to the protocol type of the acquired network connection request, the protocol interface including a message receiving interface, a message parsing interface, a command execution interface, and a response message construction interface; a calling module 43, used to respond to a protocol message sent by the client through the message receiving interface by calling the message parsing interface to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result; the calling module 43 is also used to call the command execution interface to execute the protocol command based on the message parsing result; and a generation module 44, used to generate a response message of the corresponding protocol through the response message construction interface.

[0171] The multi-protocol message processing device provided in this embodiment can perform... Figure 2 The implementation principles and technical effects of the methods shown are similar, and will not be repeated here.

[0172] Optionally, when calling module 43 to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result, the specific functions are: splitting the protocol message into multiple fields according to the predefined protocol message format; extracting the corresponding information according to the identifier of each field; and storing the information corresponding to each field in the corresponding structure to obtain the message parsing result.

[0173] Optionally, the protocol command is a NoSQL protocol command. When calling module 43 to execute the protocol command by calling the command execution interface based on the message parsing result, it is specifically used to: extract the operation information of the NoSQL protocol command from the message parsing result; perform semantic equivalence mapping from NoSQL operation to SQL operation on the operation information based on the preset bidirectional mapping rules to obtain the corresponding SQL statement; call the SQL execution engine to execute the SQL statement and receive the execution result returned by the SQL execution engine; and reverse map the execution result into a document result in the corresponding format according to the response format of the NoSQL protocol.

[0174] Optionally, the protocol interface also includes a result acquisition interface and a message sending interface. The generation module 44, when generating a response message for the corresponding protocol through the response message construction interface, is specifically used for: responding to the completion of the execution of the protocol command by the command execution interface, obtaining the execution result through the result acquisition interface and sending the execution result to the message construction interface; using the response message construction interface to fill the execution result into the response message structure of the corresponding protocol; calling the message sending interface to generate a response message for the corresponding protocol based on the response message structure; determining the sending strategy according to the protocol characteristics and sending the response message to the client according to the sending strategy.

[0175] Optionally, the multi-protocol message processing apparatus provided in this embodiment further includes a receiving module and a parsing module.

[0176] Accordingly, the protocol interface also includes a startup message processing interface and an authentication interface. A receiving module is used to receive a startup message through the startup message processing interface. The startup message includes connection initialization information, pre-authentication data, and protocol negotiation parameters. A parsing module is used to parse the relevant information in the startup message so as to initialize the database based on the relevant information. A calling module 43 is also used to call the authentication algorithm interface corresponding to each protocol through the authentication interface to verify the user's identity information.

[0177] Optionally, the multi-protocol message processing apparatus provided in this embodiment further includes a conversion module and a determination module.

[0178] Accordingly, the protocol interface also includes an error handling interface, a calling module 43, which is also used to call the error handling interface in response to an error occurring at any stage of message processing; a receiving module, which is also used to receive error information through the error handling interface; a conversion module, which is used to convert the error information into the standard error format of the corresponding protocol, the error information including the error code, error description, error occurrence stage and the protocol type of the current connection; and a determination module, which is used to determine the output channel based on the error level and database configuration, the output channel including the client and database logs.

[0179] Figure 5 A schematic diagram of the structure of the multi-protocol message processing device provided in this application. (See attached diagram.) Figure 5 As shown, the multi-protocol message processing device 50 provided in this embodiment includes a processor 51 and a memory 52. ​​The processor 51 and the memory 52 are connected via a bus and communicate with each other.

[0180] In the specific implementation process, the processor 51 executes the computer execution instructions stored in the memory 52, causing the processor 51 to perform the above-described method.

[0181] The specific implementation process of processor 51 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0182] In the above embodiments, it should be understood that the processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0183] The memory 52 may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0184] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0185] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0186] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0187] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0188] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0189] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0190] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0191] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0192] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0193] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0194] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A multi-protocol message processing method, characterized in that, The method is applied to a database kernel, and the method includes: By listening to multiple preset ports, network connection requests using different protocols are obtained; The corresponding protocol interface is loaded according to the protocol type of the obtained network connection request. The protocol interface includes a message receiving interface, a message parsing interface, a command execution interface, and a response message construction interface. In response to receiving a protocol message sent by the client through the message receiving interface, the message parsing interface is called to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result; Based on the message parsing result, the command execution interface is invoked to execute the protocol command, and the response message construction interface is used to generate the corresponding protocol response message.

2. The method according to claim 1, characterized in that, The step of calling the message parsing interface to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result includes: The protocol message is split into multiple fields according to a predefined protocol message format; Extract the corresponding information based on the identifier of each field; The information corresponding to each field is stored in the corresponding structure to obtain the message parsing result.

3. The method according to claim 1, characterized in that, The protocol command is a NoSQL protocol command, and the step of calling the command execution interface to execute the protocol command based on the message parsing result includes: Extract the operation information of the NoSQL protocol commands from the message parsing results; Based on a preset bidirectional mapping rule, the operation information is subjected to a semantic equivalence mapping from NoSQL operations to SQL operations to obtain the corresponding SQL statement; Invoke the SQL execution engine to execute the SQL statement, and receive the execution result returned by the SQL execution engine; According to the response format of the NoSQL protocol, the execution result is reverse-mapped into a document result in the corresponding format.

4. The method according to claim 1, characterized in that, The protocol interface further includes a result acquisition interface and a message sending interface. The step of generating a response message for the corresponding protocol through the response message construction interface includes: In response to the command execution interface completing the execution of the protocol command, the execution result is obtained through the result acquisition interface and sent to the message construction interface; The execution result is filled into the corresponding protocol's response message structure using the response message construction interface. The message sending interface is invoked to generate a response message of the corresponding protocol based on the response message structure; The sending strategy is determined based on the protocol characteristics, and the response message is sent to the client according to the sending strategy.

5. The method according to claim 1, characterized in that, The protocol interface also includes a startup message processing interface and an authentication interface. After loading the corresponding protocol interface according to the protocol type of the obtained network connection request, it further includes: The startup message is received through the startup message processing interface. The startup message includes connection initialization information, pre-authentication data, and protocol negotiation parameters. The relevant information in the startup message is parsed so that the database is initialized according to the relevant information; The authentication interface calls the corresponding authentication algorithm interface of each protocol to verify the user's identity information.

6. The method according to claim 1, characterized in that, The protocol interface also includes an error handling interface, and the method further includes: In response to an error occurring at any stage of message processing, the error handling interface is invoked; The error information is received through the error handling interface and converted into the standard error format of the corresponding protocol. The error information includes the error code, error description, error occurrence stage, and current connection protocol type. The output channel is determined based on the error level and database configuration, and the output channel includes client and database logs.

7. A multi-protocol message processing apparatus, characterized in that, include: The acquisition module is used to acquire network connection requests of different protocols by listening to multiple preset ports. The loading module is used to load the corresponding protocol interface according to the protocol type of the obtained network connection request. The protocol interface includes a message receiving interface, a message parsing interface, a command execution interface, and a response message construction interface. The calling module is used to respond to receiving a protocol message sent by the client through the message receiving interface, and to call the message parsing interface to parse the protocol message according to the message format of the corresponding protocol to obtain the message parsing result; The calling module is also used to call the command execution interface to execute protocol commands based on the message parsing result; The generation module is used to generate a response message for the corresponding protocol through the response message construction interface.

8. A multi-protocol message processing device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images