An implementation method of a futures trading gateway

Abstract

The application belongs to the technical field of open gateway, and particularly relates to a futures transaction gateway implementation method, comprising the following steps: S1, taking a computer server as a hardware carrier, deploying a bottom-layer SDK and a CTP SDK suitable for adapting to multiple types of futures counters in the server, and building a basic communication link with a front-end machine of a futures company; S2, when a terminal client initiates a transaction request, a Boost library is called to create an independent sub-process by a C++-developed transaction gateway, and a dedicated process instance is allocated to the client. Through the design of the C++-developed transaction gateway combined with the allocation of the independent sub-process to the client, the performance bottleneck caused by the increase of the number of users in the single process is avoided, and more user concurrent transactions can be supported without additional servers.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of open gateway, and particularly relates to a futures transaction gateway implementation method. BACKGROUND

[0002] The domestic futures transaction gateway technology takes the CTP (comprehensive transaction platform) gateway as a typical representative. The related scheme coincides with the application in the functional target, but there are obvious deficiencies in the technical architecture and performance:

[0003] Performance bottleneck problem caused by single-process architecture: in the prior art, Java language is used to call CTP SDK to realize futures transaction function, which is completely consistent with the technical field of the application, but is limited by the single-process architecture design, and needs to load the dynamic library generated by SWIG (Simplified Wrapper and Interface Generator) through JNI (Java Native Interface) to access the futures company counter. Since there are fixed limitations on the resource access of the single-process service of the CTP underlying dynamic library, when the number of access users reaches a certain scale (such as about 1000 users in the prior art), the system will have obvious performance bottleneck, which is manifested as an increase in transaction response delay, saturation of resource utilization, and the problem can only be alleviated by additionally increasing the number of servers, resulting in a significant increase in hardware cost and operation and maintenance complexity.

[0004] Unsolved scalability defects of connection number limitation: although the WebSocket communication module is introduced in the prior art, it has certain distributed processing capability, but it does not break through the core connection number limitation problem. In the multi-user concurrent scenario, the gateway lacks effective isolation mechanism for connection management of different users, and single-user connection is easy to affect the overall gateway stability, and cannot dynamically allocate connection load according to hardware performance, resulting in limited system expansion capability.

[0005] The gateway technology in the foreign securities and futures field has reference value in some mechanisms, but due to differences in application scenarios or limitations of technical paths, it cannot directly solve the core problems of the domestic futures transaction gateway:

[0006] Load balancing scheme with insufficient scene adaptability: in the prior art, the order processing logic design for securities transactions does not consider the differences in the special communication protocols and interfaces of domestic futures transaction counters (such as CTP, Feima, etc.), and its load balancing mechanism cannot directly adapt to the integration needs of domestic multiple types of futures counters, and needs to be greatly modified to migrate to the futures transaction scenario.

[0007] Protocol incompatible technical path limitation: the existing technology reconstructs the existing gateway architecture by using C++ language, but the scheme only converts the FIX / FAST protocol, cannot be compatible with the CTP protocol, Feima protocol and other special protocols commonly used in the domestic futures trading field, and does not involve the unified packaging of multiple trading posts and the support of multiple language access, which cannot meet the core needs of the domestic futures trading system for the integration of multiple trading posts.

[0008] According to the existing technical solutions at home and abroad, the current futures trading gateway generally has the following common problems to be solved:

[0009] High complexity of multi-trading post access adaptation: the underlying SDK interfaces of different futures trading posts (CTP, Feima, and Goldstar) differ greatly, and the existing gateway needs to develop an adaptation module for each trading post. If the terminal client needs to switch the accessed futures trading post, the interface calling code needs to be modified, and the development and maintenance cost is high.

[0010] Poor multi-language compatibility: most existing solutions rely on cross-language calling technologies such as JNI, and only support a few programming languages such as Java for access, which is insufficient for supporting mainstream development languages such as PHP, Python, and Go, limiting the technology selection of terminal clients.

[0011] Weak fault isolation capability: most solutions use single-process or lightweight thread pool architecture, and the process exception (such as Crash, underlying dynamic library crash) of a single user will spread to the entire gateway system, affecting multiple user transactions, and the system availability is low.

[0012] Insufficient load and expansion capability: the existing load balancing solutions (such as round-robin load balancing and IP source return) do not dynamically distribute loads based on hardware performance, the hardware resource utilization rate is low, and the maximum supported number of users is difficult to break through, which cannot meet the high-concurrency transaction demand.

