Imported from previous forum
How efficient is it to have a FIX Engine that has a Fault Tolerance Mechanism?
> How efficient is it to have a FIX Engine that has a Fault Tolerance Mechanism?
>
What specific mechanisms are you referring to?
FIX, the protocol itself, allows for a variety of fault tolerance mechanisms to be implemented by a good engine at the session layer including:
- Two Way Reliable Delivery / Recovery
- Determination of missing messages.
- Ability to recover missing messages.
- Ability to determine if a message was resent
at the session layer and/or the application
layer.
When used in conjunction with a reliable network transport such as TCP, FIX is very fault tolerant from a session layer protocol perspective. In addition, a FIX engine can be designed such that persistence of messages can be distributed over multiple systems, giving the FIX solution fault tolerance in the event of a system failure. We have implemented a RAID based solution which offers high degree of system availability where FIX is used for mission critical applications such as an order system.
If done properly, it can be very effecient such that next to no performance degradation is seen.
Peter Mellquist
Watcher Technologies
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> How efficient is it to have a FIX Engine that has a Fault Tolerance Mechanism?
I am assuming by this that you mean fault tolerance at a systems level. The FIX Protocol itself, as has been stated, does a fine job keeping both sides of a connection in sync in case of network failure. But that does no good if your only FIX engine goes up in smoke.
At a systems level, the quality of fault tolerance can dictate the performance impact. In general, while some fault tolerance you can get without significant performance impact, the higher levels of fault tolerance often involve more performance impact.
One can build in more fault tolerance by mirroring critical data on at least one other component, which hopefully has independent failure modes. One can go to all kinds of extremes to isolate failure modes, some being common sense and others being quite expensive. Mirroring to two disks in the same machine puts one at risk for the machine being damaged (i.e. power supply surging) and destroying both disks. Two machines on the same power strip puts one at risk for a circuit breaker popping or that power strip coming unplugged. Two machines with isolated power, but next to each other could put one at risk if a sprinkler head above them breaks. Two machines in different buildings in the same city puts one at risk to natural disasters.
The next issue is how that mirroring occurs. Just drop copying data as business transactions happen does allow for some data loss, as data in flight from the primary to the backup could be lost when the primary dies. This may mean a (hopefully small) sequence number mismatch with the client, and a (hopefully small) number of duped or dropped trades/orders. For some firms, this is acceptable risk.
One can go a step farther by requiring data to be committed as transactions to the backup before relaying that data to the FIX client or the internal business processing logic. This closes the gap and prevents the in-flight data loss happening above, but it comes at a price in terms of performance. It almost certainly will add latency, and it might or might not impact throughput. Committing transactions to one machine across a 100BaseT LAN adds one level of latency. Committing across a T1 to a backup site 1000 miles away can add more latency and can start imposing throughput bottlenecks.
> How efficient is it to have a FIX Engine that has a Fault Tolerance Mechanism?
>
There are some fix engines that will, in an attempt to improve throughput (messages/sec) and reduce latency, store the messages that they send asynchronously. In effect, those engines may often send messages before storing them. If the engine crashes while there are several message being sent, it is very possible that a message has been sent, but it has not been stored. The engine may not be able to find all messages to respond correctly to a resend request message. It could be execution reports, or orders, that get lost.
You should be aware of what you are buying and how this sort of persistence is handled.
Buying an engine that is "fault tolerant", may cause latency if it is storing every message before sending it. During peak times, this could become costly. In addition, storing the messages can become slower at certain levels of volume.
Hope this helps.
-Will Walter