Realization method of futures transaction gateway

Abstract

The invention belongs to the technical field of open gateways, and particularly relates to an implementation method of a futures transaction gateway, which comprises the following steps of: S1, by taking a computer server as a hardware carrier, deploying a bottom-layer SDK (Software Development Kit) and a CTP (Computer To Plate) SDK adaptive to multiple types of futures counters in the server, and establishing a basic communication link with a front-end processor of a futures company; and S2, when a terminal client initiates a transaction request, calling a Boost library to create an independent sub-process based on a transaction gateway developed by C + +, and distributing an exclusive process instance for the client. According to the application, through the design of developing the transaction gateway based on C + + and distributing the independent sub-process for the client, the performance bottleneck caused by the increase of the number of users under a single process is avoided, and concurrent transaction of more users can be supported without additionally adding a server.

Description

Technical Field

[0001] This invention belongs to the field of open gateway technology, and in particular relates to a method for implementing a futures trading gateway. Background Technology

[0002] Domestic futures trading gateway technology is typically represented by CTP (Comprehensive Trading Platform) gateways. While related solutions overlap with the present invention in terms of functional objectives, they have significant shortcomings in technical architecture and performance. The performance bottleneck caused by the single-process architecture: Existing technologies use Java to call the CTP SDK to implement futures trading functions. While the technical field is completely consistent with this invention, it is limited by the single-process architecture design. It needs to load a dynamic library compiled by SWIG (Simplified Wrapper and Interface Generator) via JNI (Java Native Interface) to access the futures company's trading platform. Because the CTP underlying dynamic library has inherent limitations on resource access to single-process services, when the number of users reaches a certain scale (such as around 1000 users in existing technologies), the system will experience a significant performance bottleneck, manifested as increased transaction response latency and resource utilization saturation. The only way to alleviate this problem is to add more servers, leading to a significant increase in hardware costs and operational complexity.

[0003] The unresolved scalability limitation due to connection count limitations: While existing technologies have introduced WebSocket communication modules and possess some distributed processing capabilities, they have not overcome the core issue of connection count limitations. In multi-user concurrent scenarios, the gateway lacks an effective isolation mechanism for managing connections from different users. Abnormal connections from a single user can easily affect the overall stability of the gateway, and the inability to dynamically allocate connection load based on hardware performance limits the system's scalability.

[0004] While gateway technologies in the international securities and futures sectors offer some valuable insights into their mechanisms, they cannot directly address the core issues of domestic futures trading gateways due to differences in application scenarios or limitations in technological approaches. Load balancing solutions with insufficient scenario adaptability: The order processing logic design of existing technologies for securities trading does not take into account the differences in dedicated communication protocols and interfaces of domestic futures trading desks (such as CTP, Pegasus, etc.). Their load balancing mechanisms cannot be directly adapted to the integration needs of multiple types of domestic futures desks and require a lot of modifications to migrate to futures trading scenarios.

[0005] Limitations of incompatible technical approaches: Existing technologies use C++ to reconstruct the existing gateway architecture, but this solution only converts the FIX / FAST protocol and cannot be compatible with specialized protocols such as CTP and Pegasus protocols commonly used in the domestic futures trading field. Furthermore, it does not involve unified encapsulation of multiple counters and support for multi-language access, and cannot meet the core requirements of domestic futures trading systems for multi-counter integration.

[0006] Based on existing technical solutions both domestically and internationally, current futures trading gateways generally suffer from the following common problems that urgently need to be addressed: High complexity of multi-counter access adaptation: The underlying SDK interfaces of different futures counters (CTP, Pegasus, Kingstar, etc.) are very different. Existing gateways need to develop an adaptation module for each counter separately. If the terminal client needs to switch the futures counter it accesses, it needs to modify the interface call code, resulting in high development and maintenance costs. Poor multi-language compatibility: Existing solutions mostly rely on cross-language calling technologies such as JNI, and only support access from a few programming languages ​​such as Java. They lack support for mainstream development languages ​​such as PHP, Python, and Go, which limits the technology choices for terminal clients. Weak fault isolation capability: Most solutions adopt a single-process or lightweight thread pool architecture. An abnormal process of a single user (such as crash or underlying dynamic library failure) will spread to the entire gateway system, causing multi-user transactions to be affected and resulting in low system availability. Insufficient load and scalability: Existing load balancing solutions (such as round-robin load balancing and IP origin pull) do not dynamically allocate load based on hardware performance, resulting in low hardware resource utilization and difficulty in exceeding the maximum number of supported users, thus failing to meet the needs of high-concurrency transactions.

