 |
OnixS C++ CME MDP Premium Market Data Handler
5.8.9
API Documentation
|
|
OnixS C++ CME MDP Premium Market Data Handler
5.8.9
API Documentation
|
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.
Yes, exactly.
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.
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.
The handler reports all errors and warnings via the OnixS::CME::MDH::HandlerListener::onError and OnixS::CME::MDH::HandlerListener::onWarning callbacks, respectively.
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.
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.
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.
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.
Security Definition contains fields that represent the multipliers to convert the CME Globex display price to the conventional price:
DisplayFactor (tag 9787) - for securities with non-fractional priceMainFraction (tag 37702) and SubFraction (tag 37703) - for securities with fractional priceHowever, I can ping the CME router. Any insight or suggestions on what may be going on here?
See Connectivity troubleshooting.
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:
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.
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.
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.
Please see Feed tracing.
Please see the Benchmark Sample.
It depends on many parameters, including network, hardware, operating system environment, market data rate and handler settings.
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.