FAQ

Is FIXP a synchronous or asynchronous protocol?

In order to optimize performance, FIXP is asynchronous. In other words, there is no blocking mechanism in the session protocol that prevents sending another application message while waiting for a previous response. Of course, applications can limit themselves to only process one message at a time if they so choose.

Does FIXP have a feature for message priority?

Individual messages are not assigned a priority. However, FIXP supports multiplexing of flows on a shared transport. Applications can prioritize handling of messages on one flow over another, if they wish.

How can a receiver detect sequence number gaps when sequence numbers are implicit for application messages?

First, consider the cases where sequence numbers are explicit in FIXP:

• Every datagram over UDP
• At every heartbeat interval, which will likely be much more rapid than FIX hearbeats in the past. (NASDAQ is not FIXP but similar in principle - their heartbeat interval in in the realm of 100 ms.)
• When context switching on a multiplexed transport
• When switching from retransmission to real-time on a recoverable flow

So, it is only implicit without a context switch or idle period over TCP. But recall that TCP guarantees in-sequence delivery of packets to an application. That is why FIXP was designed to use implicit sequencing in that case -- it avoids duplication of effort at two layers of the stack.

If the transport delivers messages in sequence but the application drops them, that is an application layer problem and cannot be solved the session layer.

Does FIXP handle very large messages?

The design target for FIXP was small messages delivered very fast. However, the protocol has no specific limit on message size.

Does a system using FIXP have single point of failure?

Unlike some other communication protocols, FIXP does not require a broker or other middleman between endpoints. (This also contributes to low latency, since a message does not take extra hops for delivery.)