Recovery

Backup connection

FIX Antenna allows to specify the primary and backup connection for the session. Backup connection means the connection, which is used instead of primary connection, when the primary connection is not usable. The parameters of backup connection specified in the Engine::Session::connect() method. Session changes the primary connection to the backup (and back) when Engine::Session::switchConnection() method called. If enableAutoSwitchToBackupConnection_ session's parameter is enabled, session changes the primary connection to the backup automatically after reconnect attempts exceeds Reconnect.MaxTries. If cyclicSwitchBackupConnection_ session's parameter is enabled, session automatically switches the primary connection to the backup and back in cycle.

The session's parameter Engine::SessionExtraParameters::keepConnectionState_ means that session will continue use current storage and values of the InSeqNum and OutSeqNum. Otherwize new storage will be created and seqNums will be reset.

For example:

Appl appl; // : see the Application class 

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

Engine::Session *sn = Engine::FixEngine::singleton()->createSession(appl, "Sender", "Target", FIX44, &params, persistent_storageType); 

Engine::SessionBackupParameters backupParams;
backupParams.host_ = "localhost";
backupParams.port_ = 5679;
backupParams.params_ = NULL;

// establish connection with primary connection - localhost:4567
sn->connect(30, "localhost", 4567, Engine::NONE, &backupParams);
// wait until connection established 
appl.waitUntilLogon();

// switch to the backup connection - localhost:5679
sn->switchConnection();
appl.waitUntilLogon();

Store-and-forward

FIX Antanna 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 sequenceing and retransmission make impossible losing message in FIX Antenna:

1. If application during the incoming message processing then it will not be stored and after restore the sequence number too high will be identified and resend request will be sent.
2. If application crashes before message is delivered to counter-party then after restore counter-party idertifies gap and sends request for retransmission.

Gap fill

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

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

FIX Antnenna automatically resolves gap fill i.e. no manual work is required. However it is possible to intervernt into standard mechanism. The Engine::Application::onResend method is called each time 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 basis for failover. This means that if application crashes after next initialization FIX Antenna fully restores its state as it was before crash. No information will be lost.