Versions Compared

Old Version 7

changes.mady.by.user Leeza Gavronsky

Saved on

compared with

New Version Current

changes.mady.by.user Artem Kleshchev

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Overview

...

The FIX Standard recommends using two independent counters for gap detection: one for incoming sequence numbers and a second for outgoing sequence numbers. Along with automatic recovery, the FIX Engine provides a set of options to specify gap handing and sequence reset management strategies for troubleshooting issues related to message sequencing or gaps. The synchronization of sequence numbers on both sides (initiator and acceptor) is critically important because desync can lead to financial loss.

Info

Click the link to see more information about FIXEdge Recovery Time Objective and Recovery Point Objective.

A retransmitted message uses the original MsgSeqNum(34) value with PossDupFlag(43)=Y.

When idle, the FIX engine maintains the integrity of a connection by sending Heartbeat (0) and Test Request (1) messages.

Trading session or trading hours

...

  • In the context of trading sessions, the start of the trading session is called Start of Day (SOD)
  • In the context of trading sessions, the time when the session goes offline is called End of Day (EOD)
  • In some cases, the trading day doesn't have strict bounds or hours. Case details and configuration options are described in this article.

The FIX Standard provides the following recommendations about sequencing during trading hours:

  • 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

...

In FIX Antenna C++-based products, users can customize the mode that considers a Logout message as the end of the trading day with the property IntradayLogoutTolerance.

When IntradayLogoutTolerance = false, FIX Antenna changes the session state to "Correctly terminated" after receiving a Logout (5) message and resets the session sequence numbers. FIX Antenna will not continue reconnecting or accept connections if the session is in the "Correctly terminated" state.

FIX Antenna Java

TBD.

FIXEdge

A FIXEdge user can configure the mode that considers a Logout message as the end of the trading day by setting the property FixLayer.FixEngine.Session.Session_Name.RecreateOnLogout = false.

On Logout, FIXEdge notifies to stop the reconnection of FIX sessions and change the state of the sessions to Correctly Terminated.

If reconnection or keeping sequences are not needed, this option should be used in a combination with FixLayer.FixEngine.Session.Session_Name.TerminateOnLogout. For example:

Results with the session object will be removed and FIX logs will be moved to an archive after receiving the Logout (5) message.

