MDP 3.0, is CME migrating to a new data comm protocol? | Reviews of Brokers and Data Feeds


futures.io - futures trading strategies, market news, trading charts and platforms


Reviews of Brokers and Data Feeds


Review and discuss futures brokers, their requirements and features, or ask questions about brokers and data feeds




 

MDP 3.0, is CME migrating to a new data comm protocol?

  #55 (permalink)

Florida
 
Trading Experience: Advanced
Platform: NinjaTrader 8
Favorite Futures: ES, CL
 
trendwaves's Avatar
 
Posts: 697 since Dec 2012
Thanks: 2,864 given, 2,488 received


aslan View Post
People are worried about nothing. The only down side is a tick chart may need to be slightly adjusted in terms of number of ticks to account for a smaller number of avg ticks.

I wish i could share your optimism.

Seeing how different vendors are already looking at different ways to break apart (or not) these data messages for subsequent delivery to the end users concerns me. CME is taking the position: here is the new protocol, good luck.

There are timing issues involved in how to precisely and accurately break apart and correctly synchronize (insert) the components of a packet into the resulting output stream. This is because the stream is not just trade executions, but is happening in parallel with book update events. It is the correct and accurate ordering of these asynchronous event streams that has in the past caused significant problems for vendors.

In the current protocol, there is a well known race condition between asynchronous trade execution events with the separate stream of order book update events. This race condition, can produce a mis-ordering of events in the resulting stream produced by an invalid vendor algorithm inadvertently causing buy orders to appear as sell orders and conversely sell orders to appear as buy orders in the stream. With each vendor's home brewed algorithm we ended up with vendors implementing a variety of solutions resulting in a ranking list from good to bad of retail data streams with respect to what we call an 'unfiltered' data feed. A significant variance of the accuracy of unfiltered data feed currently exists from vendor to vendor.

This new protocol adds at least one new layer of complexity to this, and perhaps multiple layers of complexity. Based on past performance, I cannot help but wonder if any vendor will 'get it right' this time ?

Having said all that, I personally have always favored viewing the market from the perspective of the initiating trade ( 'agressor' ). I find much more value in seeing the initiating trade, (Mikes 50 lot trade), on the tape. I really don't care about seeing the unending stream of Joe 1-lot fills. I view this as a signal to noise problem. My concern is some (hopefully not all) vendors may attempt to deconstruct the initiating trade execution packet back into a useless stream of resulting 1-lot fills. My hope is the bandwidth savings (and lower implementation complexity) found in the initiating trade stream, as designed by the CME, will persuade vendors to do the right thing and keep it intact for their customers. Sometimes less is more.

Be Patient and Trade Smart
Visit my futures io Trade Journal Reply With Quote
The following 4 users say Thank You to trendwaves for this post: