CN116760912A

CN116760912A - Transaction realization method and system based on protocol conversion

Info

Publication number: CN116760912A
Application number: CN202311041408.9A
Authority: CN
Inventors: 要军杰; 谌明; 鲍荣善
Original assignee: Hangzhou Xingrui Network Information Technology Co ltd
Current assignee: Hangzhou Xingrui Network Information Technology Co ltd
Priority date: 2023-08-18
Filing date: 2023-08-18
Publication date: 2023-09-15

Abstract

The embodiment of the specification provides a transaction realization method and system based on protocol conversion. Wherein the method is performed by a server and comprises: receiving a first transaction request from a client based on a first protocol; converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service; the protocol conversion service comprises a protocol mapping code, a protocol mapping table and a tag data dictionary; transmitting the second transaction request to the transaction system so that the transaction system generates a transaction result according to the second transaction request; converting the transaction result into a response message based on a first protocol through a protocol conversion service; and sending the response message to the client.

Description

Transaction realization method and system based on protocol conversion

Technical Field

The present disclosure relates to the field of financial transactions, and in particular, to a method and system for implementing a transaction based on protocol conversion.

Background

Currently, suppliers of different transaction systems typically have their own transaction systems, and each transaction system has its own communication protocol. For various reasons, each trading party (e.g., dealer) may use different suppliers' trading systems, which results in different trading systems being accessed within the dealer and requiring development using different vendor protocols. And each manufacturer has insufficient support to the corresponding protocol due to various historical legacy problems, so that the actual accessed protocol and standard are disordered.

Accordingly, embodiments of the present disclosure provide a method and system for implementing transactions based on protocol conversion to implement transaction implementation in transaction systems of different protocols.

Disclosure of Invention

Some embodiments of the present specification provide a transaction implementation method based on protocol conversion, the method being performed by a server, the method comprising: receiving a first transaction request from a client based on a first protocol; converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service; the protocol conversion service comprises a protocol mapping code, a protocol mapping table and a tag data dictionary; transmitting the second transaction request to a transaction system so that the transaction system generates a transaction result according to the second transaction request; converting the transaction result into a response message based on a first protocol through the protocol conversion service; and sending the response message to the client.

Other embodiments of the present specification provide a transaction implementation system based on protocol conversion, the system comprising an RPC master station system for performing the following operations: receiving a first transaction request from a client based on a first protocol; converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service; the protocol conversion service comprises a protocol mapping code, a protocol mapping table and a tag data dictionary; transmitting the second transaction request to a transaction system so that the transaction system generates a transaction result according to the second transaction request; converting the transaction result into a response message based on a first protocol through the protocol conversion service; and sending the response message to the client.

Other embodiments of the present disclosure provide a transaction implementation device based on protocol conversion, including a processor, where the processor is configured to perform the transaction implementation method based on protocol conversion.

Drawings

The present specification will be further elucidated by way of example embodiments, which will be described in detail by means of the accompanying drawings. The embodiments are not limiting, in which like numerals represent like structures, wherein:

FIG. 1 is a schematic illustration of an application scenario of a protocol conversion based transaction implementation system according to some embodiments of the present description;

FIG. 2 is an exemplary timing diagram of a protocol conversion based transaction implementation method according to some embodiments of the present description;

FIG. 3 is an exemplary schematic diagram of a FIX protocol format shown in accordance with some embodiments of the present description;

FIG. 4 is an exemplary block diagram of a protocol conversion based transaction implementation system according to some embodiments of the present description;

fig. 5 is an exemplary schematic diagram of a protocol conversion based transaction flow shown in accordance with some embodiments of the present description.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings that are required to be used in the description of the embodiments will be briefly described below. It is apparent that the drawings in the following description are only some examples or embodiments of the present specification, and it is possible for those of ordinary skill in the art to apply the present specification to other similar situations according to the drawings without inventive effort. Unless otherwise apparent from the context of the language or otherwise specified, like reference numerals in the figures refer to like structures or operations.

It will be appreciated that "system," "apparatus," "unit" and/or "module" as used herein is one method for distinguishing between different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

