Frequently Asked Questions

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 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), to establish the FIX Session successfully. Perhaps they need to update the configuration settings on their side, to accept your FIX connection (e.g., update login/password settings or the expected source IP address).

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:

EngineSettings settings = new EngineSettings()
{
    SendLogoutOnException = true
};
Engine.Init(settings);

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.

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 FIX Dictionary description.

See also: FIX Dictionary.

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 message is not received during HeartBeatInt, the FIX Connection is considered as lost. FIX Session-Acceptor changes its state to AwaitLogon. FIX Session-Initiator changes its state to Reconnecting and tries to restore the FIX Connection pre-configured number of times in pre-configured interval. Please note that OnixS .NET FIX Engine automatically handles sending of Test Request messages (when needed).

See also: Session States.

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

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

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 for 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 StorageDirectory setting.

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

A: You can use a corresponding property exposed by Session class like SenderSubId and TargetSubId.

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.

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

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

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

A: We suggest the following approach:

  • When BytesReceived is called, the T1 timestamp is recorded, and the counter is incremented.
  • If BytesReceived is called again, the counter is incremented again.
  • When InboundApplicationMessage or InboundSessionMessage is called the T2 timestamp is recorded, and the counter is analyzed. If it is one, then the inbound latency is equal to T2-T1. If it is greater than one, 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 a look at the Latency sample from the FIX Engine distribution package.

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: It is not correct to compare Wireshark timestamps with FIX .summary file timestamps. They are computed using different timers, and there is no reliable way on Windows to get precise microsecond timestamp.

Q: Why do I receive the "Garbled message received. The invalid number of repeating group instances" warning through even if I see that this number is correct?

A: The reason for 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 applies 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 FIX Dictionary description. So you would need to specify the FIX Dictionary description to use during the FIX Engine initialization and use the Dictionary instead of the FIX Protocol version in your code. FIX Dictionary also helps to validate FIX messages.

See also: Dictionary Description.

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

A: Please use the Scheduler class, there is the SessionConnectionSettings class that provides the Counterparties property to specify a backup server.

More information could be found in the Scheduling Session 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 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.

See also: Dictionary Description.

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

A: This is the expected behavior. To decrease the receiving latency (exclude the logging latency from the receiving latency), incoming application FIX messages are logged after the InboundApplicationMessage callback.

Q: How can I configure the FIX Engine to create the maximum amount of FIX sessions?

A: Each session occupies system resources (for example, threads, file descriptors). Each operating system has a limit of system resources, so if you achieve this limit, then you cannot create more FIX sessions. To create the maximum amount of FIX sessions, you can use the MemoryBasedStorage type.

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

A: When the Logout(bool) method is called, and the FIX connection is closed by the Logout message 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:

  • When InboundApplicationMessage or InboundSessionMessage 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 Session Events topic.
  • When a TCP connection cannot be closed during the timeout because of network related reasons. In this case, there should not be any adverse effects, and this warning is needed more for our internal debug purpose.

Q: How can I measure the Tick-To-Trade latency?

A: Tick-To-Trade latency includes the following:

  • Market Data update on the exchange side (T1).
  • Receiving the Market Data message.
  • Processing the Market Data message.
  • Sending the Order.
  • Executing the Order on the exchange side (T2).

Therefore, 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 (InboundApplicationMessage ) and the timestamp when you send the Order (MessageSending ).

Q: Why can I see a delay between Wireshark and FIX Engine log timestamps?

A: The reason for this can be the following:

  • 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 that are taken by the Pcap library and the way, that is used to get timestamps, 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.
  • 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 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: By 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 afterward.

Q: I'm now getting the following error: "System.TypeInitializationException: The type initializer for 'OnixS.Fix.FieldSet' threw an exception. System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.ObjectPool, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'". Am I missing something?

A: It looks like all necessary dependencies are not added to the project.

See also: Project Dependency Management.