Order loss detection method in quantitative transaction field

Abstract

The invention provides an order loss detection method in the field of quantitative transactions. The method comprises the following steps: S01, a transaction request sends data to a transaction counter through a UDP (User Datagram Protocol) channel; and S02, all transaction responses and returns of the transaction counter are sent to the transaction unit through a TCP link. S03, receiving the uplink transaction request data packet by the transaction counter, and detecting whether packet loss occurs or not; and if packet loss exists, an error is returned. And S04, the transaction unit receives a downlink transaction response and return, judges whether packet loss occurs in the uplink UDP channel, and notifies a transaction strategy detection result. And S05, determining whether to retransmit the transaction request or ignore the packet loss according to the transaction strategy. The invention relates to a transmission method with packet loss detection based on TCP and UDP (User Datagram Protocol). According to the invention, rapid order reporting in a UDP mode can be realized, and a potential order loss problem can be detected at the same time. When the user perceives that the order is lost, the user can decide whether to retransmit the order or neglect the lost order by himself / herself.

Description

Technical Field

[0001] The invention belongs to the field of quantitative trading and relates to a method for detecting lost orders in the field of quantitative trading. Background Art

[0002] In a quantitative trading system, trading clients use computer programs to quickly trade according to established trading strategies. The sooner these trading requests are sent to the exchange matching system, the greater the possibility of achieving the goal. For this reason, computer programs containing trading strategies are usually deployed as close to the trading center as possible. Therefore, the network environment of quantitative trading is usually a local area network environment spanning very few network nodes.

[0003] Generally speaking, the client of the trading strategy is connected to the trading counter through the LAN environment. The probability of data message loss in the LAN network transmission is very small and almost negligible. This is also the main reason why many latency-sensitive trading customers are willing to use unreliable UDP for trading.

[0004] Although the probability of packet loss in the trading local area network environment is low, when all trading customers have the same frequency resonance of strategy, the network traffic will surge. In this case, the network instantaneous pulse traffic may exceed the network traffic, resulting in packet loss. Packet loss will not affect the customer's transaction, as long as the wrong packet is not sent to the exchange. However, because in most application scenarios, customers cannot perceive UDP silent packet loss in time, and cannot make corresponding response strategies. This is unacceptable to trading customers who have high reliability requirements. Summary of the invention

[0005] 1. Technical problems to be solved: How to meet the requirements of extremely fast order submission via UDP and reliable transmission (packet loss detection) in different scenarios.

[0006] 2. Technical solution: In order to solve the above problems, the present invention provides a method for detecting lost orders in the field of quantitative trading. The client that initiates a transaction request is a transaction unit, and the server is a transaction counter, including the following steps: Step S01: The transaction request sends data to the transaction counter through the UDP channel.

[0007] Step S02: All transaction responses and returns of the transaction counter are sent to the transaction unit via the TCP link:.

[0008] Step S03: After receiving the uplink transaction request data packet, the transaction counter detects whether there is packet loss; if there is packet loss, an error is returned.

[0009] Step S04: After the trading unit receives the downstream trading response and return, it determines whether packet loss has occurred on the upstream UDP channel and notifies the result of the trading strategy detection.

[0010] Step S05: The trading strategy decides whether to retransmit the trading request or ignore the current packet loss.

[0011] Further, the method for the trading counter to determine whether packet loss has occurred includes the following steps: Step S21: Determine whether it is a new trading channel by judging according to the trading link ID.

[0012] Step S22: If it is a new trading channel, the received data packet is considered as the first packet. If it is not the first packet of the trading channel, it is detected whether the packet sequence number is continuously increasing. If not, it is considered that a packet loss problem has occurred and a packet loss error is returned.

[0013] Further, the method for the trading unit to determine whether packet loss has occurred includes the following steps: Step S31: If the return error code received from the counter is a specific "packet loss error", it is considered that packet loss has occurred on the upstream link.