As used in this specification and the claims, the terms "a," "an," "the," and/or "the" are not specific to a singular, but may include a plurality, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that the steps and elements are explicitly identified, and they do not constitute an exclusive list, as other steps or elements may be included in a method or apparatus.

A flowchart is used in this specification to describe the operations performed by the system according to embodiments of the present specification. It should be appreciated that the preceding or following operations are not necessarily performed in order precisely. Rather, the steps may be processed in reverse order or simultaneously. Also, other operations may be added to or removed from these processes.

Currently, internationalization of transaction systems requires FIX (Financial Information eXchange) data exchange protocols that support the mainstream in the financial arts. The current RPC (Remote Procedure Call ) master station already supports a Protocol buf (Protocol Buffers, abbreviated as ProtoBuf) communication Protocol, and when client communication adopts FIX Protocol, the RPC master station needs to implement FIX Protocol and ProtoBuf Protocol conversion. For FIX protocol conversion, at least the following three types of conversion are required: 1. business script conversion: searching a service script corresponding to the FIX message in a script list according to service type information in the service data, storing service scripts corresponding to versions of different FIX protocols in the script list, and processing the service data according to service logic when executing the service scripts; 2. XML (Extensible Markup Language ) format conversion: and analyzing the message header and each field ID of the check message header of the message by the FIX format message received by the service layer. Analyzing the message body according to the mode related to the MsgType call in the FIX protocol, and finally generating an XML format message meeting the requirements; 3. protocol service conversion: the FIX protocol business data is converted into FIX protocol request packets of all transaction system specifications by inquiring database conversion rules through protocol conversion service; and converts based on the same rules as the respective system response packets and then returns to the client a specification-compliant FIX protocol request packet.

However, in the three types of conversion, as the service script conversion and the XML format conversion have the problems that the resolution efficiency of protocol key value pairs is low and the converted data occupy larger space, the text structure serialization is adopted, the process is slow, and the programming is complicated; in addition, for protocol service conversion, not only is the data redundancy condition of the FIX itself not optimized, but also a performance bottleneck can exist when a large number of requests are concurrently queried in the database.

Accordingly, there is a need for a method and system for implementing transactions based on protocol conversion to quickly and easily implement transaction implementations in transaction systems of different protocols.

Fig. 1 is a schematic diagram of an application scenario of a transaction implementation system based on protocol conversion according to some embodiments of the present description.

As shown in fig. 1, an application scenario (abbreviated as scenario 100) of the transaction implementation system based on protocol conversion may include a transaction counter 110, a server 120, a terminal device 130, a storage device 140, and a network 150. In some embodiments, the processing device may be part of the server 120.

The transaction counter 110 may be an order system that connects exchanges. The user's terminal 130 cannot directly connect to the trading system according to regulatory requirements, and must go through the trading desk 110 of the securities corporation in the middle. The transaction counter 110 may be in communication with a transaction system for sending a transaction request (e.g., a first transaction request, a second transaction request, etc.) to the transaction system and obtaining a transaction result fed back by the transaction system. In some embodiments, the transaction counter 110 may include a centralized transaction counter, a rapid transaction counter, an institutional transaction counter, or the like. In some embodiments, the transaction counter 110 may obtain the transaction request sent by the terminal device 130 over the network 150. In some embodiments, the transaction counter 110 may send the transaction results fed back by the transaction system to the user's terminal device 130 via the network 150 to implement the entire transaction process.

The server 120 may be used to process information and/or data, for example, the server 120 may be used to process a first transaction request. In some embodiments, the server 120 may receive a first transaction request from a client based on a first protocol; converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service; the protocol conversion service comprises a protocol mapping code, a protocol mapping table and a tag data dictionary; transmitting the second transaction request to a transaction system so that the transaction system generates a transaction result according to the second transaction request; converting the transaction result into a response message based on a first protocol through the protocol conversion service; and sending the response message to the client. In some embodiments, server 120 may process data, information, and/or processing results obtained from other devices or system components and execute program instructions based on such data, information, and/or processing results to perform one or more functions described herein. For example, the server 120 may receive a transaction request (e.g., a first transaction request) sent by a user from the terminal device 130. In some embodiments, server 120 may be a single server or a group of servers. The server group may be centralized or distributed. In some embodiments, server 120 may be local or remote. For example, server 120 may access information and/or data from transaction counter 110, terminal device 130, and/or storage device 140 via network 150. In some embodiments, server 120 may be implemented on a cloud platform.

