OnixS C++ FIX Engine 4.13.0
API Documentation
Loading...
Searching...
No Matches
Frequently Asked Questions

  • Q: I need to continue the FIX session, starting from the specific message sequence number, but I have deleted the log files from the previous runs. How can I do this?
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.

  • Q: How can I customize OnixS C++ FIX Engine to work with non-standard FIX counterparties that employ user-defined fields and messages (use modifications of the FIX Protocol)?
A: You should define and use the corresponding XML-based FIX Dictionary description. For more information, take a look at FIX Dictionary topic.

  • Q: What is the default behavior of C++ FIX Engine in case a Test Request <1> message was sent to the counterparty, and the counterparty does not respond?
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.

  • Q: Why do I receive the "Invalid FIX Engine settings: Cannot open the persistent storage folder ('MsgStorage')" error, when I'm trying to run my FIX application as a Windows service? When I run my application as a standalone one, all work perfectly OK.
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.

  • Q: How will I know if I do not have the valid license file? What is a failure scenario/message for the Engine?
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.

  • Q: Is there any way to check whether Logon and/or Logout messages are received?
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.

  • Q: Why do I receive the "Garbled message received. Invalid number of repeating group instances" warning through even if I see that this number is correct?
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.

  • Q: How could I activate the automatic failover (backup session) functionality?
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.

  • Q: How to create multiple sessions with the same SenderCompID and TargetCompID?
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.

  • Q: How to control the order of the tags?
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.

  • Q: How can I configure the FIX Engine to create the maximum amount of FIX sessions?
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.

  • Q: Why do I receive the "Cannot transform Double value into decimal" exception, when I set a double value to a Message object?
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.

  • Q: Why do I receive the "Connection closing process is not finished after the internal timeout" internal warning when the OnixS::FIX::Session::logout method is called?
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.

  • Q: How can I measure the Tick-To-Trade latency?
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).

  • Q: Why is the outgoing buffer in the onMessageSending callback equals to NULL for FlatMessage objects?
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.

  • Q: I'm now getting the following error: Cannot logon: after sending the initial Logon message the telecommunication link error is detected (An existing connection was forcibly closed by the remote host). Could this be related to my setup?
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).

  • Q: Why can I see a delay between Wireshark and FIX Engine *.summary log timestamps?
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.

  • Q: Why do garbled messages not rise inbound events? Do I miss such messages?
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.

  • Q: Why do I receive linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace during building an application using the FIX Engine on Linux?
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.

  • Q: Why do I see a significant memory consumption when I receive large messages with many repeating groups? Why is this memory not released during the FIX connection lifetime?
A: Please see the Memory Consumption topic.

  • Q: Why do I see a significant memory consumption when I send messages at a high rate? Why is this memory not released during the FIX connection lifetime?
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.

  • Q: Why do I receive linker errors about undefined references to methods involving the std::basic_string_view(OnixS::FIX::StringRef) type when building an application for the C++17 standard and above?
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.