[0014] Step S32: After detecting that packet loss has occurred, use the packet sequence number recovery algorithm to restore to the correct data packet sequence number. Otherwise, all subsequent data packets will be rejected by the trading counter.

[0015] Further, the trading unit packet sequence number recovery method includes the following steps: Step S41: After each successful transmission of a trading request, save the current maximum request packet sequence number, and the packet sequence number is denoted as ReqSeqNo.

[0016] Step S42: Read the error code in the trading return returned by the TCP link. If it is a packet loss error, read the corresponding response packet sequence number, and the response packet sequence number is denoted as RspSeqNo.

[0017] Step S43: Compare the sizes of RspSeqNo - 2 and ReqSeqNo. If RspSeqNo – 2 < ReqSeqNo, replace ReqSeqNo with RspSeqNo - 2; otherwise, ignore it.

[0018] Step S44: For the next trading request data packet, increment it based on ReqSeqNo, that is, ReqSeqNo + 1.

[0019] Further, the trading unit packet sequence number recovery method includes the following steps: Step S51: After each successful transmission of a trading request, save the current maximum request packet sequence number, and the packet sequence number is denoted as ReqSeqNo.

[0020] Step S52: Read the error code in the transaction return from the TCP link. If it is a packet loss error, read the difference value between the corresponding response RspSeqNo and the sequence number. The response packet sequence number is denoted as RspSeqNo, and the difference value of the sequence number is denoted as SeqNoGap.

[0021] Step S53: Compare the magnitudes of RspSeqNo - SeqNoGap - 1 and ReqSeqNo. If RspSeqNo - SeqNoGap - 1 < ReqSeqNo, then replace ReqSeqNo with RspSeqNo - SeqNoGap - 1; otherwise, ignore it. Step S54: For the next transaction request data packet, increment it based on ReqSeqNo, that is, ReqSeqNo + 1.

[0022] Further, the method for detecting the sequence number of the lost data packet is as follows: Step S61: Increase the acknowledgment sequence number: AckSeqNo, and save the maximum sequence number value confirmed by the trading counter.

[0023] Step S62: In the downstream return of the trading counter, if there is no order rejection due to sequence number error, then it is considered that the sequence number RspSeqNo is confirmed.

[0024] Step S63: Compare the sequence number in the downstream return with the currently saved confirmed sequence number. If RspSeqNo > AckSeqNo, then replace AckSeqNo with RspSeqNo; otherwise, ignore it.

[0025] Further, if the received packet loss error return sequence number is RspSeqNo, the method for confirming which data packet is lost is as follows: Step S71: If AckSeqNo == RspSeqNo – SeqNoGap – 1, then the lost packet sequence number is AckSeqNo + 1.

[0026] Step S72: If AckSeqNo < RspSeqNo – SeqNoGap – 1, then the lost packet sequence number is a range [AckSeqNo + 1, RspSeqNo – SeqNoGap].

[0027] Step S73: For the TCP transmission of the downstream traffic, ensure that all non-lost returns can reach, and the range will be gradually reduced until the sequence number of the lost packet is accurately located.

[0028] Furthermore, in step S05, the specific method is: using a cache queue or a mapping table to associate the serial number with the user's service number, and reversely check the service number through the serial number, and let the user know.

[0029] 3. Beneficial effects: The present invention is a transmission method with packet loss detection based on TCP and UDP. It can realize extremely fast order submission in UDP mode and detect potential order loss problems. When the user perceives that the order is lost, he can decide whether to retransmit the order or ignore the order loss. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0031] The following is a detailed description with reference to the accompanying drawings and embodiments.

