Message Receiving Latency

The overall latency of the message receiving consists of latencies of the following steps that are taken to receive and report an incoming message:

  1. The invocation of the operating system receive call. In practice, the latency of the system receive function can be about 5 .. 10 microseconds depending on the size of the received data, network workload, network software/hardware, etc. For example, you can decrease this latency using Solarflare network cards and the corresponding user-level TCP stack implementation called "Onload".
  2. Invocation of the BytesReceived event handler.
  3. Deserialization of the received bytes to the inbound message. The latency of this step depends on the MessageMode property. For the Message class, it is an expensive operation and can take a few microseconds depending on the message size. For the FlatMessage class, it is a cheap operation because an instance of this class represents the serialized buffer.
  4. Validation of the incoming message following validation settings (for FlatMessage instances only). Therefore, the configured validations affect the latency.
  5. Invocation of the InboundApplicationMessage or InboundSessionMessage event handlers.
  6. Writing data (the received FIX message, timestamp, sequence numbers, etc.) to the session storage. For a File-based Session Storage, it is an expensive operation, and it can take tens of microseconds. For an Async File-based Session Storage, it is far cheaper because the actual writing is performed in a separate thread. Lastly, for a Memory-based Session Storage, it is a very cheap operation because data is stored in the memory, not the file system. Please note that for session-level messages, the writing is performed before calling the InboundSessionMessage handler, but for application-level messages, the writing is performed after calling the InboundApplicationMessage event handler. The reason is to report application-level messages to the user immediately.