OnixS C++ CME MDP Premium Market Data Handler  5.8.3
API Documentation



Order books and prices




Can more than one channel per the handler be processed? Alternatively, are multiple handler instances necessary?

One instance of the OnixS::CME::MDH::Handler processes market data for a single channel only. Users must create multiple instances of the handler to process data from multiple channels.

Is the handler implicitly subscribed to all instruments of the specified channel? Will it receive security definitions for all instruments of this channel?

Yes, exactly.

How does instrument/group filtering work? Why would we want to do this?

Filtering (instrument selection) is proper when market data is required for specific instruments only. Instrument selection is like an inclusive allowlist. E.g., if security A is selected, security-related events (members of OnixS::CME::MDH::SecurityListener) are raised for security A only.

If two or more securities are selected, events are triggered only for those securities.

See also
Selecting securities of interest

How do I find an ID for the security of interest?

The CME disseminates Security Definition messages. They contain information about the given security, for instance, SecurityExchange, Asset, Symbol, SecurityType, and SecurityID.

Analysis of these fields allows the user to choose the security of interest.

How are problems with market data indicated (e.g., an order book became invalid)?

The handler reports all errors and warnings via the OnixS::CME::MDH::HandlerListener::onError and OnixS::CME::MDH::HandlerListener::onWarning callbacks, respectively.

See also
Errors and warnings

Order books and prices

How to retrieve/receive the initial order book?

Any OnixS::CME::MDH::SecurityListener::onBookUpdate call gives you a consistent order book state (except for the Natural Refresh mode). You can get a snapshot at startup if you need the book state at the first call.

See also
Constructing and copying order books

How do we know whether the data delivered via the `onBookAtomicUpdate` call is the first or last change of a "transaction"? How can the order book be determined as valid/consistent/not-crossed after a single `onBookAtomicUpdate()` call?

CME does not guarantee a 100% book up-to-date on intermediate updates. It is guaranteed only after the "End of XXX quote" market event where XXX is real or implied. So you have to check this field to ensure the book is 100% up-to-date.

Another approach is to use book update callbacks of OnixS::CME::MDH::SecurityListener rather than atomic book updates. Book update callbacks are publishing books only at the "End of XXX quote" market event giving guarantee books are consistent and up-to-date.

See also
Custom order book building, OnixS::CME::MDH::SecurityListener, OnixS::CME::MDH::MarketDataListener

What is the difference between the 'Book Atomic Update' and 'Book Update' events?

Book Atomic Update (OnixS::CME::MDH::SecurityListener::onBookAtomicUpdate) is an elementary action over a book, and usually, there are multiple atomic updates inside a single Snapshot or Incremental Refresh message. Also, the book may not be valid between two atomic updates. The book is valid only when all atomic updates for the single market event are processed.

Book Update (OnixS::CME::MDH::SecurityListener::onBookUpdate) is raised when all atomic updates are processed and the book is valid and up-to-date.

See also
Custom order book building

Is there a way to get the message sequence number when the order book update happens?

The CME MDP 3.0 assigns sequence numbers to network packets but not messages.

Order book updates are raised at the end of the market (sub-) events like "End Of Quotes" and "End of Event". A single market event may consist of multiple messages. As a result, data related to a single book update may be distributed across multiple messages or event multiple network packets.

The attribute identifying the end of the market event is sent inside messages. A network packet may contain multiple messages, and multiple market events may be sent within one packet. Thus multiple order book updates may be raised while processing a single network packet.

To sum up, there is no one-to-one relationship between the packet sequence number and the order book update.

While processing market data, I noticed that some instruments are divided by `100`, others by `10000`, and others are not. How do I determine what value to scale the prices?

Security Definition contains fields that represent the multipliers to convert the CME Globex display price to the conventional price:

See also
CME Pricing documentation, OnixS::CME::MDH::SecurityListener


After switching the operating system, even the sample program can no longer receive market data (`code=NoNetworkActivity`).

However, I can ping the CME router. Any insight or suggestions on what may be going on here?

See Connectivity troubleshooting.

After the configuration file update, I encountered the following issue: "Cannot find connection settings for the feed [type=MboSnapshot,role=B]. Probably, connectivity configuration does not assume the use of the feed. ". What does it mean? I have downloaded the `config.xml` file from the CME FTP.

By default, the handler is configured to fail over to the secondary (B) feed if no data is received on the primary (A) feed. The given scenario assumes using both A and B feeds. Therefore, the handler looks for the connectivity parameters for both primary and secondary feeds. However, in rare cases, CME does not provide secondary recovery feeds. For example, the certification environment can expose only primary (A) feeds. You need to update the configuration to run the handler in such environments. Changing the feed layout parameter is necessary for those feeds whose secondary source is unavailable.

The following code snippet shows how to configure the handler to use only primary recovery feeds:


If the handler joins while the market is busy, warnings ("code=QueueOverflow") are reported. Is there any possibility of raising the configured limit? If so, how?

When the handler performs the book recovery, it caches the data received on Incremental feeds. When the market is busy, the number of cached messages may exceed the configured limit defined by the OnixS::CME::MDH::HandlerSettings::recoveryQueueMaxSize parameter. So, to avoid QueueOverflow warnings, it is necessary to increase the value of this parameter.

What is the cause of "QueueOverflow" warnings?

The cause is a violation of the received packets sequence (gap) that was not restored after the OnixS::CME::MDH::RealtimeFeedSettings::outOfOrderPacketMaxInterval number of packets or after the OnixS::CME::MDH::HandlerSettings::lostPacketWaitTime elapsed. The packet sequence violation can be caused by packet loss on different levels: network connectivity, system or application issues.

See also
Tuning network packet gap detection, Connectivity troubleshooting.

Also, Incremental packets are cached when the handler performs a large-scale recovery due to the gap or while joining the market lately. While the market is busy, the Incremental packets queue may reach its limit, causing the described warning.

See also
If the handler joins while the market is busy, warnings ("code=QueueOverflow") are reported. Is there any possibility of raising the configured limit? If so, how?.

How can packet issues (back-pressure/queuing) be diagnosed?

Please see Feed tracing.


What latency is added by the handler?

Please see the Benchmark Sample.

What is Handler CPU consumption?

It depends on many parameters, including network, hardware, operating system environment, market data rate and handler settings.

What is the expected maximum latency our callback implementation should have?

It should be as small as possible not to impact the ability to process data during the active market. Long callback execution may lead to buffer overflows and thus data losses.