[0032] Assume that the client that initiates the transaction request is the trading unit, and the server is the trading counter. The requirements are as follows: the trading unit actively establishes a reliable TCP virtual link with the trading counter; the trading counter supports UDP data reception, and the trading unit can send UDP data to the trading counter; after the trading unit establishes a connection with the counter, the trading counter assigns a unique ID to this transaction link; when the trading strategy triggers a transaction, the trading unit sends a request to the counter through the UDP protocol; the UDP data sent by the trading unit carries the transaction link ID and data packet sequence number, which is used by the trading counter to identify the transaction link; Using a TCP link and a UDP channel to meet the needs of various application scenarios, the present invention provides a method for detecting lost orders in the field of quantitative trading, such as Figure 1 As shown, the specific steps are: Step S01: The transaction request sends data to the transaction counter through the UDP channel.

[0033] Step S02: All transaction responses and returns of the transaction counter are sent to the transaction unit via the TCP link:.

[0034] Step S03: After receiving the uplink transaction request data packet, the transaction counter detects whether there is packet loss; if there is packet loss, an error is returned.

[0035] Step S04: After receiving the downlink transaction response and report, the transaction unit determines whether packet loss has occurred in the uplink UDP channel, and notifies the transaction strategy detection result.

[0036] Step S05: The transaction strategy determines whether to retransmit the transaction request or ignore the packet loss.

[0037] This method can achieve extremely fast order reporting in UDP mode and can also detect potential order loss problems. When the user perceives an order loss, they can decide whether to retransmit the order or ignore the current order loss.

[0038] In one embodiment, a method for a trading counter to determine whether a packet is lost includes the following steps: Step S21: Determine whether it is a new trading channel based on the trading link ID.

[0039] Step S22: If it is a new trading channel, consider the received data packet as the first packet, or determine whether it is the first packet based on SeqNo.

[0040] Step S23: If it is not the first packet of the trading channel, detect whether the packet sequence number is continuously increasing. If not, consider that a packet loss problem has occurred and return a packet loss error.

[0041] In one embodiment, a method for a trading unit to determine whether a packet is lost includes the following steps: Step S31: If the return error code received from the counter is a specific "packet loss error", consider that a packet loss problem has occurred in the uplink; Step S32: After detecting a packet loss, use a packet sequence number recovery algorithm to restore to the correct data packet sequence number; otherwise, all subsequent data packets will be rejected by the trading counter.

[0042] Here, the trading unit can sense whether a packet loss problem has occurred in the uplink. However, it does not know which data packet is lost.

[0043] In one embodiment, a method for a trading unit to recover the packet sequence number: Step S41: After each successful transmission of a trading request, save the current maximum request packet sequence number, and record the packet sequence number as ReqSeqNo.

[0044] Step S42: Read the error code in the trading return returned by the TCP link. If it is a packet loss error, read the corresponding response packet sequence number, and record the response packet sequence number as RspSeqNo.

[0045] Step S43: Compare the magnitudes of RspSeqNo - 2 and ReqSeqNo. If RspSeqNo – 2 < ReqSeqNo, replace ReqSeqNo with RspSeqNo - 2; otherwise, ignore it.

[0046] Step S44: For the next trading request data packet, increment it based on ReqSeqNo, that is, ReqSeqNo + 1.

[0047] Through this method, the packet sequence number can be restored to the correct value and the order form can continue to be processed.

[0048] For the above sequence number restoration algorithm, when encountering a scenario where the SeqNo jumps too much, it takes a long time to restore to the correct SeqNo, and it is necessary to continuously try and error through order forms and rejections to restore to the correct value. In terms of efficiency, this restoration algorithm is very low, and in the actual production scenario, long-term blocking will cause dissatisfaction among trading customers.

[0049] In one embodiment, for this abnormal scenario, a fast sequence number restoration method is given: Step S51: After each successful transaction request is sent, save the current largest request packet sequence number, and the packet sequence number is denoted as ReqSeqNo.

[0050] Step S52: Read the error code in the transaction return returned by the TCP link. If it is a packet loss error, then read the difference value between the corresponding response RspSeqNo and the sequence number. The response packet sequence number is denoted as RspSeqNo, and the difference value of the sequence number is denoted as SeqNoGap.