The terminal device 130 may be various clients used by a user. For example, the terminal device 130 may include a mobile device 130-1, a tablet computer 130-2, a notebook computer 130-3, or the like, or any combination thereof. In some embodiments, terminal device 130 may interact with other components through network 150. For example, terminal device 130 may send a transaction request to server 120 over network 150. For another example, the terminal device 130 may also receive the transaction result sent by the transaction counter and fed back by the transaction system, and display the transaction result to the user.

Storage device 140 may store data, instructions, and/or any other information. In some embodiments, the storage device 140 may store data obtained from the transaction counter 110, the server 120, and the terminal device 130. Such as a first transaction request, a reply message, etc. In some embodiments, the storage device 140 may store data and/or instructions used by the server 120 to perform or use the exemplary methods described in this specification. In some embodiments, the storage device 140 may include one or a combination of a mass memory, a removable memory, a volatile read-write memory, a read-only memory (ROM), and the like.

Network 150 may include any suitable network capable of facilitating the exchange of information and/or data. In some embodiments, at least one component of the scenario 100 (e.g., the transaction counter 110, the server 120, the terminal device 130, the storage device 140) may exchange information and/or data with at least one other component in the scenario 100 over the network 150. For example, the server 120 may obtain a scanned image of the target object from the transaction counter 1110 over the network 150.

It should be noted that scenario 100 is provided for illustrative purposes only and is not intended to limit the scope of the present description. Many modifications and variations will be apparent to those of ordinary skill in the art in light of the present description. For example, the scenario 100 may also include a database. As another example, the scene 100 may implement similar or different functionality on other devices. However, such changes and modifications do not depart from the scope of the present specification.

Fig. 2 is an exemplary timing diagram of a protocol conversion based transaction implementation method according to some embodiments of the present description. As shown in fig. 2, the process 200 may include the following steps. In some embodiments, the process 200 may be performed by a protocol conversion based transaction implementation system or server (e.g., a processing device in a server).

In some embodiments, the server may comprise an RPC master station system. RPC (Remote Procedure Call) the host system refers to a computer or server that provides remote procedure call services. In a distributed system, clients may connect to an RPC host over a network and send requests to invoke remote processes on the host. The RPC host receives the request and performs the corresponding operation, and then returns the result to the client. The RPC master may be implemented using a specific protocol and programming language, e.g., RMI (Remote Method Invocation) in Java, pyro in Python, etc.

Step 202, a first transaction request based on a first protocol is received from a client.

The client may be a program or terminal that provides a service to the user. For example, the client may be the terminal device 130 in fig. 1, or an application program on the terminal device 130, or the like.

The first protocol refers to the communication protocol used by the client (or user) to initiate a transaction request.

In some embodiments, the first protocol is the FIX protocol. In international financial transactions, FIX protocol is the predominant communication protocol. The process of demand of various securities and finance business can be formatted by the FIX protocol to be a plurality of functional processes which can be described by computer language, and the formats are uniformly exchanged on each business function interface, thereby facilitating the connection of each functional module.

In some embodiments, the first protocol may also be other protocols, which the present specification does not limit. Illustratively, for order delegation requests, FIX protocol format definition may be as shown in fig. 3, fig. 3 being an exemplary schematic diagram of FIX protocol format shown in accordance with some embodiments of the present description. Account represents an account number, and the field ID is 1; msgType indicates the request type, field ID is 35; orderNo represents an order number, field ID 37; orderQty represents the number, field ID 38; price represents Price, field ID is 44; securityID represents a security code, and field ID is 48; password represents a Password with field ID 554.

The first transaction request refers to a request related to a transaction issued by a user through a client. It should be noted that the transaction referred to in this specification may include any financial transaction. Such as stock exchanges, futures, options exchanges, international credits, international bonds, gold, foreign exchange exchanges, etc. The first transaction request may include information such as account number, request type, order number, quantity, price, security code, password, currency, transaction time, direction of purchase and sale, etc. In some embodiments, the first transaction request may be based on a first protocol. For example, the first transaction request may be a transaction request in FIX protocol format.

