[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/c95dbad0 - PLEASE DO NOT REPLY BY MAIL.]
I might have misunderstood the question as I assumed an aggregated book and was referring to price levels. With individual orders, I just send them out and let the recipient figure out the book (order priority given by their relative position in the data stream), possibly using cloaking mechanisms to reduce the probability of identifying reserve orders, hidden orders etc. > 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.
