FIX Protocol
Exchange Implementation Drives Fast | FIX 5.0, One Year On | FIX Is All About the Network |
FIX Is All About the Network
Rising volumes, execution speeds have industry reexamining access strategies
November 19, 2007
Ten years ago, providers of FIX engines proliferated in response to broker-dealer demands, but that market shrank as users began to develop in-house engines. Now, with firms facing rapidly increasing volumes and execution speeds--and trading strategies such as statistical arbitrage and their associated latency problems--they are once again looking for new solutions.
Rising trade volumes have led the industry to take a fresh look at network access strategies such as the high availability (HA) system design protocol, included in many commercial FIX engines, which attempts to keep systems accessible during peak-demand periods. Rather than failing completely, fault-tolerant systems continue to operate at a reduced performance level.
In the early 2000s, vendors "were using basic IP fail-over mechanisms and installations with hardened caches so that the sell-side and buy-side engines could fail-over, and we were using network address translation," said Jim Northey, founder and principal of Chicago-based LaSalle Technology Group and co-chair of the FIX Protocol Ltd. (FPL) Americas regional committee. "If you were an exchange or a sell-side firm, you'd give up your" Internet protocol (IP) address and offload some fail-over responsibility.
"Now, things have progressed to the point where you have one IP address per FIX session," added Northey.
"You can have multiple boxes that share one IP address and redistribute data to a FIX engine farm," said Ryan Pierce, team leader of execution services at Lehman Brothers and a member of the FPL global technical committee governance board. "Even boxes designed to distribute HTTP Web connections can be, in some cases, used for FIX. But some are not designed around low latency and parameters need to be tweaked to improve TCP environments as opposed to Web environments where you're caching a lot of data."
The use of TCP-IP as a central store of FIX data to facilitate recovery may have limitations. "A number of transactions could potentially be lost in case of a failure," said Pierce. "For example, a trade sending a large number of transactions that is in flight might not necessarily arrive. That's a gap that needs to be examined."
How have demands for high availability affected FIX vendors? Steve Grossman, director of software at NYSE TransactTools, noted that the high-availability issue is not specific to FIX. "Companies have solved this issue in other places and should extend those solutions to their FIX applications. FIX should not dictate your HA strategy, rather it should be integrated into it. Fortunately, FIX plays well with many HA strategies due to its resend semantics."
Another approach that appeared in the late 1990s was load balancing, which spreads work among many computers to get optimal utilization and quicker compute times. How has it been affected by shifting market conditions?
For direct-market access, algorithmic and statistical arbitrage order flow "you wouldn't want multiple orders competing," said Pierce. "Multiple sessions all have to be monitored and supported and there may be per-session charges. But it's important that load balancing be dynamic. If we have four sessions to a counterparty, and if for some reason one goes down, you don't want one in four future orders to die."
Said Grossman: "You can't simply send the traffic across different connections and keep track of orders, cancels following orders, and the like."
