White Paper: CME MDP 3.0

This whitepaper provides an overview of enhancements in the CME MDP 3.0 market data interfaces.

With the third generation of its market data platform CME made several key improvements in the application protocol and message encoding to allow more efficient market data processing on the client side.

Matching engine event boundaries are now clearly indicated with the MatchEventIndicator (5799) tag to allow a client application apply market data updates transactionally. The client application has explicit knowledge of the moment when market data is consistent for analysis in the case of complex order book updates or multiple instruments affected by a matching event. Matching events are now independent of the UDP packet boundaries - a matching event may spread over several sequential UDP packets and a UDP packet may contain several matching events. Market data updates of a matching event are segregated by update type to allow the client application skip handling of messages not relevant to specific algorithm to reduce processing time. New trade summary messages aggregate trades by price level resulting in fewer trade updates disseminated in the case of large fill events.

The following diagram  shows MDP 3.0 packets structure:

CME_MDP_packet _structure

( http://www.cmegroup.com/confluence/display/EPICSANDBOX/MDP+3.0+Packet+Structure+Examples) 

View larger image

 

The new Simple Binary Encoding format which replaced the FAST encoding allows more efficient and faster message decoding on the client side thanks to the fixed-length fields, native little-endian byte order and proper field alignment. The client application can efficiently access message fields directly in the buffer filled with data received from the network socket. The client application does not have to perform complex sequential state-based decoding process to access required fields. Overall the increased message encoding and decoding speed overcomes slight increase of disseminated data size and bandwidth requirements compared to the FAST compression.

Taking the new enhancements into account there is still space for data flow optimization on the server and client sides. We observe considerably different UDP packet sizes in production environment for different channels resulting in different processing time on the client side. Large complex matching events are likely caused by mass quote update orders affecting numerous instruments in one matching event. To optimize processing time in these cases further data re-organization or complex handling on the client side may be needed.

Processing _latency

View larger image

 

For more information and free trial version contact our sales at  SupportFIXAntenna@epam.com.