For keeping session in memory (don't move logs to archive after Logout), keep sequencing and store outgoing messages the user should specify options: 

Info

The trading day (EOD and SOD times), and hence the time for the next reconnection for the session, is configured with the FIXEdge schedule. Refer to the Cron-Like Session Schedule Properties article for details.

FIXEdge can endlessly recreate the session after the Logout (5) messages if the properties are:

Reset sequences on each logon or logout

...

In FIX Antenna C++-based products, users can force sequence numbers to reset in logon messages (Logon (A)) with the property ForceSeqNumReset.

Valid values for ForceSeqNumReset include:

  • "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.

...

A FIXEdge user can force sequence numbers to reset in logons for each session individually with the property FixLayer.FixEngine.Session.Session_Name.ForceSeqNumReset.

Valid values for the property include:

...

In FIX Antenna C++-based products, users can force sequence numbers to reset after disconnection by setting ResetSeqNumOnNonGracefulTermination = true.

ForceSeqNumReset should be set to false to avoid sending ResetSeqNumFlag (141) = Y in the Logon (A) message.

These options should be configured via the engine.properties file.

FIX Antenna Java

TBD.

FIXEdge

A FIXEdge user can force sequence numbers to reset for each session individually with the property FixLayer.FixEngine.Session.Session_Name.ResetSeqNumOnNonGracefulTermination.

FixLayer.FixEngine.Session.Session_Name.ForceSeqNumReset should be set to false to avoid sending ResetSeqNumFlag (141) = Y in the Logon (A) message.

...

Info

The sequences are reset without session disconnection when the session is being established

FIX Antenna C++

FIX Antenna Java

TBD.

FIXEdge

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.

...

The trading session period can be specified with Cron-Like Session Schedule Properties in FIXEdge. 

Sequence number reset and archiving happens at the time specified by Schedules.Schedule_Name.TerminateTime. 

FIX Antenna Java

In FIX Antenna Java, the user should enable the option to reset sequences by schedule with performResetSeqNumTime and specify the time for resting with resetSequenceTime.

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.

...

In FIX Antenna C++-based products, users can enable this sequence numbers handing mechanism by setting the session parameter HandleSeqNumAtLogon to true.

FIX Antenna Java

In FIX Antenna Java, users can enable this sequence numbers handing mechanism by setting the session parameter handleSeqNumAtLogon to true.

...

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.

One of the common reasons for this behavior is the wrong sequence reset schedule resulting in the wrong session state. One party has reset sequences but another is not.  The user should verify if the session state is handled correctly and sequence reset rules correspond each other on the both sides.

FIX Engine allows users to ignore this restriction with the option IgnoreSeqNumTooLowAtLogon.

FIX Antenna

In FIX Antenna C++-based products, users can accept sessions with sequences that are lower than expected by setting the session parameter IgnoreSeqNumTooLowAtLogon to true.

FIX Antenna Java

In FIX Antenna Java, users can accept sessions with sequences that are lower than expected by setting the session parameter ignoreSeqNumTooLowAtLogon to true.

...

In FIXEdge C++ users can accept sessions with sequences lower than is expected by setting the session parameter FixLayer.FixEngine.Session.Session_Name.IgnoreSeqNumTooLowAtLogon to true.

Note
It is important to understand the consequences of violating FIX Protocol recommendations in order to make a more stable connection with undefined behavior.

...

For manual requests, the user should compose the Resend Request (2) message with tags specifying the range for requested messages with tags BeginSeqNo (7) and EndSeqNo (16).

Requesting a single message

To request a single message: Both BeginSeqNo (7) and EndSeqNo (16) are set of the missing 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.

...

Info

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.

Info

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 endSeqNo is greater than the maximum sequence number supported by FIX Antenna, we use maxStorageSeqNo and post warning message into the log that is correct as well.

...

The maximum possible value of BeginSeqNo (7) for requesting is signed int 32: 2147483647. The values higher then this will be rejected with reason: "Invalid Resend Request: BeginSeqNo <= 0".

...

Sequences can be modified via FIXEdge Admin REST API functions

Sequences can be reset  via FIXEdge Admin REST API functions

...

FIXICC administrative UI tool provides users a way to update sequences. See details in Manage Sequence Numbers.

FAJ

TBD.

FEJ

The way to modify sequences is described here: FIXEdge Java Administration

...

  1. Ignoring duplicate resend requests with the option FixLayer.FixEngine.Session.Session_Name.IgnoreDuplicateResendRequests.
    If the option is enabled, FIXEdge will     ignore Resend Request (2) duplicates. This option should be used the property DuplicateResendRequestLimit > 0.

    Note

    Ignoring resend requests is not compliant with the FIX Standard Protocol.

  2. Limiting the volume of messages that can be sent back as a reply on the each resend request

The option FixLayer.FixEngine.Session.Session_Name.ResendMessagesLimit defines the maximum number of messages in the FIXEdge response. If a counterparty requests a large volume of response messages, FIXEdge only responds to the first ResendMessagesLimit from the block and then sends a Test Request (1) message notifying that synchronization has been finished. The client should adjust the resend requesting gap according to the new BeginSeqNo (7) value.

Info

This behavior is beyond the FIX Standard. However, it allows the user to have quick and resource efficient message recovery. It is recommended under high load for systems with multiple sessions. 

Before enabling it the user should be sure that the counterparty is ready for this.

The values available for ResendMessagesLimit include:

  • "-1" - disabled, default
  • "0" - does not resend real messages, replies with GapFill
  • any positive number - the maximum number of messages in the FIXEdge response

If the option is not disabled, FIXEdge will ignore the duplicates of resend requests.

How to use the ResendMessagesBlockSize parameter

ResendMessagesBlockSize specifies the number of messages that would be processed during logon preparation in one storage reading iteration. This option is used for performance tuning.

By knowing the average message size and cache size, the user can fine-tune this parameter for the best resend request preparation performance. The optimal value can be determined experimentally. The best value can be found experimentally. The blocks should be fit in a single MFU.

Default value: 1000

This option is important when there is a need to optimize time spent on resending request processing and there are multiple resend requests.

  • Lowering the value reduces the time between getting a request and sending the response to the counterparty but increases the time for overall resend request processing when resending big volumes.

    Info

    This option is preferable if memory resources are limited, and storage is slow

  • Raising the value increases the time between getting a request and sending the response to the counterparty but reduces the time for overall resend request processingwhen resending big volumes.

    Info

    This option is preferable if there is a lot of free RAM and disk storage is fast.

How to use the ResendRequestBlockSize parameter

The ResendRequestBlockSize parameters limit the number of messages that will be requested in a resend request at once when a gap is detected by FIX Engine.

...