In some embodiments, the client may generate a first transaction request related to the input information based on input from a user (e.g., an investor, a financial transactor, etc.). In some embodiments, the client may send the first transaction request to a server (e.g., server 120) via a network or the like. In some embodiments, the client may obtain the response message sent by the server and present it to the user.

In some embodiments, the server may enable client-server interactions through FIX sessions. FIX session refers to an ordered message bi-directional transport stream with consecutive sequence numbers between a client and a server. One FIX session may include one or more FIX links. Each FIX link represents a session message. Wherein each FIX link of the one or more FIX links corresponds to a different sequence number to distinguish between different session messages. When the client sends the first message request, the server may acquire a FIX session corresponding to the client, and if the client FIX session is already established, processing of subsequent service functions may be performed. In some embodiments, when a client exits, the server may delete the FIX session to which the client corresponds. When the server feeds back the reply message to the client, the server may find a FIX session corresponding to the client and feed back the reply message through the FIX session.

Step 204, converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service.

The second transaction request refers to a transaction request obtained after the first transaction request protocol is converted. In some embodiments, the second transaction request may include transaction information corresponding to a content format of the second agreement, such as account number, request type, order number, quantity, price, security code, password, currency, transaction time, direction of purchase, and the like.

The second protocol refers to a communication protocol used by the transaction system executing the transaction request. For example, the second protocol may include a ProtoBuf protocol, an XML protocol, a JSON protocol, and the like. In some embodiments, the second protocol is a ProtoBuf protocol.

Since FIX protocol analysis is inefficient and redundant data is generated after analysis, it is necessary to perform protocol conversion service on FIX protocol. The ProtoBuf protocol data storage mode is binary, the data size is smaller, the analysis efficiency is faster, the development difficulty is simpler, and the method can be suitable for protocol conversion service.

For example only, the FIX protocol format as shown in fig. 3 may be converted to the ProtoBuf protocol format as shown in the embodiments below for order delegation requests.

Request parameters

message InsertOrderReq

{

string inventor_id=0; account number//

string track_password=1; cipher/cipher

string symbol=2; "security" code

double price=3; price//

int32 quality=4; number//

}

Response parameters

message InsertOrderRsp

{

string inventor_id=0;// account number

int32 quality=1;// quantity

int32 order_no=2;// order number

}

In the request parameter message InsertOrderReq, string inventor_id represents an account number, and the field ID is 0; string track_password represents a password, and the field ID is 1; string symbol represents security code, field ID is 2; double price represents price, field ID is 3; int32 quality represents the number, field ID 4; in the response parameter message InsertOrderRsp, string inventor_id represents an account number, and the field ID is 0; int32 quality represents the number, field ID is 1; int32 order_no denotes an order number, and the field ID is 2.

The protocol conversion service is a program/function for realizing the communication protocol conversion. In some embodiments, the protocol conversion service includes a protocol mapping code, a protocol mapping table, and a tag data dictionary.

The protocol mapping code is used to provide an implementation of the protocol conversion function. In some embodiments, the protocol mapping code may beFiles in format. />The file in the format can be conveniently checked and modified by a programmer, and the programmer can modify the file through software such as Linux/Unix. The protocol mapping code may also be a file in other formats, which is not limited in this specification.

The protocol mapping table is used for realizing the conversion of the first protocol and the second protocol. The protocol mapping table may provide a supervision service that may provide a translation relationship between a field ID of a first protocol and a field name of a second protocol. For example, when the first protocol is FIX protocol and the second protocol is ProtoBuf protocol, the protocol mapping table may be as shown in the following embodiments.

Request method mapping

local RequestMap = {

['D'] = "insert_order",

['F'] = "cancel_order",

}

-field mapping

local FieldMap = {

[1] = "investor_id",

[37] = "order_no",

[38] = "quantity",

[44] = "price",

[48] = "symbol",

[554] = "trade_password",

}

Wherein, in the request method mapping local RequestMap, D represents insert_order; f represents cancel_order; in the field map local FieldMap, 1 represents an inventor_id; 37 indicates order_no;38 represents quality; 44 represents a price;48 represents symbol;554 represents track_password.

