Imported from previous forum
I have the following questions regarding market data messages:
A) When subscribing for Market Data ‘snapshot plus updates’ (i.e. SubscriptionRequestType (tag 263) set to ‘1’) are the messages expected from the server:
- A ‘Snapshot/Full Refresh’ message (MsgType = W) containing the snapshot information, followed by ‘Incremental Refresh’ messages (MsgType = X) whenever there are updates.
or
- An initial ‘Incremental Refresh’ message (MsgType = X) containing the snapshot information, followed by subsequent ‘Incremental Refresh’ messages as updates occur.
The problem with 1 is that the Snapshot message does not contain MDEntryID fields to which subsequent updates can refer. Is 2 the correct interpretation?
B) Multiple subscriptions for the same symbol for in given FIX session.
In order to simplify the subscription mechanism provided by the server I would like allow only one subscription for a given symbol. Is introducing this constraint FIX compliant? What is the recommended way to handle multiple subscriptions for the same symbol?
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
>A) When subscribing for Market Data ‘snapshot plus updates’ (i.e. SubscriptionRequestType (tag 263) set to ‘1’) are the messages expected from the server:
>
> 1. A ‘Snapshot/Full Refresh’ message (MsgType = W) containing the snapshot information, followed by ‘Incremental Refresh’ messages (MsgType = X) whenever there are updates.
>
> or
>
> 2. An initial ‘Incremental Refresh’ message (MsgType = X) containing the snapshot information, followed by subsequent ‘Incremental Refresh’ messages as updates occur.
The type of message you get in response is dictated by the MDUpdateType(265) specified in your Market Data Request. 0 = Full Refresh, which causes ‘Snapshot/Full Refresh’ messages to be sent, and 1 = Incremental Refresh, causing ‘Incremental Refresh’ messages to be sent.
> The problem with 1 is that the Snapshot message does not contain MDEntryID fields to which subsequent updates can refer. Is 2 the correct interpretation?
Both strategies are correct. The first strategy is wasteful on bandwidth, but designed so that clients can be truly stateless. Every time you get a message for a security, you throw out all the data you have for the security, and replace it with the contents of this message. This means that in a book of 20 bids and 20 offers, one market maker changing his quote will cause all 40 quotes to be sent again. Yes, it is wasteful, but it is also trivial for the recipient to display it as is is stateless.
The second strategy is designed to squeeze bandwidth as much as possible. By identifying each quote with an MDEntryID, you can change or delete one quote without having to redisplay all other quotes for that instrument. However it requires whatever is receiving the data to keep state of IDs and what quotes they represent.
> B) Multiple subscriptions for the same symbol for in given FIX session.
>
> In order to simplify the subscription mechanism provided by the server I would like allow only one subscription for a given symbol. Is introducing this constraint FIX compliant? What is the recommended way to handle multiple subscriptions for the same symbol?
Technically, the spec is flexible enough to allow for multiple subscriptions for the same symbol. However, nobody implements the full FIX application layer. People pick and choose what is right for their business and support just a subset of the spec. For instance, you don’t have to support both ‘Snapshot/Full Refresh’ and ‘Incremental Refresh’, you can support just the latter.
Also, consider the possibility that the request isn’t needed. Market Data messages can be sent “unsolicited” i.e. someone connects to one port and gets the top of book for all symbols, a different port is the full book for all symbols. This removes the burden from the client for having to keep a list of all tradeable instruments in order to display quotes, as well as solves the issue of what to do when an IPO starts trading.
We are only supporting requests with MDUpdateType = ‘Incremental Refresh’ and SubscriptionRequestType(263) = ‘Snapshot plus Updates’. The way we satisfy this request is to send an initial ‘Incremental Refresh’ message (MsgType = X) containing the snapshot information, followed by subsequent ‘Incremental Refresh’ messages (MsgType = X) as updates occur.
I wanted to confirm if this approach is correct since initally we were going to satisfy the request above by sending MsgType = W for snapshot information followed by MsgType = X with updates, which does not seem possible since MsgType = W does not return MDEntryID’s that can later be used to process updates.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> We are only supporting requests with MDUpdateType = ‘Incremental Refresh’ and SubscriptionRequestType(263) = ‘Snapshot plus Updates’. The way we satisfy this request is to send an initial ‘Incremental Refresh’ message (MsgType = X) containing the snapshot information, followed by subsequent ‘Incremental Refresh’ messages (MsgType = X) as updates occur.
>
> I wanted to confirm if this approach is correct since initally we were going to satisfy the request above by sending MsgType = W for snapshot information followed by MsgType = X with updates, which does not seem possible since MsgType = W does not return MDEntryID’s that can later be used to process updates.
You are most certainly correct. The language in the spec may be a little bit confusing.
MsgType=W is used in two cases.
-
SubscriptionRequestType = Snapshot. Since you are just displaying the state of the market at one point in time and will not update it, there’s no need for MDEntryID.
-
SubscriptionRequestType = Snapshot + Updates AND MDEntryType = Full Refresh. Here you must refresh every quote for a security every time anything changes, hence there is no need for an ID.
When SubscriptionRequestType = Snapshot + Updates and MDEntryType = Incremental Refresh, as you stated, you must always use MsgType=X for both the initial snapshot and any future updates.