[This message was posted by Lalin Dias of Millennium Information Technologies <[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/a2974ae1 - PLEASE DO NOT REPLY BY MAIL.]
We are considering offering a stateless FIX connection to our matching engine. We already offer a regular FIX connection and a native connection. We could close the latency gap between the FIX and native connection if the FIX connection was stateless. We already offer application sequencing for post trade reports and have been considering extending it to the order entry connection. We did notice the wording in Volume 1 of the spec discouraging the use of application sequencing for order routing. What is the rationale for that? Application sequencing on an order routing connection seems like a reasonable option in a low latency environment. > > 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.