[0051] Step S53: Compare the sizes of RspSeqNo - SeqNoGap - 1 and ReqSeqNo. If RspSeqNo - SeqNoGap - 1 < ReqSeqNo, then replace ReqSeqNo with RspSeqNo - SeqNoGap - 1; otherwise, ignore it. Step S54: For the next transaction request data packet, increment it based on ReqSeqNo, that is, ReqSeqNo + 1.

[0052] Here, when SeqNoGap = 1, it degenerates into a slow restoration algorithm.

[0053] Although the above processing logic can detect the occurrence of packet loss, it does not detect which packet is lost. To accurately detect the sequence number of the lost data packet, a confirmation process needs to be added.

[0054] In one embodiment, the method for detecting the sequence number of the lost data packet is as follows: Step S61: Add a confirmation sequence number: AckSeqNo, and save the largest confirmed sequence number value returned by the trading counter.

[0055] Step S62: In the downstream return of the trading counter, if there is no rejection due to sequence number error, then it is considered that the sequence number RspSeqNo is confirmed.

[0056] Step S63: Compare the sequence number of the downstream return with the currently saved confirmed sequence number. If RspSeqNo > AckSeqNo, then replace AckSeqNo with RspSeqNo; otherwise, ignore it.

[0057] After correctly processing AckSeqNo, if a packet loss error return (with sequence number RspSeqNo) is received, then according to the following packet loss detection method, it is possible to confirm which data packet is lost. In one embodiment, the packet loss detection method is as follows: Step S71: If AckSeqNo == :RspSeqNo – SeqNoGap – 1, then the lost packet sequence number is AckSeqNo + 1.

[0058] Step S72: If AckSeqNo < RspSeqNo – SeqNoGap – 1, then the lost packet sequence number is a section [AckSeqNo + 1, RspSeqNo – SeqNoGap], and the data packets within this interval may all be lost. Although it is impossible to determine the exact data packet, the range of packet loss can be immediately determined.

[0059] The TCP transmission of the downstream traffic can ensure that all non-lost returns can reach. Therefore, in the final process, this range will be gradually reduced until the sequence number of the lost packet is accurately located.

[0060] The problem of the above packet loss range only appears in the scenario where the returns may be out of order. If it can be ensured that the trading counter trading returns are processed in order, then the foregoing phenomenon will not occur, but the sequence number of the lost packet can be accurately located.

[0061] Packet loss detection is a post-event discovery. When a packet is lost, the problem cannot be immediately detected. That is to say, it is necessary to continuously send data packets to detect the occurrence of packet loss in a timely manner. For the processing of the last data packet, if it is lost, it cannot be perceived.

[0062] Similarly, if a packet is lost in the middle, but the triggering time of the next data packet is relatively late, and the time difference between the two data packets is relatively large. Then, it is also impossible to perceive the packet loss in a timely manner and take countermeasures.

[0063] A feasible boundary packet loss detection method is: regularly send specific data packets on the upstream channel, carrying SeqNo and trading link ID information, so as to drive the logic of packet loss detection. For example: when there is no trading request, send a heartbeat packet every 500ms. The heartbeat packet can be a data packet that is agreed to be ignored.

[0064] Through the above method, it is possible to locate which data packet sequence number is lost, but it is not possible to inform the user of the number of the service information. The user cannot decide whether to retransmit or ignore.

[0065] One method of detecting packet loss service numbers is to use a cache queue or mapping table to associate the sequence number with the user's service number (local order cancellation number). Use the sequence number to reversely check the service number and let the user know.

[0066] For example, use a circular queue of size 256, with seqNo as the subscript index, for fast search. As for the capacity of the circular queue, it can be determined according to the needs of the order business. Generally speaking, 256 is enough, or even less is also possible, depending on the number of in-transit order reports and the rate at which users place orders.

