OnixS C++ FIX Engine  3.24.0
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 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 describe 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 dialect 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: This is the expected behavior. In order to decrease the receiving latency (exclude the logging latency from the receiving latency), incoming application FIX messages are logged after the OnixS::FIX::ISessionListener::onInboundApplicationMsg callback.

A: Each session occupies system resources (Threads, File descriptors, etc.). Each operation 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::ConnectionMode::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 a 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 (2 sec). If the closing process is not finished during the timeout then the mentioned internal warning is reported to the log. This can be in the following cases:
  1. When OnixS::FIX::ISessionListener::onInboundApplicationMsg or OnixS::FIX::ISessionListener::onInboundSessionMsg callback is blocked. 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.
  2. When a TCP connection cannot be closed during the timeout by some network reasons (high-load, counterparty hang, etc.). In this case, there should not be any negative effects and this warning is needed more for our internal debug purpose.

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::SerializedMessage 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 SerializedMessage 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 to contact your counterparty FIX Support Team and provide them with your FIX messsage 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 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 in different timepoints. 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.