TT FIX Inbound Drop Copy client applications require a FIX session to be created in Setup in order to connect to TT FIX servers. Client applications should be designed with the following session management considerations in mind:
TT FIX Order Routing sessions are persistent by default and reset on Saturdays at 22:00 UTC.
Clients may optionally define a custom daily reset time when configuring a FIX Order Routing session in Setup [link to the Creating FIX Session in Setup section]. The default reset on Saturday at 22:00 UTC will occur in addition to a custom reset schedule defined on the session.
Note If a FIX client remains connected to a FIX session when either the default or custom scheduled reset time occurs, TT’s FIX engine will send a Logout message.
By default, message sequence numbers for FIX sessions are reset when TT resets all FIX sessions. Message sequence numbers can also be reset, when desired, by setting Tag 34 (MsgSeqNum) = 1 and Tag 141 (ResetSeqNumFlag) = Y when sending a Logon (A) message.
TT FIX will ensure ClOrdID (tag 11) uniqueness for:
For more information, refer to the ClOrdID tag description in the New Order Single (D) message.
If your FIX client application disconnects and subsequently reconnects, TT’s FIX engine will perform an internal recovery process to query our cloud based order book database and will deliver all unsent execution reports by applying an incremental sequence number that picks up where we left off prior to the disconnect. The session recovery process can be considered complete in all cases with a News message [35=B].
This eliminates the requirement for your FIX client application to detect a gap on the session level and request missed execution reports while disconnected. This also allows FIX client applications to failover seamlessly into a different datacenter without sequence number consideration.
If your FIX client application disconnects and was unable to process executions prior to the disconnect, TT’s FIX engine supports the standard message replay mechanism specified by the FIX Protocol by honoring Resend Request [2] messages received from FIX client applications.
In extreme cases where your FIX client application unexpectedly disconnected and required intervention on your side to reset sequence numbers that resulted in a subsequent Logon with 141=Y and 34=1, TT’s FIX engine will still perform a session recovery process that will query our cloud based order book database for executions marked as undelivered and apply an incremental sequence number to each message message. In this case, Logon [34=1], missed executions [34=2, 3, etc]. The session recovery process can be considered complete in all cases with a News message [35=B].
In the scenario where although TT delivered all relevant execution reports to your FIX client application, your internal system may have experienced an issue and was unable to process the messaging. TT’s FIX Engine is aware of sent messages, but we are unaware of your application's success or failure to process them. If your FIX client application also required a sequence number reset and cannot request a Resend Request [2] message, executions can be retrieved through our REST API [link to REST].