Recovery

Backup connection

FIX Antenna allows specifying the primary and backup connection for a session. The backup connection is used instead of the primary one, when the latter is not usable. The parameters of backup connection are specified in the B2BITS_Session_ConnectInitiator() method. If the enableAutoSwitchToBackupConnection_ session parameter is enabled, the session changes the primary connection to the backup automatically after reconnect attempts exceed Reconnect.MaxTries. If the cyclicSwitchBackupConnection_ session parameter is enabled, the session automatically switches the primary connection to the backup and back in cycle.

The B2BITS_SessionExtraParameters::keepConnectionState_session parameter means that the session will continue using the current storage and values of the InSeqNum and OutSeqNum. Otherwise the new storage will be created and seqNums will be reset.

For example:

B2BITS_Application appl;

// Creates session Sender:Target that keeps state at switch connection
B2BITS_SessionExtraParameters params;
params.keepConnectionState_ = true;

B2BITS_Session sn = B2BITS_FixEngine_CreateSession(&appl, "Sender", "Target", B2BITS_FIX44, &params, B2BITS_persistent_storageType); 

B2BITS_SessionBackupParameters backupParams;
backupParams.host_ = "localhost";
backupParams.port_ = 5679;
backupParams.params_ = NULL;

// establishes connection with the primary connection - localhost:4567
B2BITS_Session_ConnectInitiator(30, "localhost", 4567, &backupParams);

Store-and-forward

FIX Antenna follows two main rules:

1. Outgoing message is stored to the file and then sent
2. Incoming message is stored to the file after it is processed

There are two very important consequences of these rules, which in combination with FIX sequencing and retransmission make losing messages in FIX Antenna impossible:

1. If an application crashes during incoming message processing, the message will not be stored and after the connection is restored the sequence number too high will be identified and a resend request will be sent.
2. If an application crashes before a message is delivered to the counter-party, the counter-party will identify a gap after the connection is restored and send a request for retransmission.

Gap fill

Gap fill is a standard FIX mechanism for indentifying and resolving message loss. It is based on sequencing messages in each direction, resend request mechanism, PosDup flag and sequence reset.

When the session identifies a "sequence number too high" problem it sends a resend request message asking for retransmission of lost messages. The opposite side resends requested messages with PosDupFlag set to "Y". Session level messages are not resent. The sequence reset is used to keep sequence numbers consistent during resending.

FIX Antenna resolves the gap fill automatically, i.e. no manual work is required. However it is possible to intervene into the standard mechanism. The Engine::Application::onResend method is called each time an application level message is resent. It is possible to return "false" for those messages, which should not be resent; sequence reset will be sent instead.

Fail-over

FIX Antenna comes with a basis for failover. This means that if an application crashes FIX Antenna will fully restore its state after the next initialization as it was before crash. No information will be lost.