[This message was posted by John Harris of BondMart Technologies, Inc. <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/831d9875 - PLEASE DO NOT REPLY BY MAIL.]
I have a question on this topic for High Frequency Trading Working Group purposes, if not of more general applicability... If I understand this question correctly, the market data gateway is trying to keep track of order book state. That strikes me as the wrong approach. I would prefer that the market data gateway help me, as client, construct my own notion of order book state, and otherwise get out of the way. If it sends me Side, Instrument, Price, Quantity, and some form of guaranteed-to-be-incrementing identifier, I can construct and maintain my own notion of the order book. Because of the incrementing identifier, I will know that lower numbers represent older orders - thus it is easy for me to rank orders first by price and then by age. As orders expire, fill, or are cancelled, the gateway just needs to tell me that, referencing the same identifier. If the gateway plays the order-book-construction game, too, then we have three versions of reality instead of two: 1) The real state of the order book; 2) What the market data gateway thinks is the state of the order book; and, 3) What my app thinks is the state of the order book. Why not get rid of the middleman, so to speak? Sorry if I am missing something... Best, John > The incremental instructions within a single MDIncGrp should not be applied > in parallel but sequentially, i.e. you only need to make sure that the > deletion of row 3 comes first, followed by the add for row 5. Row 5 is empty > after the first instruction, i.e. it is not an update. > As a side note, when best prices shift it is important that you send the > instruction first that widens the spread to avoid the possibility of a > crossed book in between instructions of the same MDIncGrp, even though a user > should not take any trading action prior to having processed all instructions > of one MDIncGrp (but you cannot rule it out). > Regards, > Hanno. > > > Hi, > > > > I'm in the process of developing a market data gateway. When implementing > > the depth (restricted to several rows in a book Market By Order) I have a > > concern in the following scenario. > > > > - Actual book is beyond the viewable depth (say depth shown out side is 5 > > and there are 10 entries) > > - An entry is deleted from the viewable depth (say the 3rd order is > > canceled) > > - The gateway should send the deletion update for the 3rd row > > - Then an update should be sent to lift up the entry which was at the 6th > > position as an add to the client's book (to maintain the depth) > > > > My concern is: > > - Do we pack two MDEntries (add and delete) within the same Incremental > > Refresh (NoMDEntries = 2)as this scenario can be considered as a single > > transaction? > > - OR do we send separate Incremental Refresh for delete and add of entries > > (NoMDEntries = 1 in each)? > > > > Please provide the best way of implementing the above scenario (according > > to the FAST standards) > > > > Thanks a lot. > > Sajith > > [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.