The tag data dictionary is used for realizing parameter mapping searching between the first protocol and the second protocol. The bidirectional assignment of each parameter in the first protocol and the second protocol can be realized through the tag data dictionary. Only one parameter of the first protocol or the second protocol can be known through the tag data dictionary, and the parameter of the other corresponding protocol can be known. In some embodiments, when a new protocol (e.g., a third protocol) is added, the proto file is only modified, so that the introduction of the new protocol can be completed, and the mutual conversion among the first protocol, the second protocol and the third protocol can be realized. The tag data dictionary has high processing efficiency and strong plasticity, and can be used for conversion of various protocols.

In some embodiments, the server may implement a parameter map lookup between the first protocol and the second protocol using multiple languages. For example, a Lua language is used to implement a parameter mapping lookup between the first protocol and the second protocol. The Lua language is a light-weight script language and has the characteristics of high efficiency, portability, embeddability and expandability. Since the protocol mapping table content varies from one trade order to another, a highly scalable scripting language is required. Through tests, as for the change part of the protocol mapping table, the Lua language is adopted as the scripting language, so that the stability and the expandability of the program can be improved, and the running of the C++ main program can not be influenced.

It should be noted that, other languages may be used to implement the parameter mapping search between the first protocol and the second protocol. For example, the external configuration file may be loaded via JSON, XML, or the like.

In some embodiments, the protocol mapping code, protocol mapping table, and tag data dictionary in the protocol conversion service may be obtained by a code generation tool. For example, the code generation tool may obtain the protocol mapping code, the protocol mapping table and the tag data dictionary by processing the protocol mapping file based on a preset code generation rule. The code generation tool may be a machine learning tool, or other existing code generation model, and the present specification is not limited thereto.

Illustratively, the processing device may generate the protocol mapping code, the protocol mapping table, and the tag data dictionary in a manner described in the embodiments below.

In some embodiments, the server may determine a protocol mapping file based on the first protocol and the second protocol; and generating the protocol mapping code, the protocol mapping table and the tag data dictionary by using the protocol mapping file through a code generation tool.

The protocol mapping file may be protocol contents defined in advance based on the first protocol and the second protocol to be converted. For the first protocol and the second protocol, the protocol mapping file may reflect a relationship between fields of the first protocol and attributes of the second protocol. For example, each particular protocol mapping file may indicate a PB class corresponding to one of the final C++ when the corresponding C++ code is generated in the proto file.

In some embodiments, the server may generate the protocol mapping code, the protocol mapping table, and the tag data dictionary using preset rules through a code generation tool based on a mapping relationship of fields between two protocols in the protocol mapping file. Illustratively, one example of a protocol mapping code is illustrated in the following embodiments.

The input parameter reader is encapsulated Fix protocol data of the/request processing function

function request(FixReader reader)

{

Obtaining request type from Fix data, i.e. MsgType of Fix protocol

var msg_type = reader.to_string(fix::tag::MsgType);

And/finding the rpc request name corresponding to the MsgType from the mapping table. request_map is a map object parsed from the protocol map file

var rpc_request = request_map[msg_type];

Call request (assuming here a delegated transaction request)

call_rpc<insert_order>(reader);

}

Entrusting/delegating transaction request, and entering participant as encapsulated Fix protocol data

function call_rpc<insert_order>(FixReader reader)

{

The data needed by the request for the delegated transaction is read from the Fix data in turn by// parsing the Fix data: account number, password, commission number, price, code

var investor_id = reader.to_string(fix::tag::Account);

var quantity = reader.to_int(fix::tag::OrderQty);

var price = reader.to_double(fix::tag::Price);

var symbol = reader.to_string(fix::tag::SecurityID);

var password = reader.to_string(fix::tag::Password);

Protobuf Message object for// creation delegated transaction request

InsertOrderReq req;

Setting parameters required for entrusting transaction requests in sequence: account number, password, commission number, price, code

req.set_investor_id(investor_id);

req.set_qurantity(quantity);

req.set_price(price);

req.set_symbol(symbol);

req.set_password(password);

External RPC service is/is called, and RPC method name and protobuf object are imported

call_rpc_service(insert_order, req);

}

