Managing order book state: persistent FIX order sessions
Determining the order book state
Persistent FIX order sessions are stateful. Specifically, FIX clients persist the order book state as well as the last message sequence number received from the TT FIX Adapter. The TT FIX Adapter persists the same information. Therefore, the order book state and message sequence number are linked.
When a FIX client initializes, it should use the following process to determine the current order book state:
its local cache to determine the:
- Order book state since the last time it connected to the TT FIX Adapter
- Last message sequence number received from the TT FIX Adapter
- Send a Logon (A) message to the TT FIX Adapter with Tag 34 (MsgSeqNum)=(1 + <last message sequence number sent to the TT FIX Adapter>).
- Process all order update messages pending from the TT FIX Adapter.
The following example shows how a FIX client using a persistent FIX order session maintains an up-to-date order book, even when it disconnects and reconnects to the TT FIX Adapter.
Note: FIX clients can use either Tag 11 (ClOrdID) or Tag 37 (OrderID) when referencing order handling messages, because the TT FIX Adapter preserves both across connections.
Handling missed messages
Persistent FIX sessions support the standard message replay mechanism specified by the FIX Protocol. A TT FIX Adapter honors Resend Request (2) messages received from FIX clients because the TT FIX Adapter caches all messages that it sends.
Handling connection problems
During the course of normal operation, various problems, such as hardware failures, can occur. To account for the possibility of failures, TT recommends that you make two duplicate TT FIX Adapters (primary and secondary) available to FIX clients. These redundant adapters should be configured identically so that FIX clients can interact with both in the same manner.
If a FIX client that uses a persistent FIX session cannot communicate with its primary TT FIX Adapter, it should automatically connect to the secondary TT FIX Adapter, reset the session, and determine the current order book state. Specifically, the FIX client should:
- Send a Logon (A) message to the secondary TT FIX Adapter with Tag 34 (MsgSeqNum)=1 and Tag 141 (ResetSeqNumFlag)=Y.
- Request the current state of all orders by sending an Order Status Request (H) message, omitting both Tag 11 (ClOrdID) and Tag 37 (OrderID).
- Determine the trader’s current position by using one of the
- Requesting all trades, manual fills, SODs,
and DSODs since the last rollover by sending sequential Request For Position (UAN) messages
- Tag 16724 (PosReqType)=1 (trades)
- Tag 16724 (PosReqType)=4 (SOD)
- Tag 16724 (PosReqType)=5 (manual fills)
- Tag 16724 (PosReqType)=6 (DSOD)
- Reconcile the information resulting from these requests with the information that the FIX client already received to determine whether anything was missed up to this point.
- Request a list of positions based on all trades, manual fills, SODs, and DSODs that occurred since the last rollover by sending a Request For Position (UAN) message with Tag 16724 (PosReqType)=0 (positions).
- Requesting all trades, manual fills, SODs, and DSODs since the last rollover by sending sequential Request For Position (UAN) messages with:
Because the TT FIX Adapter maintains the session cache locally for each adapter, FIX clients must log into the secondary TT FIX Adapter with Tag 34 (MsgSeqNum)=1 and Tag 141 (ResetSeqNumFlag)=Y to begin a new session. Additionally, TT FIX Adapter preserves neither Tag 11 (ClOrdID) nor any information regarding how the order book got to its current state. You must use Tag 37 (OrderID) to reference all existing orders in all subsequent FIX messages. However, the FIX client can resume normal operations after it resynchronizes its order book.