File-based Session Storage
For each FIX session with a File-based Session Storage the following files are created in the StorageDirectory :
STORAGE_ID.summary- contains inbound and outbound FIX messages.
STORAGE_ID.state- contains session state-related data.
To create a session with file-based session storage, the
storageType parameter in the
Session(String, String, ProtocolVersion, Boolean, SessionStorageType, String)
constructor should be set to the FileBasedStorage value.
const bool keepSequenceNumbersBetweenFixConnections = true; var session = new Session("SenderCompID", "TargetCompID", ProtocolVersion.Fix44, keepSequenceNumbersBetweenFixConnections, SessionStorageType.FileBasedStorage);
Segmented File-based Storage
File-based Storage could be configured to store messages in a set of
*.summary files, instead of single one. In this mode, logged messages are split through multiple files called "segments".
Segmented mode of File-based Storage is activated when the FileBasedStorageSegmentSize property is set to a positive value during the Engine initialization.
var settings = new EngineSettings(); settings.FileBasedStorageSegmentSize = 256 * 1024; settings.IgnoreFileBasedStorageIntegrityErrors = true; Engine.Init(settings); const bool keepSequenceNumbersBetweenFixConnections = true; Session initiator = new Session("SenderCompID", "TargetCompID", ProtocolVersion.Fix44, keepSequenceNumbersBetweenFixConnections, SessionStorageType.FileBasedStorage);
Segments names are in the following format:
STORAGE_ID- the name of the storage (available via the StorageId property).
-part-N- the segment suffix, the
Nis 1-based segment index. The segment where the latest messages are written does not have this suffix.
For example, the following set of files could be created:
, etc. Oldest messages are stored in STORAGE_ID-part-1.summary
, and the latest ones - in STORAGE_ID.summary`.
The current number of segments (
N+1) is stored in the
STORAGE_ID.state file (the
When a session is re-started, to restore previously sent messages segment files are analyzed in the following order:
The number of segments to analyze depends on the ResendingQueueSize value and on message types (for example, session-level messages are not restored).
While the session is active, all segments that could be used to service inbound Resend Request messages are kept opened to prevent unexpected deleting.
When new messages arrive, new storage segments are created if needed. If the older ones become unused, they are closed and could be archived.
Restoring Session State from File-based Storage
When a Session instance with a File-based Session Storage is created, the FIX Session state (sequence numbers of last received and sent messages, previously sent messages, etc.) is restored from files that were written earlier.
To start a FIX session as a new one (so-called "clean start"), it is necessary to remove the session files from the previous run.
Connecting parties must bi-laterally agree as to when sessions are to be started/stopped, and log files are backed up based upon individual system and time zone requirements.
When the FIX session is finished, the session files are not needed anymore. They can be backed up, and later a new FIX session with the same SenderCompId and
TargetCompId will start sequence numbers from
The usual practice is to back up the log files at the end of each business day (so-called "End Of Day procedure") to start the sequence numbers from
1 at the beginning of the next day.
To reset the local sequence numbers to
1 and back-up the log files, use the ResetLocalSequenceNumbers() member. This method can be called only when the session is disconnected.
When the session state is restored, the Engine checks that all files required to fill the resending queue are available and could be read.
If some files are not available or inaccessible the Engine behavior depends on the IgnoreFileBasedStorageIntegrityErrors property:
false(the default value): an exception is thrown.
true: a new empty storage with a new
STORAGE_IDis created; all sequence numbers are reset to
1; the corresponding message is written to the Engine log.