It should be noted that the protocol conversion code illustrated above is for exemplary purposes only, and various languages, such as c++, etc., may be used in practical applications, which are not limited in this specification.

In some embodiments, the server may adjust the protocol mapping file and generate the protocol mapping file, protocol mapping table, and tag data dictionary using the adjusted protocol mapping file via a code generation tool. For example, the server may add or subtract fields in the protocol mapping file according to the specific requirements of each transaction request, obtain an adjusted protocol mapping file, and generate the protocol mapping file, the protocol mapping table, and the tag data dictionary according to the adjusted protocol mapping file. The adjustment of the protocol conversion service can be simply and rapidly realized by adjusting the protocol mapping file, so that the method is suitable for conversion among different protocols and the efficiency is improved.

In some embodiments, the server may perform protocol conversion on the first transaction request to obtain the second transaction request based on the first transaction request and the protocol mapping code, the protocol mapping table, and the tag data dictionary through the protocol conversion service. For example, the specific function defined by the method in the ProtoBuf protocol can be obtained by looking up a table through a FIX mapping table based on the message type MsgType in the FIX protocol through the protocol conversion service; matching and searching a label and a label data dictionary in the first transaction request to obtain a corresponding parameter value; the server may copy the parameter value to a field corresponding to the message in the ProtoBuf protocol, to obtain the second transaction request.

Step 206, sending the second transaction request to a transaction system, so that the transaction system generates a transaction result according to the second transaction request.

The transaction system refers to an execution platform of a transaction corresponding to the transaction request. In some embodiments, the transaction system may include a plurality of transaction counters, and the transaction counter may send a transaction request (e.g., a second transaction request) to the exchange system, and receive the delegated return and the bargain returned by the exchange system as a result of the transaction to the server. In some embodiments, the transaction counter and the exchange system may be one piece for different financial environments.

The transaction result refers to the execution result of the transaction corresponding to the transaction request. For example, the transaction results may include information on account numbers, request types, order numbers, amounts, prices, security codes, success/failure of transactions, profitability, etc. involved in the transaction. In some embodiments, the transaction result is information based on a second protocol. For example, the transaction result may be information in the ProtoBuf protocol format.

In some embodiments, the transaction results may be generated based on a preset correspondence. For example, the transaction system may process the second transaction request (e.g., extract key fields, calculate financial transactions based on market prices, etc.) to obtain a transaction result.

Step 208, converting the transaction result into a response message based on the first protocol through the protocol conversion service.

The response message may be the final and feedback transaction outcome information to the user. For example, the response message may be specific text, such as information on account numbers, request types, order numbers, amounts, prices, security codes, success/failure of transactions, profitability, etc. involved in transactions. In some embodiments, the reply message may be information in a first protocol format. For example, the reply message may be information in FIX protocol format.

In some embodiments, the server may convert the transaction result into the reply message based on the transaction result and the protocol mapping code, protocol mapping table, and tag data dictionary in a manner similar to converting the first transaction request into the second transaction request. For example, the server may reversely search through the tag data dictionary based on each parameter value in the ProtoBuf protocol to obtain a tag corresponding to the response message in the FIX protocol; the server may look up a table based on the tag through FIX mapping table to obtain a corresponding response message. In some embodiments, the process of converting the transaction result into a reply message in this embodiment may be similar to the reverse of the process of converting the first transaction request into the second transaction request.

And step 210, sending the response message to the client.

In some embodiments, the server (processing device) may send the reply message to the client over the network.

In some embodiments of the present disclosure, protocol conversion is performed on a first transaction request sent by a client through a protocol conversion service, and the method may implement mapping conversion on a FIX protocol through a high-performance ProtoBuf protocol, thereby improving data analysis efficiency and transaction efficiency of financial transactions; in addition, by generating the mapping files of the two protocols, the mapping files can be reused, so that the cost of protocol conversion is saved.

It should be noted that the above description of the flow steps in the timing diagrams is merely for illustration and description, and does not limit the application scope of the present specification. Various modifications and changes to the process steps will be apparent to those skilled in the art in light of the present description. However, such modifications and variations are still within the scope of the present description. For example, a storage step is added, etc.

