OnixS C++ FIX Engine  4.10.1
API Documentation
Frequently Asked Questions

A: You can use OnixS::FIX::Session::inSeqNum and OnixS::FIX::Session::outSeqNum members to set the start sequence numbers before establishing the session. For more information, take a look at Message Sequence Numbers topic.

A: You should define and use the corresponding XML-based FIX Dictionary description. For more information, take a look at FIX Dictionary topic.

A: When the response on the Test Request <1> message is not received during HeartBeatInt, the FIX Connection is considered lost. Session-acceptor changes its state to OnixS::FIX::Session::LOGON_IN_PROGRESS in such a case. Session-initiator changes its state to OnixS::FIX::Session::RECONNECTING and tries to restore the FIX Connection pre-configured number of times in pre-configured interval (using the binary exponential back off algorithm). Please note that FIX Engine handles sending of Test Request messages (when it is needed) automatically. For more information, take a look at Complete Reference of Configuration Settings topic.

A: Take a look at Connecting using Custom Logon Message topic.

A: The reason of this error is the different default current folder for Windows Service and Windows application. By default, the current directory for your Windows service is the System32 folder. To solve this issue, specify the full path to the persistent storage folder, using the Log.Directory setting.

A: You can use OnixS::FIX::Session::senderSubId, OnixS::FIX::Session::targetSubId, OnixS::FIX::Session::senderLocationId, OnixS::FIX::Session::targetLocationId methods of the OnixS::FIX::Session class.

A: When does the license expire OnixS::FIX::Exception, that is thrown during the call of the OnixS::FIX::Engine::init method? For more information read Licensing topic.

A: Yes. Override OnixS::FIX::ISessionListener::onInboundSessionMsg virtual member, and you'll be able to check all session-level messages including Logon and Logout.

A: We would suggest the following approach:
  1. When OnixS::FIX::ISessionListener::onReceivedBytes is called, the T1 timestamp is recorded and the counter is incremented.
  2. If OnixS::FIX::ISessionListener::onReceivedBytes is called again the counter is incremented again.
  3. When OnixS::FIX::ISessionListener::onInboundApplicationMsg or OnixS::FIX::ISessionListener::onInboundSessionMsg is called the T2 timestamp is called and the counter is analyzed.

    If it is 1 then the inbound latency is equal to T2-T1. If it is greater than 1 it means that there was TCP fragmentation so the latency cannot be calculated properly. If it is 0 it means that more than one FIX messages were received in one IP package and the latency cannot be calculated properly. In any case the counter should be set back to 0. Please also take the look at the Latency Sample from our distribution package.

A: The reason of this warning is the following: Due to the design of the FIX protocol, the FIX repeating group cannot be parsed properly without the additional information that describes its structure. This is a well-known feature/flaw of the FIX protocol - and is applicable to any software that parses FIX repeating groups. If the FIX destination you work with uses non-standard (custom) fields in the repeating group then the FIX Engine needs the corresponding XML-based FIX Dictionary description file. So you would need to specify the FIX Dictionary description file to use during the FIX Engine initialization and use the Dictionary Id instead of FIX Protocol version in your code. FIX Dictionary also helps to validate FIX messages. More information could be found in the Editing Dictionaries Descriptions topic.

A: Please use the SessionScheduler class, there is the OnixS::FIX::Scheduling::SessionConnectionSettings class which provides the OnixS::FIX::Scheduling::InitiatorConnectionSettings::addCounterparty method to specify a backup server. More information could be found in the Scheduling Sessions for Automatic Connection topic.

A: You can specify different keys for the sessions with the same SenderCompID and TargetCompID. Please see parameter customSessionKey of the OnixS::FIX::Session class constructor.

A: To control tags order you need to create a custom dictionary and describe all tags in a Message or Repeating group in the necessary order with the override mode. More information could be found in the Editing Dictionaries Descriptions topic.

A: Each session occupies system resources (Threads, File descriptors, etc.). Each operating system has a limit of system resources, so if you achieve this limit then you cannot create more FIX sessions. In order to create the maximum amount of FIX sessions you can use the OnixS::FIX::ThreadingModel::ThreadPool mode, and OnixS::FIX::SessionStorageType::MemoryBased session storage type.

A: This exception means that the specified double value cannot be represented as the Decimal one because of the mantissa part of decimal will be very big and overflowed. In order to avoid this you can specify the precision parameter of the OnixS::FIX::FieldSet::set method. Detailed information about reasons of such issues you can find on the Manipulating Real Numbers topic. We recommend you to use the OnixS::FIX::Decimal class instead of raw double values to avoid such issues and improve performance.

