Market Data Full Refresh - Repeating Group for Symbol

, ,
1

Imported from previous forum

2

[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The Market Data Request message permits a single subscription to refer to multiple entries.

The Full Refresh message does not permit group of multiple instruments within on Full Refresh message.

This greatly reduces overhead in distributing market data in more bandwidth / #transaction per second applications, because batching of securities in one transmission is not provided.

For FIX 4.4, this could be addressed by:

  1. Breaking the Market Data Full Refresh Message by adding NoRelatedSym repeating group right after request ID.

  2. Adding a new message that is identical with Market Data Full Refresh Message with the exception of a adding the NoRelatedSym repeating group. If we were to choose this approach, we would most likely nest the Request ID field within the repeating group - to permit batching across subscription type.

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> The Market Data Request message permits a single subscription to refer to multiple entries.
>
> The Full Refresh message does not permit group of multiple instruments within on Full Refresh message.
>
> This greatly reduces overhead in distributing market data in more bandwidth / #transaction per second applications, because batching of securities in one transmission is not provided.

I think that there is a misunderstanding regarding the purpose of the Market Data Snapshot / Full Refresh message.

This message was NOT intended to conserve bandwidth. On the contrary, it is quite a bandwidth hog. Applications concerned with performance should use Market Data / Incremental Refresh.

The Snapshot / Full Refresh was designed exclusively to allow support for extremely simple, lightweight, totally stateless clients. When displaying a book, the ENTIRETY of the book for that symbol must be sent, regardless of what actually changed. For instance, if I’m just sending top of book, and the bid changes, I must send one message with the full symbol definition, the bid, and the offer. If I’m sending depth of book, and one price tier changes, I must resend the entire symbol, and ALL bids and offers.

While bundling multiple securities into one Snapshot / Full Refresh will certainly save bandwidth since it lowers the header length / body length ratio, a lot will be wasted by having to duplicate all non-changing data for each security. I think you’re using the wrong tool for the job. Once you pack multiple securities into one message and eliminate redundant info by requiring the client to keep state, you’ve essentially got the Incremental Refresh message.

The Incremental Refresh message was designed to be as bandwidth efficient as possible. It is a more complex message, and it requires the client to keep state. In the above exaple, the symbol is identified only when a new "entry" is created, and the entry is given an MDEntryID. For a top of book environment, one will generally create two entries for each security, one for the bid and one for the offer. Changing or deleting a quote is quite trivial, and many such updates can be packed into one Market Data - Incremental Refresh message, thus lowering the header length / body length ratio and saving bandwidth.