[0013] Therefore, there is an urgent need for a futures trading gateway implementation method that can integrate multiple types of futures trading posts, support multi-language access, and have efficient load balancing and fault isolation capabilities to solve the above-mentioned deficiencies of existing technologies. SUMMARY

[0014] The purpose of the present application is to provide a method for implementing a futures trading gateway to solve the above-mentioned technical problems.

[0015] Therefore, the present application provides a method for implementing a futures trading gateway, comprising the following steps:

[0016] S1, taking a computer server as a hardware carrier, deploying an underlying SDK and a CTP SDK for adapting multiple types of futures trading posts in the server, and building a basic communication link with a front-end machine of a futures company;

[0017] S2, when the terminal client initiates a transaction request, a Boost library is called by a transaction gateway developed based on C++ to create an independent child process, and a dedicated process instance is allocated for the client;

[0018] S3, the client establishes a TCP long connection with the transaction gateway through a WebSocket protocol, and sends encapsulated transaction request data; after the transaction gateway receives and analyzes the data, the data is transmitted to an underlying SDK or a CTP SDK; wherein the WebSocket protocol complies with the IETF RFC 6455 standard;

[0019] S4, the transaction gateway adapts the parsed request data through a preset uniform interface API data structure, shields the SDK calling differences of different futures counters, and then forwards the data to a corresponding futures company front-end machine;

[0020] S5, the futures company front-end machine generates response data after processing the request, and feeds back the data to the transaction gateway through the underlying SDK or the CTP SDK; the transaction gateway encapsulates the response data into a WebSocket format, and returns the data to the client through the TCP long connection.

[0021] Further, in step S2, the independent child process is created based on an operating system level process isolation mechanism; when any child process exits abnormally, only the client transaction link corresponding to the child process is interrupted, and the running of the main process of the transaction gateway and the dedicated child processes of other clients is not affected.

[0022] Further, in step S3, the terminal client is a client developed in Java, PHP, Python, C++, or Go language; the client completes request data encapsulation through a WebSocket library of its own programming language, without relying on a Java native interface.

[0023] Further, between steps S1 and S2, there is also a load balancing scheduling step, specifically:

[0024] A plurality of servers form a transaction gateway cluster, and each server records its own active connection number P and a preset performance weight Weight in real time;

[0025] The servers in the cluster synchronize their P values and Weight values to other servers in real time through TCP communication; wherein Weight>0, and the default value is 1;

[0026] When a new transaction request arrives, each server calculates its own weighted connection number through the formula "weighted connection number=P / Weight";

[0027] The transaction gateway assigns the new request to the server with the smallest number of weighted connections, and if there are multiple servers with the same number of weighted connections, a server is randomly selected, and the server executes step S2 to create a dedicated sub-process.

[0028] Further, in step S3, before the transaction gateway receives the request data, an identity authentication step is further included:

[0029] The client signs its own identity information based on the RSA public key to generate identity authentication data;

[0030] The client sends the identity authentication data to the transaction gateway together with the transaction request data;

[0031] The transaction gateway verifies the identity authentication data through a preset RSA private key, and after verification, it performs data analysis; if the verification fails, the request is rejected, and an authentication failure response is returned.

[0032] Further, in the request transmission of step S3 and the response return process of step S5, a data encryption step is further included:

[0033] The transaction gateway and the client pre-negotiate to determine an AES symmetric encryption key;

[0034] Before the client sends the request data, the data is encrypted using the key;

[0035] After the transaction gateway receives it, it is decrypted using the same key;

[0036] Before the transaction gateway returns the response data, the data is encrypted using the key;

[0037] After the client receives it, it is decrypted using the same key.

[0038] Further, in the response return step of step S5, before the transaction gateway encapsulates the response data, a data compression step is further included:

[0039] The transaction gateway uses the gzip compression algorithm to compress the response data;

[0040] After the client receives the compressed response data, it is restored to the original response data through the gzip decompression algorithm, and then subsequent business processing is performed.

[0041] Further, in step S4, before forwarding to the corresponding futures company front-end machine, the private network channel between the transaction gateway and the futures company front-end machine is implemented, which includes a dedicated line or an intranet channel, and is used to replace public network transmission to reduce data transmission delay.

[0042] Further, in the step S1, the transaction gateway realizes seamless switching between different futures counters by unified packaging of corresponding underlying SDKs, without the need for the client to modify interface calling codes.

[0043] Further, in the step S2, the transaction gateway records the process identifier PID of the created exclusive sub-process; and in the subsequent transaction data interaction process, the transaction gateway establishes an association with the sub-process, the underlying SDK or the CTP SDK through the PID, to ensure accurate data transmission.