[0007] Therefore, there is an urgent need for a futures trading gateway implementation method that can integrate multiple types of futures trading desks, support multilingual access, and have efficient load balancing and fault isolation capabilities, in order to solve the above-mentioned defects of existing technologies. Summary of the Invention

[0008] The purpose of this invention is to address the aforementioned technical problems by providing a method for implementing a futures trading gateway.

[0009] In view of this, the present invention provides a method for implementing a futures trading gateway, comprising 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.

[0010] Furthermore, 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.

[0011] Furthermore, 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.

[0012] Furthermore, a load balancing scheduling step is included between steps S1 and S2, specifically as follows: 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.

[0013] Furthermore, 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.

[0014] Furthermore, the request transmission in step S3 and the response return in step S5 also include 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.

[0015] Furthermore, 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.

[0016] Furthermore, 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.

[0017] Furthermore, 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.

[0018] Furthermore, in step S2, after the transaction gateway creates a dedicated sub-process, it also records the process identifier (PID) of the sub-process. During subsequent transaction data interaction, the transaction gateway uses the PID to establish an association with the sub-process, the underlying SDK, or the CTPSDK to ensure accurate data transmission.

[0019] The beneficial effects of this invention are: This application avoids performance bottlenecks caused by the increase in the number of users under a single process by developing a transaction gateway based on C++ and allocating independent child processes to the client. It can support more users' concurrent transactions without adding an extra server. This application addresses the issue of separate adaptation required for multiple futures trading platforms by deploying underlying SDKs and CTP SDKs adapted to various types of futures trading platforms, and by combining them with a pre-defined unified interface API data structure. This shields the differences in SDK calls between different futures trading platforms, thus reducing the complexity of multi-platform access. This application establishes a long TCP connection based on the WebSocket protocol conforming to the IETF RFC 6455 standard, replacing the traditional JNI call, and realizes bidirectional real-time communication between multi-language clients such as Java, PHP, Python, C++, and Go and the transaction gateway, simplifying the cross-language interaction process; This application, through a complete process design of request reception, parsing and adaptation, front-end forwarding, and response feedback, ensures a smooth and continuous link from the client-side initiation of a transaction request to the futures company's front-end processing and response feedback, thereby improving the stability of the transaction process. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the implementation method of a futures trading gateway proposed in this invention. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0022] In the description of this application, it should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. For ease of description, the dimensions of the various parts shown in the drawings are not drawn to actual scale. Techniques, methods, and devices known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and devices should be considered part of the specification. In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. It should be noted that similar reference numerals and letters in the following drawings denote similar items; therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.

[0023] It should be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0024] Reference Figure 1 An implementation method for a futures trading gateway 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.

[0025] This application avoids performance bottlenecks caused by the increase in the number of users under a single process by developing a transaction gateway based on C++ and allocating independent child processes to the client. It can support more users' concurrent transactions without adding an extra server. This application addresses the issue of separate adaptation required for multiple futures trading platforms by deploying underlying SDKs and CTP SDKs adapted to various types of futures trading platforms, and by combining them with a pre-defined unified interface API data structure. This shields the differences in SDK calls between different futures trading platforms, thus reducing the complexity of multi-platform access. This application establishes a long TCP connection based on the WebSocket protocol conforming to the IETF RFC 6455 standard, replacing the traditional JNI call, and realizes bidirectional real-time communication between multi-language clients such as Java, PHP, Python, C++, and Go and the transaction gateway, simplifying the cross-language interaction process; This application, through a complete process design of request reception, parsing and adaptation, front-end forwarding, and response feedback, ensures a smooth and continuous link from the client-side initiation of a transaction request to the futures company's front-end processing and response feedback, thereby improving the stability of the transaction process.

[0026] In the example of this application, 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.

[0027] As a preferred example of the present invention, this application creates independent child processes based on the operating system-level process isolation mechanism. When any client-specific child process exits due to an anomaly (such as process crash or underlying SDK failure), only the transaction link of that client is interrupted, without affecting the operation of the transaction gateway main process and the dedicated child processes of other clients, thus avoiding the risk of the entire system being paralyzed due to a single user failure. In addition, it can reduce the impact of a single point of failure on the system, ensure that the transactions of most clients are not affected by individual anomalies, maintain the continuous and stable operation of the futures trading system, and reduce the probability of system downtime or service interruption.

