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.