[0067] In the following examples, the following are determined: 1. req-99: indicates that the trading unit sends a trading request (order submission or order cancellation) with sequence number 99 to the trading counter.

[0068] 2. rsp-99: indicates that the trading counter returns the transaction return numbered 99 to the trading unit.

[0069] 3. OK: Indicates that the trading counter accepts the transaction request and no packet loss error occurs (errors caused by other reasons are also considered OK).

[0070] 4. failed: indicates that the transaction counter returns a failure because it detects that the sequence number is discontinuous (errors caused by other reasons are not included in this range).

[0071] 5. Ignore: means ignore and do not update the sequence number.

[0072] 6. seqno-gap: If the counter does not explicitly return, the default value is 1.

[0073] Example 1 case-01: seqno=98 / / Assume this value is wrong, req-99, seqno=99 / / Report the data packet with sequence number 99, and record the sequence number as 99. rsp-99, failed, seqno=99-1-1<99 / / The counter returns a packet loss error (seqno-gap = 1). seqno=97 / / The sequence number falls back to 97, req-98, seqno=98 / / Report the data packet with sequence number 98, and record the sequence number as 98. rsp-98, ok / / Correct.

[0074] Example 2 Case-02: Batch order scenario, seqno=100 / / Assume this value is wrong, req-101 102 103, seqno=103 / / Report three data packets with sequence numbers 101 / 102 / 103 in batches, with the record sequence number being 103. rsp-101 failed, seqno=101-1-1<103 / / The counter returns a packet loss error, and the calculated seqno is less than the current value. seqno=99 / / The sequence number falls back to 99. rsp-102 failed, seqno=102-1-1>99, ignore / / The counter returns a packet loss error, and the calculated seqno is greater than the current value. Ignore. rsp-103 failed, seqno=103-1-1>99, ignore / / The counter returns a packet loss error, and the calculated seqno is greater than the current value, ignore, req-100, seqno=100 / / Report the data packet with sequence number 100, record sequence number 100, rsp-100, ok / / Correct.

[0075] Example 3 Case-03: Batch orders and out-of-order responses. seqno=100 / / Assume this value is wrong, req-101 102 103, seqno=103 / / Report three data packets with sequence numbers 101 / 102 / 103 in batches, with the record sequence number being 103. rsp-103 failed, seqno=103-1-1<103 / / The out-of-order caused the return of 103 to arrive first. seqno=101 / / The sequence number falls back to 101. rsp-101 failed, seqno=101-1-1<101, seqno=99 / / The sequence number falls back to 99. rsp-102 failed, seqno=102-1-1>99, ignore, req-100, seqno=100 / / Report the data packet with sequence number 100, record sequence number 100, rsp-100, ok / / Correct.

[0076] Example 4 Case-04: Batch order scenario, with orders inserted in the middle. seqno=100 / / Assume this value is wrong, req-101 102 103, seqno=103 / / Report three data packets with sequence numbers 101 / 102 / 103 in batches, with the record sequence number being 103. rsp-101 failed, seqno=101-1-1<103 / / The counter returns a packet loss error, and the calculated seqno is less than the current value. seqno=99 / / The sequence number falls back to 99. req-100 seqno=100 / / Report the data packet with sequence number 100, and record the sequence number as 100. rsp-102 failed, seqno=102-1-1=100, ignore / / The counter returns a packet loss error, and the calculated seqno is equal to the current value. Ignore. rsp-103 failed, seqno=103-1-1>100, ignore / / The counter returns a packet loss error, and the calculated seqno is greater than the current value. Ignore. rsp-100, ok / / Correct.

