forwardHigh Throughput Best Practices   Table of ContentGlossaryforward
Frequently Asked Questions

  1. Q: Why do I receive the "Cannot load assembly FixForge.dll or one of its dependency" error when I run my application?

    A: The reason of this error is the Visual C++ Runtime Libraries missing, please see Deployment.

  2. Q: Why I cannot use AnyCpu solution platform in my Visual Studio project with your library?

    A: In order to achieve the best performance and minimize latency, our FIX Engine library contains the native unmanaged code, which is platform depended, so there is need to compile the library specifying the concrete platform - x86 or x64.

  3. Q: Why I cannot open Windows Form or Controls in the Visual Studio designer for x64 sample projects?

    A: Visual Studio is a 32-bit process, and therefore can only execute 32-bit modules. While Visual Studio allows you to add a reference to a 64-bit assembly, it cannot actually JIT compile it to 64-bit and execute it in process. The workaround is to use the 32-bit DLL for form designer and change to the 64-bit DLL when the design is finished.

  4. 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. System error code = 10054). 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 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).

  5. Q: How can I configure FIX Engine to send a Logout message before terminating the FIX connection when the incoming message sequence number is less than expected?

    A: Please set the SendLogoutOnException configuration option to true. For example:

    C#
    EngineSettings settings = new EngineSettings();
    settings.SendLogoutOnException = true;
    
    Engine.Init(settings);

  6. Q: Is the OnixS .NET FIX Engine 100% managed code (MSIL-only, no native code)?

    A: No. OnixS .NET FIX Engine represent a mixed code assembly. To achieve the best performance and minimize latency we use unmanaged code in some mission-critical subsystems of OnixS .NET FIX Engine.

  7. 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 InSeqNum and OutSeqNum properties to set the start sequence numbers before establishing the session.

    See also:Message Sequence Numbers.

  8. Q: Why does my GUI application hang when I try to handle the Engine events?

    A: The most probable reason is that you are trying to update GUI controls directly from the event handler. It is necessary to use Control.Invoke instead.

    See also:Updating GUI Controls on Session event.

  9. Q:How can I customize OnixS .NET FIX Engine to work with non-standard FIX counterparties that employ user-defined fields and messages (use modifications of the FIX Protocol)?

    A: You need to define and use the corresponding XML-based FIX Dialect description.

    See also:FIX Dialects.

  10. Q: What is the default behavior of OnixS .NET FIX Engine in the case where 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 as lost. FIX Session-Acceptor changes its state to LOGON_IN_PROGRESS. FIX Session-Initiator changes its state to 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 OnixS .NET FIX Engine automatically handles sending of Test Request messages (when needed).

    See also:Reconnect.Attempts and Reconnect.Interval configuration settings.

  11. Q: How can I set SenderSubID and OnBehalfOfSubID fields in the Logon message?

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

  12. 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.

  13. Q: How can I set SenderSubID, TargetSubID, SenderLocationID, TargetLocationID, for all outgoing messages including session-level ones?

    A: You can use a corresponding property exposed by Session class like SenderSubID and TargetSubID.

  14. 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 the license expires EngineException is thrown during the call of the Init() method. See also:Licensing the Engine.

  15. Q:Is there any way to check whether Logon and/or Logout messages are received?

    A: Yes. Subscribe to the InboundSessionMsgEvent event and you'll be able to check all session-level messages including Logon and Logout.

  16. Q: How can I tell what the latency from the last byte on the wire to when I get the InboundApplicationMsgEvent?

    A: We would suggest the following approach:

    1. When BytesReceived is called, the T1 timestamp is recorded and the counter is incremented.
    2. If BytesReceived is called again the counter is incremented again.
    3. When InboundApplicationMsgEvent or InboundSessionMsgEvent 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.

  17. Q: Why do I see large delays between timestamps of FIX messages captured by Wireshark and corresponding timestamps of records in FIX .summary file?

    A: We have detected that it is not correct to compare Wireshark timestamps with FIX .summary file timestamps. They are computed using different timers and as we know there is no way on Windows to get precise microsecond timestamp.

  18. 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 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 Dialect description file. So you would need to specify the FIX Dialect description file to use during the FIX Engine initialization and use the Dialect Id instead of FIX Protocol version in your code. FIX Dialect also helps to validate FIX messages. More information could be found in the Dialect Description topic.

  19. Q: How could I activate the automatic failover (backup session) functionality?

    A: Please use the Scheduler class, there is the SessionConnectionSettings class which provides the Counterparties property to specify a backup server. More information could be found in the Scheduling Sessions for Automatic Connection topic.

  20. 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 Session class constructor.

  21. Q: How to control the order of the tags?

    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 Dialect Description topic.

  22. Q: Why can I see that my sent application messages are logged before the received application message?

    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 InboundApplicationMsgEvent callback.

  23. 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 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 ThreadPool mode, and MemoryBasedStorage type.

  24. Q: Why do I receive the "Connection closing process is not finished after 2 sec timeout" internal warning when the Logout() method is called?

    A: When the 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 InboundApplicationMsgEvent or InboundSessionMsgEvent handler 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 Subscribing 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.

  25. 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 (InboundApplicationMsgEvent) and the timestamp when you send the Order (MessageSending).

  26. 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 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.

  27. 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.