|Table of Contents|
This article will describe the most common cases, best practices, and configuration properties for sequence number handing and possible related issues.
Trading session or trading hours
A FIX endpoint (for example, exchange or venue) can specify the time when the FIX client connection becomes available. More info about trading sessions can be found here: https://www.fixtrading.org/standards/fix-session-layer-online/#fix-session.
- Messages from previous trading days can be recovered
- At the SOD, a client should connect with sequence numbers 1/1
- Counterparties should maintain incrementing sequences till the EOD
- On disconnections or on receiving a Logout message, the application can reconnect and continue with sequences from the most recently connected session within the trading day
- This is common practice and not a strict recommendation
- The way the client should behave with sequences upon reconnection is usually described in a specification document or connectivity specification and can vary across different venues
- After EOD, it is recommended to stop reconnecting and schedule the connection at the next SOD
- After EOD, sequence numbers can be reset because on the next trading day sequences will be reset to 1/1
- Usually after EOD, users perform cleanup procedures such as moving FIX logs to an archive if they need to be saved for an audit
Trading session limited by incoming Logout
The EOD can be triggered by an incoming Logout (5) message from a counterparty. The FIX Engine should interpret it as the end of trading hours and start the EOD procedure, such as stop session and reconnection attempts, and resetting sequences because the next logon will be considered a new trading day.
The trading day (EOD and SOD times), and hence the time for the next reconnection for the session, is configured with FIXEdge schedule. Refer to the Cron-Like Session Schedule Properties article for details.
Reset sequences on each logon or logout
There are cases when trading sessions exist only while a session is established. That means that the session state can be recovered after disconnection, can be recovered only within a connection, or sequencing isn't needed for that message flow. For example, in market data scenarios, the session state should be recovered from a snapshot and all messages from the previous connection are obsolete or redundant.
Reset on Logon
- "0" or "false" - Does not reset sequence numbers on Logon. Keeps session sequences from a previous connection.
- "1" or "true" - Resets sequences at the first session initiation, i.e. when the FIX Engine hasn't detected logs from the previous run.
- "2" - Resets sequences for every Logon.
Reset on Logout
In some scenarios, venues recommend resetting sequences on logout or disconnection. In these scenarios, if sequences are reset on logon, messages accumulated after disconnection and before logon will be lost due to the message flag ResetSeqNumFlag (141) being = Y. If the user wants to send the messages accumulated after the disconnection, resetting sequences on logout is preferred to resetting sequences on logon. In the next logon message, the ResetSeqNumFlag (141) should not be present in the Logon (A) message or set to = N.
FixLayer.FixEngine.Session.Session_Name.ForceSeqNumReset should be set to false to avoid sending ResetSeqNumFlag (141) = Y in the Logon (A) message.
Reset sequences every 24 hours
Reset sequences once a week
Some exchanges (like CME Logon Scenarios) uses weekly sessions and resets sequences once a week, using the same sequence counter across multiple days.
- performResetSeqNumTime - specifies whether to reset sequence number at the time defined in resetSequenceTime
- resetSequenceTime - specifies a GMT time when the FIX Engine initiates the reset
FIX sessions with uninterrupted connections
Sometimes a session cannot be dropped and must be maintained forever. In other words, the session should be connected 24/7/365.
There is no option to enable this behavior in our products. The functionality for sequence reset should be implemented by the user or counterparty.
Sequence numbers recovery during Logon
In FIXEdge C++, users can enable this sequence numbers handing mechanism by setting the session parameter FixLayer.FixEngine.Session.Session_Name.HandleSeqNumAtLogon to true.
The sequence number is too low on Logon
FIX Engine will not accept the session if it detects that a counterparty connects with a sequence lower than expected and ResetSeqNumFlag (141) is not set.This behavior is recommended by the FIX Standard as a serious problem. For example, it identifies the issue that messages on both sides are inconsistent and this may lead to financial losses.
Requesting a single message
Requesting a range of messages
To request a range of messages should be equal to the first message of range, should be equal to the last message of the range.
- To request a range of messages: BeginSeqNo (7) is set to the MsgSeqNum (34) of the first message of the range of missing messages and EndSeqNo (16) is set to the MsgSeqNum (34) of the last message of the range of missing messages.
Requesting all messages from a specific sequence number
- To request all messages subsequent to a particular missing message: BeginSeqNo (7) is set to the MsgSeqNum (34) of the first message of range and EndSeqNo (16) is set to 0. Zero is used to specify all messages after the message with MsgSeqNum (34) = BeginSeqNo (7)
This approach is recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.
Setting EndSeqNo(16) to 0 has been the recommended approach since FIX.4.2.
Negative case: Resend request with a correct BeginSeqNo and wrong EndSeqNo
In cases when the counterparty sends EndSeqNo (16) greater than the current counter of outgoing sequence numbers, FIX Antenna sends all messages from BeginSeqNo (7) to the last known message with the current outgoing sequence number.
For example, there is a request is for 1-100 but FIX Engine has only 10 messages so FIX Engine will send messages with sequence from 1 to 10.
Negative case: Resend request with a wrong BeginSeqNo
In cases when the counterparty sends invalid or greater than expected BeginSeqNo (7), the FIX Engine treats it as unexpected and sends back a reject message.
- If BeginSeqNo is greater than expected, QuickFIX doesn’t reject it but sends a Sequence Reset (4) message with NewSeqNo(36) equal to the next expected sequence number expected by the counterparty and doesn’t resend messages.
- If BeginSeqNo is greater than int32, then QuickFIX treats it as a negative integer (-2147483648), sends Sequence Reset message with 34=-2147483648 and 36=2, and then resends all messages.
Modify Sequence Numbers Manually
FIX Antenna C++
The way to modify sequences is described here: FIXEdge Java Administration
Limiting the number of messages in the resend request response from FIXEdge
This option is available starting with FIXEdge version 6.3.0.
If option is not disabled, FIXEdge will ignore the duplicates of resend requests.
Performance optimizations with the ResendMessagesBlockSize parameter
FIX Engine allows fine-tuning performance by splitting one big resend request in to multiple batches of ResendMessagesBlockSize messages. The best value can be found experimentally. The blocks should be fit in a single MFU.