[0077] Example 5 case-05: Slow recovery in abnormal scenarios, req-101 102 1003, seqno=1003, rsp-101, ok, seqno=1003, rsp-102, ok, seqno=1003, rsp-1003, failed, seqno=1003-2<1003<-- An abnormal order number appeared. seqno=1001, req-1002, seqno=1002 / / Send a new order, keep trying and erroring, and drive seqno back to the correct value. rsq-1002, failed, seqno=1002-2<1002, seqno=1000, req-1001, seqno=1001, rsq-1001, failed, seqno=1001-2<1001, seqno=999, ... / / It takes about 900 intermediate orders to restore to the correct state.

[0078] req-105, seqno=105, rsq-105, failed, seqno=105-2<105, seqno=103, req-104, seqno=104, rsq-104, failed, seqno=104-2<103, seqno=102 / / The sequence number is restored to the correct value. req-103, seqno=103, rsq-103, ok.

[0079] Example 6 Case-06 Rapid recovery in abnormal scenarios. The counter brings back the gap value of seqno. Assume that the maximum range of the gap value is 1024 (it can be adjusted and designed as needed). req-101 102 1003 2003, seqno=2003, rsp-101, ok, seqno=2003, rsp-102, ok, seqno=2003, / / Consider the out-of-order scenario, the return from 2003 arrives first, and the return from 1003 arrives later. rsp-2003, failed, gap=1024, seqno=2003-1024-1=978 / / An abnormal order number appeared. The maximum gap value was used to quickly restore the order number to seqno=978. req-979, seqno=979 / / New orders will still have a lost order error report. rsp-1003, failed, gap=900, seqno=1003-900-1=102 / / The report of 1003 carries gap=900, and quickly recovers to seqno=102. rsp-979, failed, gap=979-103=876, seqno=979-876-1=102, ignore / / The sequence number has been updated correctly, ignore this report, req-103 seqno=103, rsq-103 ok.

[0080] Example 7 case-07: Accurately detect the sequence number of lost packets, batch orders and reports out of order, seqno=100, ack-seqno=99 / / Assume that the data packet with sequence number 100 is lost. req-101 102 103, seqno=103, ack-seqno=99 / / Report three packets with sequence numbers 101 / 102 / 103 in batches, with the record number 103. rsp-103 failed, seqno=103-1-1<103 / / The out-of-order caused the return of 103 to arrive first. seqno=101 / / The sequence number falls back to 101. At this time, the packet loss range should be sensed: [100,101], ① rsp-101 failed, seqno=101-1-1<101, seqno=99 / / The sequence number falls back to 99, seqno=99=ack-seqno, at this time it should be confirmed that the lost packet number is: 99+1=100, ② rsp-102 failed, seqno=102-1-1>99, ignore, req-100, seqno=100 / / Report the data packet with sequence number 100, record sequence number 100, rsp-100, ok / / Correct.

[0081] In the above embodiment, because the out-of-order scenario is taken into consideration, it is not possible to determine which data packet is lost at step ①, and only a range can be confirmed; if out-of-order does not occur, then in the above process, the packet loss sequence number can be confirmed at step ① without waiting until step ②.

Claims

1. A method for detecting lost orders in the field of quantitative trading, wherein the client that initiates a transaction request is a trading unit, and the server is a trading counter, and the method is characterized by: The following steps are involved: Step S01: The transaction request sends data to the transaction counter through the UDP channel; Step S02: All transaction responses and returns from the transaction counter are sent to the transaction unit via the TCP link: Step S03: After receiving the uplink transaction request data packet, the transaction counter detects whether there is packet loss; if there is packet loss, an error is returned; Step S04: After receiving the downlink transaction response and report, the transaction unit determines whether packet loss has occurred in the uplink UDP channel, and notifies the transaction strategy detection result; Step S05: The transaction strategy determines whether to retransmit the transaction request or ignore the packet loss.

2. The method for detecting lost orders in the field of quantitative trading according to claim 1, characterized in that: The method for the trading counter to determine whether a packet is lost includes the following steps: Step S21: judging whether it is a new transaction channel according to the transaction link ID; Step S22: If it is a new transaction channel, the received data packet is considered to be the first packet. If it is not the first packet of the transaction channel, the packet sequence number is checked to see if it is continuously increasing. If not, it is considered that a packet loss problem has occurred and a packet loss error is returned.

