B2BITS provides FIXAntenna QF add-on package for FIX Antenna™ C++ library which helps to migrate from QuickFIX to FIX Antenna™ C++. The package includes C++ classes which implement QuickFIX interface. The migration to FIX Antenna™ engine essentially becomes a replacement for the library. The package also contains tools that help to deal with QuickFIX FIX protocol definition in XML.
FIXAntenna QF Adaptor supports import of customized dictionaries from QuickFIX. This is done by using an XML conversion tool which is part of the migration package (see Converting customized QuickFIX protocol dictionaries ).
The user migrating to FIX Antenna™ can leverage Certified FIX Connections to major exchanges and ECNs still using QuickFIX business object model. This is achieved by using C++ code generator, which is part of the migration package, that can convert B2BITS provided FIX custom protocol definitions into the typed C++ business messages in QuickFIX style (see Generating C++ business objects for standard or customized FIX protocol versions).
Supported QuickFIX features
- Typed C++ message objects and MessageCracker interface
- Transient and persistent FIX session storage
- FIX Session management (schedules)
- 4.x and 5.x FIX protocol versions
- FIX protocol customizations
Features which are not part of the QF adaptor package
The following features are not part of the QF adaptor package. You may consider using the QuickFIX classes instead:
- Database persistence
- Built-in HTTP remote administration. But it is possible to use a rich GUI tool for remote administration: FIXICC
- QuickFIX property names in SessionSettings class. FIX Antenna™ property syntax is supported instead. The static configuration files from QuickFIX are supported (through a conversion tool)
- Dynamic loading of XML dictionaries. The dictionary files should be specified in the configuration file before engine start.
- The following configuration properties currently not fully supported: StartDay, EndDay , MillisecondsInTimeStamps=N, CheckCompID, CheckLatency, MaxLatency. The options StartTime and EndTime are supported though.
- A number of C++ interfaces that represent low-level implementation details of FIX Message class, FIX session, socket connections, message store and FIX session level messaging. The FIX Antenna™ engine library encapsulates its own optimized implementation of these interfaces and hides such low-level details from the user.
This section describes performance scenarios and numbers obtained using PerformanceTest application that is part of the migration package (please find the source code at: ...\QFAdaptor\examples\PerformanceTest). The application code is written using QuickFIX interface, the same source code is used when running the test with QuickFIX and FIX Antenna™ library.
The test application establishes a FIX session on a local host using an instance of ThreadedSocketAcceptor/Initiator class. A FIX message (NewOrderSignle) is repeatedly sent within the session. The time of the FIX message traveling from the sending endpoint to the receiving endpoint is measured and reported. This is the time which is spent between Session::send() call and MessageCracker::onMessage(). FIX session uses persistent disk message store.
CPU: AMD Phenom II X4 3.0 GHz
Average message latency with FIX Antenna™: 38 mcs (min: 34, max: 276)
Average message latency with QuickFIX: 146 mcs (min: 141, max: 14528)
Conclusion: The message delivery time with FIX Antenna™ QF Adaptor is 3.7 times less than that of the QuickFIX library.
The test application establishes FIX sessions on a local host using an instance of SocketAcceptor/Initiator class. A FIX message (NewOrderSignle) is repeatedly sent into each of the created sessions. The test ends once all of the 1,000,000 messages are delivered to the receiving endpoint. The test calculates the throughput that is the number of messages delivered per 1 second.
Conclusion: The message throughput of FIX Antenna™ with QF adaptor is over 7 times more than that of the QuickFIX using the single instance of SocketAcceptor/Initiator class that hosts the sessions. With FIX Antenna™ you don’t need to decide how many of the SocketAcceptor instances to launch in order to load your CPU cores with enough work. The scalability is achieved automatically regardless how the session grouping within particular acceptor/initiator instances.
Typically in order to migrate, you need to do the following steps:
- Install FIX Antenna™
- FIX Antenna™ QF adaptor
- Update your project to include QF adaptor source files and add a QF adaptor initialization call
- Convert QuickFIX configuration files into FIX Antenna™ format
- Compile and run
If you used custom FIX dictionaries:
- Convert the dictionaries into FIXDIC format
- An optional extra step: Generate C++ business objects for custom FIX protocol
1. Migration Package Installation
In order to use the tools included with the package, ensure the following is installed:
Perl version 5.6 or later. Under Windows, we recommend using the ActivePerl distribution. In order to check that Perl is available, use the following command line:
Java 1.5 or higher. In order to check that java is available, use the following command line:
Note: for Linux the Sun Java or OpenJDK packages are recommended. The “gij (GNU libgcj) 1.4 ” was found to show significantly slower performance with the XML conversion tool.
Microsoft Visual Studio™ and GNU C++ compilers are supported. The version of the compiler should be the same as used by your FIX Antenna™ C++ package.
- Install FIX Antenna™ C++ package. For information on how to get it please refer to the web site.
- Unpack and place the “QFAdaptor” folder with FIX Antenna™ QF adaptor into the FIX Antenna™ installation at "\B2BITS\FIX Antenna C++\v220.127.116.11". The version number may be different.
- Run setup.cmd on Windows or setup.sh on Linux. This will create a symlink named "quickfix" pointing to the package's “include” folder with .h files. If the mklink command is not available on your Windows version you may create the “quickfix” folder and copy the contents of “qfa” folder into it.
In the FIX Antenna™ QF Adaptor package the C++ classes are placed in the “QFA::” namespace. Additional define redirects FIX:: namespace definitions used in user programs to QFA::.
To check that everything works OK, you may compile and run the example application found at "\B2BITS\FIX Antenna C++\v18.104.22.168\QFAdaptor\examples\PerformanceTest\”. Please follow the instructions below:
Sample Project - Windows
- Open PerformanceTest_vs2010.sln in Microsoft Visual Studio 2010
- Build the solution
- Go to PerformanceTest\bin\config and run config_convert_1session.cmd and config_convert_10session.cmd command files. These commands convert 1session.cfg and 10sessions.cfg configuration files from QuickFIX to FIXAntenna™ format. Output files are placed in the folder “converted”
- Go to “bin” folder and run run_latency_test.bat, run_throughput_1session.bat, run_throughput_10sessions.bat.
Sample Project - Linux
- Go to PerformanceTest folder and run ‘make’
- Go to PerformanceTest\bin\config and run config_convert_1session.sh and config_convert_10session.sh command files. These commands convert 1session.cfg and 10sessions.cfg configuration files from QuickFIX to FIXAntenna™ format. Output files are placed in the folder “converted”
- Go to “bin” folder and run run_latency_test.sh, run_throughput_1session.sh, run_throughput_10sessions.sh
2. Updating Your Development Project
This chapter provides step-by-step instructions for changing a project that used QuickFIX C++ library and was created in Microsoft Visual Studio 2010. Similar steps will be necessary in the case of other IDEs or platforms (for example, updating the project’s makefile on Linux).
- Follow the general FIX Antenna™ installation instructions
- Remove the references to QuickFIX include and library folders from your project
- Add the "\B2BITS\FIX Antenna C++\v22.214.171.124\QFAdaptor\include” and "\B2BITS\FIX Antenna C++\v126.96.36.199\headers” to your project’s include paths
- Add new library path to the project: "\B2BITS\FIX Antenna C++\v188.8.131.52\lib”
- Add the all_cpp.cpp file that is located in the folder "\B2BITS\FIX Antenna C++\v184.108.40.206\QFAdaptor\include\qfa\cpp\all_cpp.cpp” to your project so that they are compiled together with the rest of your project files.
- Link the project with one of the FIX Antenna™ libs in the lib folder depending on release/debug configuration
You may refer to the sample project that is under "\B2BITS\FIX Antenna C++\v220.127.116.11\QFAdaptor\examples\PerformanceTest\” to see how a project may be set up.4. Converting customized QuickFIX protocol dictionaries for use with FIX Antenna C++ engine
Insert a call to initialize QF adaptor and the instance of FIX Antenna™ library used by this adaptor before making further calls to it:
See the next chapter for the details on producing the .properties files.
In the end of the program, insert a call to shut down the adaptor and the instance of FIX Antenna™ library:
3. Converting QuickFIX configuration files
The QuickFIX session configuration files are converted into B2BITS format using the "<path>\B2BITS\FIX Antenna C++\v18.104.22.168\QFAdaptor\tools\migrate_config\qfa_migrate_config.pl” script. In order to use this script, Perl interpreter version 5.6 or later has to be available. Under Windows we recommend using the ActivePerl distribution.
In order to check the presence and version of Perl, use the following command line:
The migration tool consists of the following files:
- qfa_migrate_config.pl, IniFiles265.pm – Perl scripts
- engine.properties.template, qfa.adaptor.properties.template – Template files that are used to produce appropriate output files.
To convert a QuickFIX .CFG file go to the folder where it resides and invoke the following command:
Refer to the “example_conversion.cmd” file in the migrate_config folder to see how the command is used.
Below are the qfa_migrate_config.pl command line parameters:
The script parses QuickFIX configuration file, maps the QuickFIX settings to the FIX Antenna™ settings and creates the output file. Notice the ERRORs or WARNINGs messages that may be generated by the conversion script when it fails to produce proper mapping and try to correct the cause.
The conversion script will create the following three files1:
- engine.properties – FIX Antenna™ engine global settings. The path to this file is then passed to the QFA::InitializeEngineAdaptor() call.
- qfa.adaptor.properties – The settings used specifically by the adaptor classes that provide QuickFIX interface for the user application. The path to this file is passed to the QFA::InitializeEngineAdaptor() call.
- example.qfa.sessions2 – This is the FIX session definition file. There can be multiple files of such kind used by an application. The path to the file is passed to an instance of FIX::SessionSettings class.
The produced files can also be used by FIXEdge server as well without much change in the format. The leading “QFA.” in the property names have to be replaced with an appropriate FIXEdge prefix (refer to this FIXEdge guide).
Note that Start/TerminateTimeUTC parameters are currently not supported by FIXEdge, use the parameters that specify a local time instead - Start/TerminateTime
Note that two of the files, engine.properties and qfa.adaptor.properties, are used globally and are to be passed to the adaptor initialization call. There can be multiple *.qfa.sessions files used by your program and each conversion would produce the engine.properties and qfa.adaptor.properties files. If this is the case, review the produced engine.properties and qfa.adaptor.properties files (compare the file content) and chose the files for the QFA::InitializeEngineAdaptor() call.
IMPORTANT: The following properties of the global engine.properties file are updated by the migration script and are shared between all FIX connections:
- ListenPort – this is the setting copied from SocketAcceptorPort of the QuickFIX configuration file
- EngineRoot – the path used to resolved the log and message store relative paths
- Log.File.RootDir – the path to the additional log folder (set to be <EngineRoot>/logs)
- LogonTimeFrame, LogoutTimeFrame, AllowEmptyFieldValue, MessageMustBeValidated
The following properties of the global qfa.adaptor.properties file are updated by the migration script and are shared between all FIX connections:
- Log.File.RootDir – the path to the folder where the QF adaptor stores its own logs (set to be <EngineRoot>/logs)
Backup FIX Connection
If the QuickFIX’ configuration file specifies SocketConnectHost1/ SocketConnectPort1 pair, this is converted to the Backup connection properties of the FIX Antenna™ thus enabling to switch to this connection if the primary connection breaks.
Log files to be watched on run-time
After starting the engine, the following log files will be created:
- <EngineRoot>/logs/qfa_engine_<digits>.log – the FIX Antenna™ engine log
- <EngineRoot>/logs/qfa_engine_adaptor.log – the QF adaptor log
- <EngineRoot>/logs/SENDER-TARGET_<digits>.conf – this file will contain the list of actual FIX Antenna™ session settings used when creating particular FIX session identified by <SENDER, TARGET>
4. Converting customized QuickFIX protocol dictionaries for use with FIX Antenna C++ engine
If your project uses customized FIX protocol definitions, you may convert them into FIXDIC format by using the utility “<path>\QFAdaptor\tools\xml_dict_conversion\dict_convert_for_engine_runtime.cmd”.
Pass the path to QuickFIX XML in the “input_file” parameter, and the path to the output file in the “out” parameter.
The produced XML file should then be mentioned in qfa.adaptor.properties file like below:
The same identifier (e.g. FIXcustom) will be used later in a session configuration file to specify that this particular session is using the FIX dialect, for example consider example.qfa.sessions file with following seting:
Creating Messages in C++ using customized FIX dictionaries
The following are examples of how to create messages using custom dictionaries. The syntax is different compared with QuickFIX.
Example 1. Creating an ExecutionReport message using the session’s FIX dictionary. Depending on what was configured for this session it might be a custom dictionary.
Example 2. Creating an ExecutionReport message using the FIXcustom dictionary configured in qfa.adaptor.properties file.
Example 3. Creating an ExecutionReport message using the FIXcustom dictionary configured in qfa.adaptor.properties file and C++ classes generated for this dictionary. See the following chapters for more info:
Generate Message Classes that bind to Custom FIX Protocols and New C++ namespace for custom FIX protocols
5. Converting customized QuickFIX protocol dictionaries for CPP code generator
Use the utility “<path>\QFAdaptor\tools\xml_dict_conversion\dict_convert_for_cpp.cmd” to convert QuickFIX XML definition into XML format suitable for further use with CPP code generator tool. This .CMD file is an example how to invoke the conversion tool.
6. Generating C++ business objects for standard or customized FIX protocol versions
Note: the CppGenerator.exe application is a Windows executable. When using the Linux version of the QF adaptor package, please unpack it on Windows and run the tool there.
Alternative 1. QuickFIX dictionary XML to CPP conversion
This method is the recommended way for generating CPP classes, it uses QuickFIX dictionaries as the source.
- Go to <path>\QFAdaptor\tools\cpp_code_generator\quickfix-dict folder
- Copy FIX40.xml, FIX41.xml, FIX42.xml, FIX43.xml, FIX44.xml, FIX50.xml, FIX50SP1.xml, FIX50SP2.xml, FIXT11.xml from quickfix/spec folder of your QuickFIX/C++ distribution to quickfix-input folder.
- Add any custom dictionary files you would like to convert to the quickfix-input folder
- Edit the quickfix-to-qfa-to-cpp.cmd file if any custom XMLs are used. Typically you would replace one of the existing FIXnn files with a custom one. Please refer to the following chapter if you would like to keep the base FIXnn version untouched and see your custom FIX protocol as a separate version of FIX protocol with new C++ message classes for business messages: Generate Message Classes that bind to Custom FIX Protocols
- New C++ namespace for custom FIX protocol
- Run quickfix-to-qfa-to-cpp.cmd command (on Linux use the .sh script)
- Copy the contents of generated “qfa” folder to <path>\QFAdaptor\include\qfa. This will overwrite existing files in this folder.
Alternative 2. FIX Antenna XML to CPP conversion
This method is recommended in the case when one wants to generate the C++ classes for business messages directly out of the FIX Antenna FIXDIC XML dictionaries rather than out of the QuickFIX dictionaries.
The business message C++ classes can be generated from FIX Antenna ™ dictionaries using the <path>\QFAdaptor\tools\cpp_code_generator\qfa-generate.cmd utility (or .sh script on Linux). This command file can be further modified by the user who wants to produce the classes for customized FIX protocols. For example, consider changing the following command line in this .cmd file:
and replace the text
fixdic-input\fixdic44.xml with a path to a custom FIX protocol definition. Such a definition can be produced from QuickFIX XML, refer to this chapter for the instructions: Converting customized QuickFIX protocol dictionaries for CPP code generator.
Note that the XMLs for all the FIX versions should be passed to this utility for processing at once (i.e. all files to be passed in the single command line, the code generator is not to be invoked for one individual file) because the code generator has to collect the definitions from all versions of the files to create consolidated lists in output files. This includes definitions for FIX tag numbers, message field values, etc.
After running the command, the “qfa” folder with the .H files is created. Copy the contents to the qfa folder located at: <path>\QFAdaptor\include\qfa
Generate Message Classes that bind to Custom FIX Protocols
When custom FIX protocol XML dictionaries are used, it may be desired to generate CPP message classes that will support the custom fields and groups defined in that dictionary. Then it will be possible to access these fields using get/set methods, for example, message.get( FIX42::MyNewField ).
In contrast to standard FIX 4.x and 5.x protocols, the custom protocols are loaded from XML and registered in the FIX Antenna engine and QFA adaptor. The message classes need also to know how to find the custom dictionary when the message object is created.
The custom FIX protocols are defined in qfa.adaptor.properties file in QFA.CustomVersion… properties. Refer to the chapter for more info: 4. Converting customized QuickFIX protocol dictionaries for use with FIX Antenna C++ engine. The custom protocol is identified by an ID, which is a string, e.g. “CustomFIX44”.
In order to pass this information to the CPP code generator, the “customFIXVer” attribute should be specified for the XML dictionary file that is passed to the tool in <path>\QFAdaptor\tools\cpp_code_generator\quickfix-to-qfato-cpp.cmd:
where MY_Custom_FIX44 is the name of the custom protocol defined in qfa.adaptor.properties file.
New C++ namespace for custom FIX protocols
By default, the business message C++ classes are created in FIXnn namespace which corresponds to the FIX base protocol version taken from the XML. If you’d like to place your customized protocol classes into a separate distinct namespace, pass the XML file to bin\CodeGenerator.exe command as follows:
As long as the MessageCracker class cannot distinguish between the base FIX version and your custom version since the BeginString field of the message will contain the base FIX version number, you would have to do the message class conversion on your own, for example, consider modifying
<path>\QFAdaptor\include\qfa\MessageCracker.h like follows:
7. Converting existing B2BITS FIX protocol customizations into QuickFIX C++ business objects
B2BITS can provide you with FIX protocol customizations used to connect to various destinations. Let’s consider MICEX exchange as an example. There will be the micex_fix.xml file which defines additional fields used in some FIX messages. This file is to be mentioned in QFA.CustomVersions property of qfa.adaptor.properties file.
In order to obtain the C++ classes for customized business messages follow these steps:
- Merge the micex_fix.xml customization with the base protocol, for example FIX44. Use the <path>\QFAdaptor\tools\xml_dict_conversion\dict_merge.cmd command line to do the merging.
- Take the merged XML file and follow the instructions specified in chapter Generating C++ business objects for standard or customized FIX protocol versions
APPENDIX A. Configuration Reference
Also refer to the latest version of documentation on the B2BITS web site: engine.properties or documentation in your FIX Antenna™ distribution: <path>\B2Bits\FIX Antenna C++\v22.214.171.124\doc\index.html
The corresponding FIXEdge parameters are described in this guide.
List of custom FIX protocol IDs (ID is an arbitrary string). This is a comma-separated list
Base FIX version of customprotocol. Required
QFA.CustomVersion. .<Custom FIX ID>.AdditionalFieldsFileName
XML file that provides protocol customization. If a relative path is specified, the root folder is taken from the engine.properties EngineRoot setting
|Log.Device||File Console||Target devices|
Turns on/off logging on the debug level
Turns on/off logging on the notice level
Turns on/off logging on the warning level
Turns on/off logging on the error level
Turns on/off logging on the fatal level
|Log.Cycling||false||Turns cycling on/off.|
Number of repeating records to be placed to log before cycling is started.
Number of repeating records to be accumulated (hidden) before writing the "cycle record" to the log.
Multiplier for the Block Size. If BlockSize number of messages is accumulated and the same message still appears then next BlockSize is calculated as the previous one multiplied by Multiplier.
File name. If more than one category uses files with the same name the same file will be used simultaneously.
If true then file will be recreated on each start. If false then new records will be appended to the current file.
If set to true then the buffer is flushed after each logging call. If set to false then flush is not called. Setting to true decreases program performance; setting to false increases a risk of record loss in the event of program failure.
Note that this configuration file uses a syntax which is close to that of the FIXEdge product. This is helpful when someone wants to migrate from QuickFIX to FIXEdge. The corresponding FIXEdge parameters are described in "FIX Edge - AdminGuide.html" available in the FIXEdge product installation.
|QFA.Sessions||This parameter determines the names of FIX session-acceptors. For each such a session it is necessary to define the parameters described below. The format is 'session.X.ParameterName' where 'X' is the name of session.|
|QFA.Session.<Name>.Version||FIX protocol version. Allowed values are FIX40, FIX41, FIX42, FIX43, FIX44, FIX50, FIX50SP1, FIX50SP2 or custom protocol names as specified in qfa.adaptor.properties file|
|QFA.Session.<Name>.Username||Username for FIX Session authentication|
|QFA.Session.<Name>.Password||Password for FIX Session authentication|
SenderCompID (Assigned value is used to identify a firm sending message).
|QFA.Session.<Name>.TargetCompID||TargetCompID (Assigned value is used to identify a receiving firm).|
|QFA.Session.<Name>.Host||Network address of the computer, to which connection is established.|
|QFA.Session.<Name>.Port||Port's network number on the computer, to which connection is established.|
|QFA.Session.<Name>.HBI||60||Time interval (in seconds) between Heartbeat messages. The recommended value is 10 seconds for dedicated connections or private networks. Trading connections via the internet will require calibration. '0' means that no Heartbeat messages will be sent.|
|QFA.Session.<Name>.InSeqNum||0||The initial incoming sequence number. The first incoming message is expected to have the specified sequence number. The default value will be used when set to zero.|
|QFA.Session.<Name>.IntradayLogoutTolerance||false||An option not to reset sequence numbers after a Logout. The party sending a Logout should initiate session recovery by sending a Logon message with SeqNum = + 1; expecting reply Logon withSeqNum = + 1. If a gap is detected, standard message recovery or gap filling processes arise. This property overrides the 'IntradayLogoutTolerance' property in 'engine.properties' for this session. Note : The default value is taken from engine.properties|
|QFA.Session.<Name>.OutSeqNum||0||The initial outgoing sequence number. The first outgoing message will be sent with the specified sequence number. If '0' then the default value is used.|
|false||When true, application messages will be rejected, when session unable to send them during specified period or after being disconnected.|
|QFA.Session.<Name>.StartTime||Local time to start the session (HH:MM). If the start-up time is greater than the specified value then the session will be started immediately. Note: this property is optional.|
|QFA.Session.<Name>.TerminateTime||Local time to terminate this session (HH:MM). If the start-up time is greater than the specified value then the value will take effect. Note: this property is optional.|
|QFA.Session.<Name>.StartTimeUTC||Start time in UTC|
|QFA.Session.<Name>.TerminateTimeUTC||Terminate time in UTC|
|QFA.Session.<Name>.SourceIPaddress||localhost||The expected value of the source IP address. If the real value is not equal to the expected one then the session is disconnected without sending a message and an error condition is generated in the log output.|
|If set to true and an attempt to connect fails, QFA adaptor will continue to ask the FIX Engine to establish the connection until it is successfully done.|
|If set to false then session is removed from the list of sessions after successful disconnection. If set to true then it will be recreated after disconnection. Note : recreation will take place only if disconnection is initialized by the counterparty.|
|QFA.Session.<Name>.ReconnectInterval||30||Time interval at which the ReconnectOnLogon/Logout attempts will be made for session initiators. For acceptors it is always set to 0 meaning to repeat immediately. So for example an acceptor with RecreateOnLogout=true is reacreated and is ready for a new connection right after the logout.|
Extends the session connection retry mechanism in the FIX Engine to the logon attempts. The engine will try to establish a connection if the remote endpoint is not available. Without this settings, the engine reconnects only when an already established session breaks. The number of retry attempts is specified in the Reconnect.MaxTries setting of the engine.property file. The time interval is set by the Reconnect.Interval property in the same file.
With this setting enabled, the connection may switch to backup connection at the logon time, if the primary endpoint is not available.
|QFA.Session.<Name>.Protocol||FIX_TCP||Specifies the underlying protocol of session <Name>. Values: FIX_TCP, FIXT11_TCP. Not required for sessions based on FIX_TCP.|
Specified default application protocol of custom sessions. Values: FIX40, FIX41, FIX42, FIX43, FIX44, FIX50, FIX50SP1, FIX50SP2, FIXT11.
Required only for sessions that bases on FIXT11_TCP.
|QFA.Session.<Name>. SenderLocationID||FIX tag 142 - assigned value used to identify specific message originator's location (i.e. geographic location and/or desk, trader).|
|QFA.Session.<Name>. TargetLocationID||FIX tag 143|
This parameter allow to automatically resolve sequence gap problem. When mode is ON session uses 141(ResetSeqNumFlag) tag in sending/confirming Logon message to reset SeqNum at the initiator or acceptor.
"0" - Disable ForceSeqNumReset mode
"1" - Enable SeqNum reset at first time of session initiation
"2" - Enable SeqNum reset for every session initiation
|false||Perform FIX session sequence numbers at the scheduled session’s start time (do so when the session happens to be still alive at the scheduled time)|
|QFA.Session.<Name>. IntradayLogoutTolerance||true||If true, don’t reset sequence numbers on logout|
|QFA.Session.<Name>. KeepConnectionState||false||When true, primary to backup (and back) connection switching continue using existing message storage|
EVEN – use a pool of worker threads for network I/O
AGGRESSIVE_SEND_AND_RECEIVE – use dedicated thread for network I/O to achieve a minimal latency. It is set to true by the ThreadedSocketAcceptor/Initiator automatically, but may be overridden in the configuration file
|StorageType||persistent||Type of the message storage to use. persistent – disk storage transient – in-memory storage Appropriate value is chosen by the FileStore/MemoryStoreFactory, but may be overridden in the configuration file.|
1 - NONE
|QFA.Session.<Name>. TcpBufferDisabled||false||If true, the Nagle algorithm on TCP/IP connection is disabled to achieve the minimal latency of message sending. It is set to true by the ThreadedSocketAcceptor/Initiator automatically, but may be overridden in the configuration file|
|This parameter allows to resolve ‘seqNum too low’ problem at logon. When true - session continues with the received seqNum.|
|QFA.Session.<Name>. Backup.Host||Host name to be used for a backup FIX connection (valid for session initiators)|
|QFA.Session.<Name>. Backup.Port||Port number to be used for backup FIX connection (valid for session initiators)|
|QFA.Session.<Name>. Backup.HBI||Backup session setting.|
|QFA.Session.<Name>. Backup.SenderSubID||Backup session setting.|
|QFA.Session.<Name>. Backup.TargetSubID||Backup session setting.|
|Backup session setting.|
|Backup session setting.|
|Backup session setting.|
|Backup session setting.|
|QFA.Session.<Name>. Backup.ForceReconnect||Backup session setting.|
|Backup session setting.|
|When true, automatic switch mode is enabled. By default automatic switch mode is disabled.|
|QFA.Session.<Name>. Backup.EnableCyclicSwitchBackupConnection||When true, connection will be switched from primary to backup and back until connection will be established.|
backup - The session connects via backup connection
|QFA.Session.<Name>.CustomLogonFileName||Path to the file containing FIX Logon message that will be sent to the counterparty when initiating the connection. The message is in binary format. If a relative path is specified, the root folder is taken from the engine.properties EngineRoot setting|