[0044] The application has the following beneficial effects:

[0045] The application avoids performance bottlenecks caused by an increase in the number of users in a single process by assigning an independent sub-process to the client based on C++ development of the transaction gateway, and supports more concurrent transactions of users without additional servers.

[0046] The application deploys underlying SDKs and CTP SDKs adapted to multiple types of futures counters, and combines a preset unified interface API data structure to shield differences in SDK calling of different futures counters, solve the problem of separate adaptation of traditional multiple counters, and reduce the complexity of multiple counter access.

[0047] The application establishes a TCP long connection based on the WebSocket protocol conforming to the IETF RFC 6455 standard, replaces traditional JNI calling, realizes bidirectional real-time communication between multiple language clients such as Java, PHP, Python, C++, Go and the transaction gateway, and simplifies cross-language interaction processes.

[0048] The application ensures smoothness of a complete link from initiation of a transaction request from a client to processing of the transaction request by a front-end machine of a futures company and feedback of a response by the front-end machine, and improves the stability of a transaction process through a whole-process design of request receiving, analysis and adaptation, front-end machine forwarding and response feedback. BRIEF DESCRIPTION OF DRAWINGS

[0049] Figure 1 is a flowchart of an implementation method of a futures transaction gateway. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the application will be clearly described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art belong to the scope of protection of the application.

[0051] In the description of the present application, it should be noted that the terms used herein are only intended to describe specific embodiments and are not intended to limit the exemplary embodiments according to the present application. For ease of description, the sizes of the various parts shown in the drawings are not drawn in proportion to the actual proportions. The techniques, methods and devices known to those skilled in the relevant art can not be discussed in detail, but should be considered as part of the authorized description, if appropriate. In all examples shown and discussed herein, any specific value should be interpreted as merely exemplary and not as a limitation. Therefore, other examples of exemplary embodiments can have different values. It should be noted that similar reference numerals and letters represent similar items in the following drawings, and therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

[0052] It should be noted that in the present application, the term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed or inherent to such a process, method, article or device. Without more limitations, the element defined by the statement "comprises a" does not exclude the presence of additional identical elements in the process, method, article or device comprising the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, but can also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method can be performed in an order different from that described, and various steps can also be added, omitted or combined. In addition, the features described with reference to certain examples can be combined in other examples.

[0053] Referring to Figure 1 An implementation method of a futures trading gateway, comprising the following steps:

[0054] S1, taking a computer server as a hardware carrier, deploying a bottom-layer SDK and a CTP SDK suitable for adapting multiple types of futures counters in the server, and building a basic communication link with a front-end machine of a futures company;

[0055] S2, when a terminal client initiates a trading request, a Boost library is called to create an independent sub-process by a C++-developed trading gateway, and a dedicated process instance is allocated for the client;

[0056] S3, the client establishes a TCP long connection with the transaction gateway through a WebSocket protocol, and sends encapsulated transaction request data; the transaction gateway receives and analyzes the data, and then transmits the data to an underlying SDK or a CTP SDK; wherein the WebSocket protocol conforms to the IETF RFC 6455 standard;

[0057] S4, the transaction gateway performs adaptation on the parsed request data through a preset unified interface API data structure, shields the SDK calling differences of different futures trading desks, and then forwards the data to a corresponding futures company front-end machine.

[0058] S5, the futures company front-end machine generates response data after processing the request, and feeds back the data to the transaction gateway through the underlying SDK or the CTP SDK; the transaction gateway encapsulates the response data into a WebSocket format, and returns the data to the client through the TCP long connection.

[0059] The application assigns independent sub-processes to the client based on the development of the transaction gateway in C++, avoids the performance bottleneck caused by the increase in the number of users in a single process, and supports more user concurrent transactions without additional servers.

[0060] The application deploys underlying SDKs and CTP SDKs that adapt to multiple types of futures trading desks, and shields the SDK calling differences of different futures trading desks by combining a preset unified interface API data structure, thereby solving the problem of separate adaptation of traditional multiple trading desks and reducing the complexity of multiple trading desk access.

[0061] The application establishes a TCP long connection based on the WebSocket protocol conforming to the IETF RFC 6455 standard, replaces traditional JNI calling, realizes two-way real-time communication between Java, PHP, Python, C++, Go, and other multi-language clients and the transaction gateway, and simplifies the cross-language interaction process.