Fig. 4 is an exemplary block diagram of a protocol conversion based transaction implementation system according to some embodiments of the present description.

In some embodiments, the system 400 may include a client 410, an RPC master station system 420, and a transaction system 430.

The client 410 may be configured to generate a first transaction request based on a first protocol based on user input and send the first transaction request to the RPC master station system 420.

The RPC master station system 420 may be configured to receive a first transaction request from a client based on a first protocol; converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service; the protocol conversion service comprises a protocol mapping code, a protocol mapping table and a tag data dictionary; and sending the second transaction request to a transaction system so that the transaction system generates a transaction result according to the second transaction request.

Transaction system 430 may be configured to receive the second transaction request and generate a transaction result based on the second transaction request and transmit the transaction result to RPC master station system 420.

The RPC master station system 420 is further configured to convert the transaction result into a response message based on the first protocol through the protocol conversion service; the reply message is sent to the client 410.

Still further embodiments of the present disclosure disclose a transaction implementation device based on protocol conversion, including a processor, where the processor is configured to perform the transaction implementation method based on protocol conversion.

In order to facilitate understanding of the technical solutions disclosed in the present specification, taking the first protocol as FIX protocol and the second protocol as ProtoBuf protocol as examples, a specific and complete embodiment of a transaction implementation method based on protocol conversion is illustrated. As shown in fig. 5, fig. 5 is an exemplary schematic diagram of a protocol conversion based transaction flow shown in accordance with some embodiments of the present description. The system mainly comprises a client, an RPC master station system and a counter system. The client and counter system is not described too much, and for the conversion service in the RPC master station system, it may include a FIX session management module, a protocol conversion service module.

(1) The FIX session management module is used for realizing connection and management of user session, judging according to the user state when a user function request is sent to the module, and processing service functions if the user session is established; the service may delete the session information for the user when the user exits. In the request transmission process, a request sent by a client is sent to a FIX session management service, and a corresponding session is searched and sent to a corresponding RPC transaction service through a protocol conversion service; and returning the corresponding client according to the used session when the RPC transaction service response data returns to the FIX session management service.

(2) The method comprises the steps that a FIX protocol mapping file is used for defining message protocol content of a ProtoBuf of an RPC master station system aiming at a specific service scene, wherein the content covers a client function list to ensure that a client FIX request can correspond to a proto file realization function; and after the service proto file is defined, generating a corresponding message cc file through a code generation tool, and simultaneously generating a corresponding MsgType mapping table of the FIX and a data dictionary of the Tag. The MsgType mapping table is used for distributing related functional requests to different RPC transaction services in the RPC access service, and finally, request service routing is realized. The main function of the Tag data dictionary is to realize mapping and searching of two communication protocol request parameters and realize assignment among parameters. The method has higher lightweight processing efficiency, and can be realized by modifying the proto file if the protocol is newly added.

It should be noted that, the FIX protocol mapping file may be generated and stored in advance, and is called by the protocol conversion service when applied.

(3) When the conversion service finds a corresponding method, the conversion service performs matching search on the FIX protocol Tag in the request data and a data dictionary corresponding to the ProtoBuf, and finally copies a request parameter value corresponding to the FIX protocol Tag in the request data to a field corresponding to a message in the ProtoBuf. The data packet of the FIX protocol is converted into the data packet in the ProtoBuf format used by the RPC master station system, and the data packet is sent to the RPC access service to realize the call of the service and is sent to the internal RPC transaction system service (comprising common transaction systems, two-fusion transaction systems, fund transaction systems and the like).

While the basic concepts have been described above, it will be apparent to those skilled in the art that the foregoing detailed disclosure is by way of example only and is not intended to be limiting. Although not explicitly described herein, various modifications, improvements, and adaptations to the present disclosure may occur to one skilled in the art. Such modifications, improvements, and modifications are intended to be suggested within this specification, and therefore, such modifications, improvements, and modifications are intended to be included within the spirit and scope of the exemplary embodiments of the present invention.

Meanwhile, the specification uses specific words to describe the embodiments of the specification. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic is associated with at least one embodiment of the present description. Thus, it should be emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various positions in this specification are not necessarily referring to the same embodiment. Furthermore, certain features, structures, or characteristics of one or more embodiments of the present description may be combined as suitable.

