[This message was posted by Ryan Pierce of CME Group <[email protected]> to the "5.0 SP2 Feedback" discussion forum at http://fixprotocol.org/discuss/121. You can reply to it on-line at http://fixprotocol.org/discuss/read/1c584332 - PLEASE DO NOT REPLY BY MAIL.]
> I'd like to know if it's FIX compliant to implement application sequencing in > Order Routing systems? > > For example we have a trading backend which has several partitions, and we > need to send order into all the partitions. We are planning to initiate one > FIX session for sending orders into all the backend partitions, while for > each partition, we maintain a application sequence number. > > I'm just wondeing if this design is FIX compliant? This is quite an interesting topic, with a lot of history. Technically, the language of the spec forbids use of application sequencing for transactional messaging, like executions in response to orders. Its intended use is for pre-trade market data, post-trade reports, drop copies, etc. However, there has been an increasing need raised by a number of exchanges for the ability to use application sequencing for messages from exchanges to consumers. The issue is that a lot of exchange systems not originally built around FIX embed a sort of recovery mechanism and sequencing in their core matching engines, which may or may not be partitioned, and they run this in parallel with their native API's. And FIX has its own sequence numbers, which increment in each session. FIX recovery is based off of its own sequence numbers. So this means the exchange must expend the latency to commit FIX transactions to stable storage twice: once in the matching engine, and once at the FIX engine. This has two negative consequences: 1. The FIX connection will probably be slower than the native protocol. Customers using the native protocol can use the matching engine's sequence numbers for recovery. FIX messages must be committed to stable storage again, as FIX users will use FIX session recovery, not the native exchange sequence numbers and recovery protocol. 2. The FIX engine must be hardened against failure. If the FIX engine crashes, it must be able to recover its state, or it will result in an inability for the customer to recover state using in-band means. I recall Kevin Houstoun had proposed the concept of "Stateless FIX" that would make use of application sequencing for recovery. My understanding is that in cases where "Stateless FIX" would be employed, FIX engines would no longer need to store message state to stable storage. If a FIX engine crashes, the message store is lost, but this is not in any way a problem. The customer will use the FIX application sequencing mechanism to ask for exchange messages for each partition. This gets translated into the matching engine's native recovery protocol. I don't know if anything has happened regarding this. From what I understand, doing this would require: 1. FPL deciding to remove the language prohibiting application sequencing for transactional messages like order flow from exchange to client. Adding notes to the spec of how to use this in an exchage environment would be useful. 2. Adding the application sequencing fields on more messages, e.g. it is on Execution Report today (for drop copy purposes) but, I don't think, on Order Cancel Reject. There is work underway to create the concept of a Business Application Header, which could be added to all business messages and would contain certain fields; the application sequencing fields would be likely candidates for this. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