[0062] The application ensures the smoothness of the complete link from the initiation of the transaction request by the client to the processing and response feedback of the futures company front-end machine through the whole process design of request receiving, analysis and adaptation, front-end machine forwarding, and response returning, thereby improving the stability of the transaction process.

[0063] In the example of the application, in the step S2, the independent sub-processes are created based on the operating system level process isolation mechanism; when any sub-process exits abnormally, only the transaction link of the client corresponding to the sub-process is interrupted, without affecting the running of the main process of the transaction gateway and the exclusive sub-processes of other clients.

[0064] As a preferred example of the present application, the application creates an independent sub-process based on an operating system level process isolation mechanism. When any client-specific sub-process exits due to an exception (such as process crash, underlying SDK failure), only the transaction link of the client is interrupted, and the running of the transaction gateway main process and other client-specific sub-processes is not affected, thereby avoiding the risk of overall system paralysis caused by single user failure. In addition, the influence range of a single failure point on the system can be reduced, the transactions of most clients can be protected from the influence of individual exceptions, the continuous and stable operation of the futures trading system can be maintained, and the probability of system downtime or service interruption can be reduced.

[0065] In the example of the present application, in the step S3, the terminal client is developed in Java, PHP, Python, C++, or Go language; and the client completes request data encapsulation through the WebSocket library of its own programming language without relying on Java native interface.

[0066] As a preferred example of the present application, the application supports clients developed in Java, PHP, Python, C++, and Go language, covers mainstream development languages, meets the access needs of users with different technology stacks, and expands the applicable scenarios of the transaction gateway.

[0067] The client can complete request data encapsulation through the WebSocket library of its own programming language without relying on Java native interface (JNI) for cross-language calling development, thereby avoiding the complex adaptation work of JNI development.

[0068] In the example of the present application, the steps S1 and S2 further include a load balancing scheduling step, specifically:

[0069] A plurality of servers form a transaction gateway cluster, and each server records its own active connection number P and preset performance weight Weight in real time.

[0070] The servers in the cluster communicate through TCP to synchronize their P values and Weight values to other servers in real time; wherein Weight>0, and the default value is 1.

[0071] When a new transaction request arrives, each server calculates its own weighted connection number through the formula "weighted connection number=P / Weight".

[0072] The transaction gateway distributes the new request to the server with the smallest weighted connection number, and if there are multiple servers with the same weighted connection number, a server is randomly selected, and the server executes the step S2 to create a specific sub-process.

[0073] As a preferred example of the present application, the application distributes new transaction requests to the server with the minimum weighted connection number through the load balancing algorithm of "weighted connection number = active connection number (P) / performance weight (Weight)", avoiding the situation of overloading of some servers and idling of some servers;

[0074] Based on the transaction gateway cluster composed of multiple servers and the load balancing scheduling, the user number limit of a single server can be broken through;

[0075] Through real-time synchronization of the active connection number (P) and the performance weight (Weight) of each server through TCP communication, it is ensured that the load calculation is based on the latest cluster state, the scheduling deviation caused by information lag is avoided, and the overall load balancing of the cluster is maintained.

[0076] In the example of the present application, before the transaction gateway receives the request data in step S3, an identity authentication step is further included:

[0077] The client signs its own identity information based on the RSA public key to generate identity authentication data;

[0078] The client sends the identity authentication data to the transaction gateway together with the transaction request data;

[0079] The transaction gateway verifies the identity authentication data through a preset RSA private key, and performs data analysis after verification; if the verification fails, the request is rejected, and an authentication failure response is returned.

[0080] As a preferred example of the present application, the identity authentication process through RSA public key signature and private key verification ensures that the client initiating the transaction request is a legal authorized user, prevents illegal and unauthorized clients from accessing the transaction gateway, and avoids illegal transaction requests entering the system;

[0081] Identity authentication data is transmitted together with transaction request data, and subsequent data analysis can only be performed after verification by a preset RSA private key, effectively preventing attackers from forging transaction requests (such as imitating legal users to initiate transactions), and ensuring the legality and security of futures trading.

[0082] In the example of the present application, during the request transmission of step S3 and the response return process of step S5, a data encryption step is further included:

[0083] The transaction gateway and the client pre-negotiate and determine an AES symmetric encryption key;

[0084] Before sending the request data, the client encrypts the data using the key;

[0085] After receiving, the transaction gateway decrypts it with the same key;

[0086] Before returning the response data, the transaction gateway encrypts the data using the key;

[0087] The client receives and decrypts with the same key.

