Persistent session
Persistent session is a session with persistent storage.
Session state is stored on a disk and can be restored after failure. The following information is stored for a session:
- Session parameters (SenderCompID, TargetCompID, FIX version, etc.)
- Session incoming sequence number
- Incoming messages (optional)
- Outgoing messages
Transient session
Transient session is a session with transient storage.
Session state is stored in memory, which increases performance highly. This is the recommended way in case when the session is not required to provide a fail-over by itself.
Session state
From the moment of creation till till the moment of destruction the session uses the state that dictates its reaction to events. The session state can be obtained using the Engine::Session::getState() method, which returns Session::State.
- INITIAL - The session has been created, but has not been connected yet
- WAIT_FOR_FIRST_LOGON - The session has been connected as an Acceptor and is waiting for the first Logon message
- WAIT_FOR_CONFIRM_LOGON - The session has been connected as an Initiator, the first Logon message has been sent and it is waiting for the conforming Logon message
- SWITCH_CONNECTION - The session change connection from primary to backup (or back)
- ESTABLISHED - The session is fully established
- RECONNECT - The session-initiator has detected the telecommunication link error and is trying to re-establish the link
- CORRECTLY_TERMINATED - The session has been correctly terminated
- NON_GRACEFULLY_TERMINATED - The session has been non-gracefully terminated
Sequence number handling
The session is always assigned with two sequence numbers:
- Incoming sequence number is a counter for incoming message
- OUtgoing sequence number is a counter for outgoing message
Both sides must maintain the two values and ensure that they are in sync. There are two types of sequence numbers desync:
- Sequence number too high indicates message loss and leads to resend procedure.
- Sequence number too low indicates some serious problem and leads to immediate session termination and manual sequence number synchronization.
Both sequence numbers start from 1 when the session is created from scratch. After the correct session termination sequence numbers are reset to 1. If connection is terminated non-gracefully sequence numbers will continue after it is restored. In fact a lot of service providers never reset sequence numbers during the day. There are also some, who reset sequence numbers once per week. There are several cases to handle such deviation from standard in FIX Antenna
- IntradayLogouttolerance mode makes the session always go to the non-gracefully terminated state, which means the sequence numbers will continue on the next connection. It is enough to remove FIX session persistent files from the logs directory to reset sequence numbers. Since FIX Antenna stores session state in those files, absence of such file will be treated as session being created from scratch and thus sequence numbers will be set to 1. Files can be removed during the End-Of-Day or End-Of-Week procedure.
- ForceSeqNumReset mode makes the session reset sequence number each time on logon and forces the counter-party to do the same (standard FIX mechanism). This is not a recommended way since messages sent during inactivity time will be lost.
Resetting sequence number
It is recommended that a new FIX session is established once within each 24 hour period. The new set of sequence numbers can be set by sending a Logon message with the ResetSeqNumFlag set. FIX Antenna supports this feature via ResetSeqNumAfter24hours configuration option.
Late delivery vs rejecting
When session connection is lost, the initiator tries to reconnect, which may take some time (or even infinity), and the acceptor waits for reconnect. For both sides message delivery is impossible. FIX Antenna provides two different approaches to message handling in this case:
- Late delivery (default mode) means that all outgoing messages are stored in outgoing queue and sent once connection is reestablished.
- Message rejecting means that after some reasonable period of time messages are rejected i.e. they are removed from outgoing queue and reject message is sent to the counter-party.
The B2BITS_SessionExtraParameters::enableMessageRejecting_ parameter controls if Message rejecting is enabled or not (by default it is disabled). The MessageTimeToLive configuration file property specifies how long the session waits for connection restore (i.e. before rejecting the message). If the connection is not restored during the MessageTimeToLive interval - the session starts rejecting messages by calling B2BITS_Application::OnMsgRejectEvent() for each rejected message.