[0028] In the example of this application, 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 the Java native interface.

[0029] As a preferred example of the present invention, this application supports clients developed in Java, PHP, Python, C++, and Go languages, covering mainstream development languages, meeting the access needs of users with different technology stacks, and expanding the applicable scenarios of the transaction gateway; The client can encapsulate the request data using its own programming language's WebSocket library, without relying on Java Native Interface (JNI) for cross-language call development, thus avoiding the complex adaptation work of JNI development.

[0030] In the example of this application, a load balancing scheduling step is further included between steps S1 and S2, 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.

[0031] As a preferred example of the present invention, this application uses a load balancing algorithm of "weighted connection number = active connection number (P) / performance weight (Weight)" to allocate new transaction requests to the server with the smallest weighted connection number, thereby avoiding the situation where some servers are overloaded and some servers are idle. Based on a transaction gateway cluster composed of multiple servers and load balancing scheduling, the user limit of a single server can be broken. By synchronizing the number of active connections (P) and performance weights (Weight) of each server in real time via TCP communication, the load calculation is ensured to be based on the latest cluster status, avoiding scheduling deviations caused by information lag and maintaining overall cluster load balance.

[0032] In the example of this application, step S3, before the transaction gateway receives the request data, also includes an identity authentication step: 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.

[0033] As a preferred example of the present invention, the authentication process of RSA public key signing and private key verification ensures that the client initiating the transaction request is a legitimate and authorized user, prevents unauthorized clients from accessing the transaction gateway, and avoids illegal transaction requests from entering the system; Identity authentication data is transmitted along with transaction request data, and subsequent data parsing can only be performed after verification with a preset RSA private key. This effectively prevents attackers from forging transaction requests (such as impersonating legitimate users to initiate transactions), ensuring the legality and security of futures trading.

[0034] In the example of this application, the request transmission in step S3 and the response return in step S5 further include 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.

[0035] As a preferred example of the present invention, the transaction gateway and the client perform bidirectional encryption processing on the request data and response data based on a pre-negotiated AES symmetric encryption key to prevent the data from being stolen by third parties during transmission (such as data interception during public network transmission) and ensure that transaction data (such as the amount of the order and account information) is not leaked. If the encrypted data stream is tampered with, the valid data cannot be obtained by decryption, thus indirectly realizing data integrity verification and preventing attackers from tampering with transaction requests (such as modifying order prices or quantities) or response data (such as modifying market conditions or transaction results), thereby ensuring the authenticity of transaction data.

[0036] In the example of this application, 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.

[0037] As a preferred example of the present invention, the response data of the transaction gateway is compressed using the gzip compression algorithm to reduce the size of the response data, reduce the transmission time of data in the TCP long connection, and improve the speed at which the client receives the response. Compressed response data consumes less network bandwidth, especially in multi-user concurrent transaction scenarios, which can reduce overall network bandwidth consumption, lower network resource costs, and avoid transmission congestion caused by insufficient bandwidth.

[0038] In the example of this application, 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.

[0039] As a preferred example of the present invention, data is forwarded through a private network channel such as a dedicated line or intranet between the trading gateway and the futures company's front-end machine, replacing the traditional public network transmission. This avoids the impact of public network fluctuations (such as delays and packet loss). According to the relevant test data in the disclosure document, the transmission delay can be reduced from about 300ms in the traditional public network to within 50ms, thereby improving the real-time performance of futures trading. Private network channels offer more stable network quality and lower packet loss rates, reducing issues such as transaction request timeouts and response loss caused by public network instability, and ensuring the timely transmission and processing of futures trading instructions (such as orders and cancellations).

[0040] In the example of this application, in step S1, the trading gateway enables seamless switching between different futures trading platforms by uniformly encapsulating the corresponding underlying SDK, so that the client does not need to modify the interface call code.

[0041] As a preferred example of the present invention, the trading gateway, through the unified encapsulation of the underlying SDK of multiple types of futures trading desks, allows the client to switch from one futures trading desk to another (such as switching from a CTP desk to a Hang Seng desk) without modifying any interface call code, thus avoiding the cumbersome process of redeveloping the adaptation interface required for traditional desk switching. The client does not need to pay attention to the type of futures trading platform it is connected to, nor does it need to develop dedicated interfaces for different trading platforms. This reduces the client's technical adaptation and maintenance costs and improves the client's compatibility with different futures company trading platforms.