[0088] As a preferred example of the present application, the transaction gateway and the client perform bidirectional encryption processing on the request data and the response data based on a pre-negotiated AES symmetric encryption key, preventing the data from being stolen by a third party in the transmission process (such as data interception in public network transmission), and ensuring that the transaction data (such as the order amount, account information) is not leaked;

[0089] If the encrypted data stream is tampered with, valid data cannot be obtained through decryption, indirectly implementing data integrity verification, avoiding tampering with transaction requests (such as modifying the order price and quantity) or response data (such as modifying the market situation and transaction results), and ensuring the authenticity of the transaction data.

[0090] In the example of the present application, the response return step of step S5 further includes a data compression step before the transaction gateway encapsulates the response data:

[0091] The transaction gateway uses the gzip compression algorithm to compress the response data;

[0092] After the client receives the compressed response data, it is restored to the original response data through the gzip decompression algorithm, and then subsequent business processing is performed.

[0093] As a preferred example of the present application, the response data of the transaction gateway is compressed by the gzip compression algorithm, reducing the volume of the response data, reducing the transmission time of the data in the TCP long connection, and improving the speed of the client receiving the response;

[0094] The compressed response data occupies less network bandwidth, especially in the multi-user concurrent transaction scenario, which can reduce the overall network bandwidth consumption, reduce the network resource cost, and avoid transmission congestion caused by insufficient bandwidth.

[0095] In the example of the present application, in step S4, the forwarding to the corresponding futures company front-end machine is realized through a private network channel between the transaction gateway and the futures company front-end machine, which includes a dedicated line or an intranet channel, used to replace public network transmission to reduce data transmission delay.

[0096] As a preferred example of the present application, the data is forwarded through a private network channel such as a dedicated line or an intranet between the transaction gateway and the futures company front-end machine, replacing traditional public network transmission, avoiding the influence of public network fluctuations (such as delay and packet loss), and according to the test data in the disclosure, the transmission delay can be reduced from about 300ms of traditional public network to within 50ms, improving the real-time performance of futures trading;

[0097] The network quality of the private network channel is more stable and the packet loss rate is lower, reducing problems such as transaction request timeout and response loss caused by unstable public networks, and guaranteeing the timely transmission and processing of futures transaction instructions (such as orders and order cancellations).

[0098] In the example of the present application, in step S1, the transaction gateway realizes seamless switching between different futures trading desks through unified encapsulation of corresponding underlying SDKs, without the need for the client to modify interface call codes.

[0099] As a preferred example of the present application, the transaction gateway realizes switching from one futures trading desk to another (such as switching from a CTP trading desk to a Hang Seng trading desk) through unified encapsulation of multiple types of futures trading desk underlying SDKs, without the need for the client to modify any interface call codes, avoiding the cumbersome process of redeveloping adaptive interfaces required by traditional trading desk switching.

[0100] The client does not need to pay attention to the type of underlying access futures trading desk, and does not need to develop exclusive interfaces for different trading desks, reducing the technical adaptation and maintenance costs of the client and improving the compatibility of the client to different futures company trading desks.

[0101] In the example of the present application, in step S2, the transaction gateway records the process identifier (PID) of the exclusive sub-process after creating it; in the subsequent transaction data interaction process, the transaction gateway establishes an association with the sub-process, underlying SDK or CTP SDK through the PID, ensuring accurate data transmission.

[0102] As a preferred example of the present application, the transaction gateway records the process identifier (PID) of the exclusive sub-process and establishes an association with the sub-process, underlying SDK or CTP SDK through the PID, avoiding confusion of transaction data of different clients in the transmission process (such as transmitting request data of client A to the sub-process of client B), and ensuring accurate matching of each transaction data to the corresponding client and SDK.

[0103] By using PID as the unique identifier for data interaction, the transaction gateway can quickly locate the target sub-process and associated SDK, reducing the complexity of data routing, improving the processing efficiency of transaction data, and facilitating subsequent troubleshooting of specific client transaction links (such as tracking the transaction data flow log of a certain client through PID).

[0104] The embodiments of the present application are described above with reference to the drawings, and the embodiments and features in the embodiments of the present application can be combined with each other without conflict, and the present application is not limited to the above-described specific embodiments, and the above-described specific embodiments are only illustrative but not restrictive, and a person of ordinary skill in the art can make many forms under the inspiration of the present application without departing from the purpose of the present application and the scope protected by the claims, and all belong to the protection of the present application.

Claims

