The FixRepository.xml file is used to generate a specification used by the engine.
This specification defines the enumerated values for Enum Fields, field order in messages and groups, and Data (binary) fields that must be stepped over when parsing.
Customized flavors of a protocol are created by editing this file.
It is possible to add a user defined tag with a function calls, which is handy when testing, e.g. adding a time tag to measure latency.
The second's precision for a message's Sending Time is defined in the engine's configuration file. The engine honors the configuration file's value while ignoring the protocol's limit of 3 decimal places.
To use your preferred time source, create a Time Module and give it to the engine. The engine marks the receive time of an in-bound message and the sending time of an out-bound message with this module's timestamp.
This module is passed to all message callbacks.
The static class model defines the tag ids and Enum tags values in your code. By using the model through the Message Index, you are guided to add only legal tags and legal tag values for that message. Use of this model is optional.
Since the model is a set of static classes, your IDE will help you navigate through the classes to find the value you want. You can enter the model via 3 indexes:
by Field IDs
by Message type
by Component name (Groups are defined under a Component)
Statically load balance the connections into Session threads based on their anticipated message load.
There is no need to enforce Sessions with only Acceptors or only Initiators.
As a buy side, you may find the rare sell side that wants to connect to you, i.e. you become an Acceptor.
You can easiliy deploy this connection with your existing connections instead of dedicating a new
engine session (with three threads) to this one broker.
The engine's configuration includes a start/stop schedule for each connection. The engine will
automatically schedule the login and logout to meet this schedule.
When the engine is in Standby, the auto login and logout will have no effect. When the engine shifts to Active, the
computed login and logout state for that time are honored.
A Client's thread Scheduler is available to help with:
starting and stopping connections
ensuring a connection is disconnected after sending a logout even if a logout reply is never returned.
A Session Scheduler is available to work without impacting the Client's thread. This scheduler:
is used for logging state information, e.g., sequence numbers, in-bound messages, etc.
and would be ideal for logging statistics or sending test messages on a connection to keep it hot.
The engine can start in Standby and, later, shift to Atcive. In standby, the state logger invokes the client's
HA callbacks to broadcast a request to the active state logger. On receipt, the active state logger invokes
HA callbacks to send the standby engine the current state. For all future updates, the engine will invoke the HA callbacks
to broadcast updates to all standby engines.
The engine supports a "replay messages" interface to allow the client level to replay messages from the external connections
back into the client's system. This "replay" is to assist the client-side's system in restarting midday.
Features for the FIX Protocol
Start coding by writing your application message handler.
ISMFIX Engine handles the default session layer processing requirements.
The engine's configuration file is your deployment model. This model is used to define, start and stop the connections
without additional coding at the client level.
The examples provided with the download have an acceptor process and initiator process defined
to demonstrate the minimal code required to start the two processes heart beating.
You start with writing only five abstract methods for the client's callback handlers.
Two methods for callbacks of a disconnect on attempted connections.
One method for a callback on a deactivated state change due to a logout or an illegal, unrecoverable condition.
One method for a callback of a midday disconnect.
One method for a callback to process non-session level messages, i.e. application level messages.
Provides default session level management allowing the client level to start with processing application messages.
Supports specifications in the FIX Trading Community™'s Unified/FixRepository.xml
and dialects defined by modifying the file.
Supports only TCP connections.
Provides FIX Message utilities to parse and format FIX messages including:
handling Data type tags with their binary data.
group tags, group segments and group field ordering.
programatically defining user defined tags for messages.
Provides FIX state logging to allow disconnect and connection recovery, gap fill request processing, etc.