A: When the OnixS::FIX::Session::logout method is called and the FIX connection is closed by the Logouts exchange the FIX Engine waits for closing the TCP connection and internal network components during the internal timeout (30 sec). If the closing process is not finished during the timeout then the mentioned internal warning is reported to the log. This can be when OnixS::FIX::ISessionListener::onInboundApplicationMsg or OnixS::FIX::ISessionListener::onInboundSessionMsg callback is blocked for some reasons. Session event handling is a synchronous operation. For this reason, it is recommended not to perform time-consuming tasks inside event handlers, please see the Listening to Session Events topic.

A: Tick-To-Trade latency includes the following:
  1. Market Data update on the exchange side (T1).
  2. Receiving the Market Data message.
  3. Processing the Market Data message.
  4. Sending the Order.
  5. Executing the Order on the exchange side (T2).

    Therefore, the clear Tick-To-Trade latency = T2 - T1. However, on the client side, you cannot get T2 and T1 properly. You can get only the timestamp when you receive the Market Data (OnixS::FIX::ISessionListener::onInboundApplicationMsg) and the timestamp when you send the Order (OnixS::FIX::ISessionListener::onMessageSending).

A: This is the expected behavior and this is by design. The buffer, in the OnixS::FIX::ISessionListener::onMessageSending callback, is a mutable buffer and can be used for low-level modifications of outgoing messages right before sending. For OnixS::FIX::Message class objects, it is a safe operation because it affects the outgoing serialized buffer only and does not affect the initial Message object. However, a OnixS::FIX::FlatMessage class object represents the already pre-serialized buffer in itself, so the modification of this buffer in the OnixS::FIX::ISessionListener::onMessageSending callback can corrupt the initial FlatMessage object, so this buffer is not passed at all.

A: It looks like a configuration-related issue indeed (either on yours or counterpart side). The error message means that the TCP connection was established and the initial Logon (MsgType=A) FIX message was sent, but after that, the TCP connection was closed by the counterparty. So we would recommend contacting your counterparty FIX Support Team and provide them with your FIX message log file (*.summary) and ask them what you need to change (if anything) in your initial Logon (MsgType=A), in order to establish the FIX Session successfully. Perhaps they need to update the configuration settings on their side, in order to accept your FIX connection (e.g. update login/password settings or the expected source IP address).

A: The reason of this can be the following:
  1. The way to get timestamps for the FIX Engine *.summary log and the Wireshark is different. FIX Engine uses the fastest, but not the best accuracy way. Wireshark uses timestamps are taken by the pcap library and the actual way, which is used to get timestamps, depends on your system, but definitely, it can be different. Moreover, there can be a timestamp drift in Wireshark, because by default it is synchronized with the system clock only once, at the beginning of the capture.
  2. These timestamps are taken at different time points. FIX Engine takes sending timestamps before writing to the session storage and before the socket send call. Receiving timestamps are taken after the socket receive call and after the deserialization. Wireshark takes sending timestamps after a message is sent. Receiving timestamps are taken right after a message is received. Therefore, the delay between Wireshark and FIX Engine timestamps can include the latency of the session storage, the latency of the deserialization process and the latency of the TCP stack.

A: In accordance with the FIX protocol, an application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Therefore, such garbled messages should cause the sequence gap and the counterparty should resend messages afterwards.

A: The issue is related to the Dual ABI mismatch. The reason for this can be the following:
  1. You use an incompatible FIX Engine package for this OS and GCC version. On each particular OS and GCC version, one needs to use a corresponding package.
  2. You use a non-standard (non-system) GCC version. We are using the Red Hat Developer Toolset for builds with up-to-date GCC versions on CentOS/RHEL. We highly recommend using DTS as a modern and easy-to-use way, which does not affect the system GCC version and tools. DTS compiler uses the old ABI, but if your compiler is configured with new ABI, then to resolve the issue you need to add the D_GLIBCXX_USE_CXX11_ABI=0 flag to your build system. However, it would be easier just to use the DTS compiler.

A: Please see the Memory Consumption topic.

A: Please see the Memory Consumption topic.

A: You can use the OnixS::FIX::Timestamp constructor, which accepts total nanoseconds since the Unix epoch, to create the OnixS::FIX::Timestamp from the Unix timestamp. You can use the OnixS::FIX::Timestamp::toUnixNanosecondTimestamp() method to convert the OnixS::FIX::Timestamp to the Unix nanosecond timestamp.

A: In the C++17 standard, the std::string_view class was introduced, which is mainly similar to the OnixS::FIX::StringRef type. It is more clear, safe, effective, and less error-prone to use the standard class from the standard libraries. Therefore, since the 4.7.0 version, the alias was added for C++17 users to use the standard library std::string_view class instead of the OnixS::FIX::StringRef class. The package built for the C++14 standard and below uses the OnixS::FIX::StringRef class. Therefore, when one uses such a package with the C++17 standard, all methods involved the OnixS::FIX::StringRef type will produce linker errors since the API interface uses the std::string_view class, but the implementation uses the OnixS::FIX::StringRef class. One should use the package built for the same C++ standard used in the application to avoid such issues.