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 to 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 to skip the handling of messages that are not relevant to a 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 packet structures:
The new Simple Binary Encoding format that replaced the FAST encoding allows for 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 speeds overcome the slight increase of the disseminated data size and bandwidth requirements compared to 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 the production environment for different channels resulting in different processing times 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.
For more information and a free trial version, contact our sales at SupportFIXAntenna@epam.com.