Furthermore, the order in which the elements and sequences are processed, the use of numerical letters, or other designations in the description are not intended to limit the order in which the processes and methods of the description are performed unless explicitly recited in the claims. While certain presently useful inventive embodiments have been discussed in the foregoing disclosure, by way of various examples, it is to be understood that such details are merely illustrative and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements included within the spirit and scope of the embodiments of the present disclosure. For example, while the system components described above may be implemented by hardware devices, they may also be implemented solely by software solutions, such as installing the described system on an existing server or mobile device.

Likewise, it should be noted that in order to simplify the presentation disclosed in this specification and thereby aid in understanding one or more inventive embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof. This method of disclosure, however, is not intended to imply that more features than are presented in the claims are required for the present description. Indeed, less than all of the features of a single embodiment disclosed above.

In some embodiments, numbers describing the components, number of attributes are used, it being understood that such numbers being used in the description of embodiments are modified in some examples by the modifier "about," approximately, "or" substantially. Unless otherwise indicated, "about," "approximately," or "substantially" indicate that the number allows for a 20% variation. Accordingly, in some embodiments, numerical parameters set forth in the specification and claims are approximations that may vary depending upon the desired properties sought to be obtained by the individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and employ a method for preserving the general number of digits. Although the numerical ranges and parameters set forth herein are approximations that may be employed in some embodiments to confirm the breadth of the range, in particular embodiments, the setting of such numerical values is as precise as possible.

Each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., referred to in this specification is incorporated herein by reference in its entirety. Except for application history documents that are inconsistent or conflicting with the content of this specification, documents that are currently or later attached to this specification in which the broadest scope of the claims to this specification is limited are also. It is noted that, if the description, definition, and/or use of a term in an attached material in this specification does not conform to or conflict with what is described in this specification, the description, definition, and/or use of the term in this specification controls.

Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments of this specification. Other variations are possible within the scope of this description. Thus, by way of example, and not limitation, alternative configurations of embodiments of the present specification may be considered as consistent with the teachings of the present specification. Accordingly, the embodiments of the present specification are not limited to only the embodiments explicitly described and depicted in the present specification.

Claims

1. A method of implementing a transaction based on protocol conversion, the method being performed by a server, the method comprising:

receiving a first transaction request from a client based on a first protocol;

converting the first transaction request into a second transaction request based on a second protocol through a protocol conversion service; the protocol conversion service comprises a protocol mapping code, a protocol mapping table and a tag data dictionary;

transmitting the second transaction request to a transaction system so that the transaction system generates a transaction result according to the second transaction request;

converting the transaction result into a response message based on a first protocol through the protocol conversion service;

and sending the response message to the client.

2. The method of claim 1, the method further comprising:

determining a protocol mapping file based on the first protocol and the second protocol;

and generating the protocol mapping codes, the protocol mapping table and the tag data dictionary by using the protocol mapping file through a code generation tool.

3. The method of claim 2, the method further comprising:

and adjusting the protocol mapping file, and generating the protocol mapping file, the protocol mapping table and the tag data dictionary by using the adjusted protocol mapping file through a code generation tool.

4. The method of claim 2, wherein,

the protocol mapping code is used for realizing a protocol conversion function;

the protocol mapping table is used for realizing the conversion of the first protocol and the second protocol;

the tag data dictionary is used for realizing parameter mapping searching between the first protocol and the second protocol.

5. The method of claim 4, using lua language to implement a parameter map lookup between the first protocol and the second protocol.

6. The method of claim 1, the first protocol being FIX protocol and the second protocol being ProtoBuf protocol.

7. The method of claim 1, the server comprising an RPC master station system.

8. A transaction implementation system based on protocol conversion, the system comprising an RPC master station system for performing the following operations:

receiving a first transaction request from a client based on a first protocol;

and sending the response message to the client.

9. The system of claim 8, the first protocol being FIX protocol and the second protocol being ProtoBuf protocol.

10. A transaction enabling device based on protocol conversion, comprising a processor for performing the method of any of claims 1-7.