[0042] In the example of this application, in step S2, after the transaction gateway creates a dedicated sub-process, it also records the process identifier (PID) of the sub-process; during subsequent transaction data interaction, 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.

[0043] As a preferred example of the present invention, the transaction gateway records the process identifier (PID) of the dedicated subprocess and establishes an association with the subprocess, the underlying SDK or CTP SDK through the PID, so as to avoid confusion of transaction data from different clients during transmission (such as passing the request data of client A to the subprocess of client B), and ensure that each transaction data is accurately matched with the corresponding client and SDK. By using the PID as a unique identifier for data interaction, the transaction gateway can quickly locate the target subprocess and associated SDK, reduce the complexity of data routing, improve the processing efficiency of transaction data, and facilitate subsequent troubleshooting of specific client transaction links (such as tracking the transaction data flow log of a client by using the PID).

[0044] The embodiments of this application have been described above with reference to the accompanying drawings. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. This application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method of implementing a futures exchange gateway, the method comprising: The method comprises the following steps: S1, taking a computer server as a hardware carrier, deploying a bottom-layer SDK and a CTP SDK suitable for multiple types of futures counters in the server, and building a basic communication link with a futures company front-end machine; S2, when a terminal client initiates a transaction request, a Boost library is called to create an independent sub-process based on a C++-developed transaction gateway, and a dedicated process instance is allocated for the client; S3, the client establishes a TCP long connection with the transaction gateway through a WebSocket protocol, and sends encapsulated transaction request data; after receiving and analyzing the data, the transaction gateway transmits the data to the bottom-layer SDK or the CTP SDK; wherein the WebSocket protocol conforms to the IETF RFC 6455 standard; S4, the transaction gateway adapts the parsed request data through a preset unified interface API data structure, shields the SDK calling differences of different futures counters, and then forwards the data to the corresponding futures company front-end machine; 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 bottom-layer 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.

2. The method of claim 1, wherein, In the step S2, the independent sub-process is created based on an 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 dedicated sub-processes of other clients.

3. The method of claim 1, wherein the method further comprises: In the 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.

4. The method of claim 1, wherein the method further comprises: Between the steps S1 and S2, there is also a load balancing scheduling step, specifically: Multiple 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; The P value and the Weight value of each server in the cluster are synchronized to other servers in real time through TCP communication; wherein Weight>0, and the default value is 1; When a new transaction request arrives, each server calculates its own weighted connection number through the formula "weighted connection number=P / Weight"; The transaction gateway allocates 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 to execute the step S2 to create a dedicated sub-process.

5. The method of claim 1, wherein the method further comprises: In the step S3, before receiving the request data, there is also an identity authentication step: The client signs its own identity information based on an RSA public key to generate identity authentication data; The client sends the identity authentication data to the transaction gateway together with the transaction request data; The transaction gateway verifies the identity authentication data through a preset RSA private key, and executes data analysis after verification; if the verification fails, the request is rejected, and a response of authentication failure is returned.

6. The method of claim 5, wherein the method further comprises: In the request transmission of the step S3 and the response return process of the step S5, there is also a data encryption step: The transaction gateway and the client pre-negotiate to determine an AES symmetric encryption key; Before the client sends the request data, the data is encrypted using the key; After the transaction gateway receives it, the data is decrypted using the same key; Before the transaction gateway returns the response data, the data is encrypted using the key; After the client receives it, the data is decrypted using the same key.

7. The method of claim 1, wherein the method further comprises: In the response return step of step S5, before the transaction gateway encapsulates the response data, a data compression step is further included: The transaction gateway uses the gzip compression algorithm to compress the response data; After the client receives the compressed response data, it is restored to the original response data through the gzip decompression algorithm, and subsequent business processing is performed.

8. The method of claim 1, wherein the method further comprises: In step S4, before being forwarded to the corresponding futures company front-end machine, the private network channel between the transaction gateway and the futures company front-end machine is used to realize the transmission, which includes a dedicated line or an intranet channel, and is used to replace public network transmission to reduce data transmission delay.

9. The method of claim 1, wherein the method further comprises: In step S1, the transaction gateway encapsulates the corresponding underlying SDK to enable seamless switching between different futures counters without modifying the interface call code of the client.

10. The method of claim 1, wherein the method further comprises: In step S2, after the transaction gateway creates a dedicated sub-process, it also records the process identifier PID of the sub-process; 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.

Images