[This message was posted by Sajith Premadasa of Millennium IT <[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/588db05a - PLEASE DO NOT REPLY BY MAIL.]
Thanks a lot Hanno for your feedback! And John, it's nice having your ideas here and I think the document "Recommended Practices for Book Management(2.00)" will answer some of your concerns. That's a very good guide on handling stuff in the FAST standard. I'm not sure whether this document is there for reference now (Someone please put a link here). Hanno, regarding your best prices approach, I think there is a separate implementation for the Top of Book in the above document to prevent such intermediate problems. I'd like more ideas/concerns on best practices of depth handling if anyone of you is interested discussing here. Thanks a lot again! Sajith > 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.