3. The method for detecting lost orders in the field of quantitative trading according to claim 2, characterized in that: The method for the transaction unit to determine whether a packet is lost includes the following steps: Step S31: If the error code reported back by the counter is a specific "packet loss error", it is considered that a packet loss problem occurs in the uplink; Step S32: After detecting packet loss, use the packet sequence number recovery algorithm to restore the correct data packet sequence number:, otherwise, all subsequent data packets will be rejected by the transaction counter.

4. The method for detecting lost orders in the field of quantitative trading according to claim 3, characterized in that: The transaction unit package sequence number recovery method includes the following steps: Step S41: After each successful transaction request is sent, the current largest request packet sequence number is saved, and the packet sequence number is recorded as ReqSeqNo; Step S42: read the error code in the transaction report returned by the TCP link. If it is a packet loss error, read the corresponding response packet sequence number, which is recorded as RspSeqNo; Step S43: compare the sizes of RspSeqNo - 2 and ReqSeqNo. If RspSeqNo - 2 < ReqSeqNo, replace ReqSeqNo with RspSeqNo - 2; otherwise, ignore it. Step S44: The next transaction request data packet is incremented based on ReqSeqNo, i.e., ReqSeqNo + 1.

5. The method for detecting lost orders in the field of quantitative trading according to claim 3, characterized in that: The transaction unit package sequence number recovery method includes the following steps: Step S51: After each successful transaction request is sent, the current largest request packet sequence number is saved, and the packet sequence number is recorded as ReqSeqNo; Step S52: read the error code in the transaction report returned by the TCP link. If it is a packet loss error, read the corresponding response RspSeqNo and the difference value of the sequence number. The response packet sequence number is recorded as RspSeqNo, and the difference value of the sequence number is recorded as SeqNoGap; Step S53: compare the size of RspSeqNo - SeqNoGap - 1 and ReqSeqNo: if RspSeqNo - SeqNoGap - 1 < ReqSeqNo, replace ReqSeqNo with RspSeqNo - SeqNoGap - 1; otherwise, ignore it; Step S54: The next transaction request data packet is incremented based on ReqSeqNo, i.e., ReqSeqNo + 1.

6. The method for detecting lost orders in the field of quantitative trading according to claim 4 or 5, characterized in that: The method to detect the sequence number of the lost data packet is: Step S61: Add the confirmation sequence number: AckSeqNo, and save the maximum confirmed sequence number value returned by the transaction counter; Step S62: In the downlink report of the trading counter, if the order is not rejected due to a wrong sequence number, the sequence number RspSeqNo is considered to be confirmed; Step S63: Compare the sequence number reported in the downlink with the currently saved confirmed sequence number. If RspSeqNo > AckSeqNo, use RspSeqNo to replace AckSeqNo; otherwise, ignore it.

7. The method for detecting lost orders in the field of quantitative trading according to claim 6, characterized in that: If the packet loss error report sequence number is RspSeqNo, the method to confirm which data packet is lost is: Step S71: If AckSeqNo == RspSeqNo – SeqNoGap – 1, then the packet loss sequence number is AckSeqNo + 1; Step S72: If AckSeqNo <: RspSeqNo – SeqNoGap – 1, then the packet loss sequence number is a segment [AckSeqNo + 1, RspSeqNo – SeqNoGap]; Step S73: TCP transmission of the downstream traffic ensures that all reports of non-lost packets can be received, and the scope will be gradually reduced until the sequence number of the lost packet is accurately located.

8. The method for detecting lost orders in the field of quantitative trading according to claim 1, characterized in that: In step S05, the specific method is: use a cache queue or a mapping table to associate the serial number with the user's service number, check the service number through the serial number, and let the user know.

Images