1. A method for implementing a futures trading gateway, characterized in that, Includes the following steps: S1 uses a computer server as the hardware carrier, and deploys the underlying SDK and CTP SDK adapted to multiple types of futures counters in the server to build a basic communication link with the front-end machine of the futures company. S2, When the terminal client initiates a transaction request, the transaction gateway developed based on C++ calls the Boost library to create an independent child process and allocates a dedicated process instance to the client; S3, the client establishes a long TCP connection with the transaction gateway via the WebSocket protocol and sends encapsulated transaction request data; after receiving and parsing the data, the transaction gateway passes it to the underlying SDK or CTP SDK; wherein, the WebSocket protocol conforms to the IETF RFC 6455 standard; S4, the trading gateway adapts the parsed request data through a pre-defined unified interface API data structure, shields the differences in SDK calls between different futures counters, and then forwards it to the corresponding futures company's front-end machine; In S5, the futures company's front-end server processes the request and generates response data, which is then fed back to the trading gateway via the underlying SDK or CTP SDK. The trading gateway encapsulates the response data into WebSocket format and sends it back to the client via a TCP long connection.

2. The method for implementing a futures trading gateway according to claim 1, characterized in that, In step S2, the independent subprocess is created based on the operating system-level process isolation mechanism; when any subprocess exits abnormally, only the client transaction link corresponding to that subprocess is interrupted, without affecting the operation of the transaction gateway main process and the dedicated subprocesses of other clients.

3. The method for implementing a futures trading gateway according to claim 1, characterized in that, In step S3, the terminal client is a client developed in Java, PHP, Python, C++, or Go; the client completes the request data encapsulation through its own programming language's WebSocket library, without relying on Java's native interface.

4. The method for implementing a futures trading gateway according to claim 1, characterized in that, The step between steps S1 and S2 also includes a load balancing scheduling step, specifically: Multiple servers form a transaction gateway cluster, and each server records its own active connection count P and preset performance weight Weight in real time; Each server in the cluster synchronizes its own P-value and Weight value to other servers in real time via TCP communication; where Weight > 0, and the default value is 1. When a new transaction request arrives, each server calculates its own weighted connection count using the formula "Weighted Connection Count = P / Weight". The transaction gateway assigns new requests to the server with the smallest weighted connection count. If multiple servers have the same weighted connection count, one server is randomly selected and that server executes step S2 to create a dedicated child process.

5. The method for implementing a futures trading gateway according to claim 1, characterized in that, In step S3, before the transaction gateway receives the request data, an identity authentication step is also included: The client uses an RSA public key to sign its own identity information and generate authentication data. The client sends the authentication data along with the transaction request data to the transaction gateway; The transaction gateway verifies the identity authentication data using a preset RSA private key. If the verification is successful, the data is parsed; if the verification fails, the request is rejected and an authentication failure response is returned.

6. The method for implementing a futures trading gateway according to claim 5, characterized in that, The process of request transmission in step S3 and response return in step S5 also includes a data encryption step: The transaction gateway and the client pre-negotiate and determine the AES symmetric encryption key; Before sending request data, the client encrypts the data using the aforementioned key; After receiving the data, the transaction gateway decrypts it using the same key. Before the transaction gateway sends back response data, it encrypts the data using the aforementioned key; After receiving the data, the client decrypts it using the same key.

7. The method for implementing a futures trading gateway according to claim 1, characterized in that, In the response feedback step of step S5, before the transaction gateway encapsulates the response data, a data compression step is also included: The transaction gateway uses the gzip compression algorithm to compress the response data; After receiving the compressed response data, the client uses the gzip decompression algorithm to restore it to the original response data before performing subsequent business processing.

8. The method for implementing a futures trading gateway according to claim 1, characterized in that, In step S4, forwarding to the corresponding futures company's front-end server is achieved through a private network channel between the trading gateway and the futures company's front-end server. The private network channel includes a dedicated line or an intranet channel, which is used to replace public network transmission to reduce data transmission latency.

9. The method for implementing a futures trading gateway according to claim 1, characterized in that, In step S1, the trading gateway enables seamless switching between different futures trading platforms by uniformly encapsulating the corresponding underlying SDK, allowing the client to do so without modifying the interface call code.

10. The method for implementing a futures trading gateway according to claim 1, characterized in that, In step S2, after the transaction gateway creates a dedicated subprocess, it also records the process identifier (PID) of the subprocess. During subsequent transaction data interaction, the transaction gateway uses the PID to establish an association with the subprocess, the underlying SDK, or the CTP SDK to ensure accurate data transmission.

Images