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 processing errors and warnings via the OnixS::CME::MDH::HandlerListener::onError and OnixS::CME::MDH::HandlerListener::onWarning callbacks, respectively.
Use OnixS::CME::MDH::SecurityListener::onBookUpdate to receive book state. Notification timing depends on OnixS::CME::MDH::BookManagement::updateNotification; the first callback alone does not establish recovery completion or currency with the live stream. See Interpreting a book update for the notification and recovery conditions, including Natural Refresh.
To retain a snapshot, see Constructing and Copying Order Books.
A single atomic update does not establish book consistency. Use the book type's end-of-quote or end-of-event indicator, or use OnixS::CME::MDH::SecurityListener::onBookUpdate with the default OnixS::CME::MDH::BookUpdateNotification::OnEndOfEvent policy. See Interpreting a book update for the boundaries and recovery conditions.
Book Atomic Update (OnixS::CME::MDH::SecurityListener::onBookAtomicUpdate) reports an elementary book change. A snapshot or incremental message can contain multiple atomic updates, and intermediate book state may be inconsistent.
Book Update (OnixS::CME::MDH::SecurityListener::onBookUpdate) reports the maintained book according to the configured notification strategy. Timing and recovery conditions are described in Interpreting a book update.
The CME MDP 3.0 assigns sequence numbers to network packets but not messages.
With the default notification strategy, incremental book updates are raised at the relevant market event boundaries (see Book Update Notification Strategies). 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 even 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:
However, 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:
The handler queues Incremental packets while real-time processing is suspended, including during instrument, market and TCP recovery. The OnixS::CME::MDH::HandlerSettings::recoveryQueueMaxSize setting limits this queue in packets. When the configured threshold is reached, the handler discards the oldest queued packet and reports OnixS::CME::MDH::Issue::QueueOverflow through OnixS::CME::MDH::HandlerListener::onWarning for each discarded packet. Keep warning callbacks inexpensive, since overflow under heavy traffic can produce many warnings.
A packet gap is reported separately as OnixS::CME::MDH::Issue::SequenceError. Discarded queued packets can cause a gap during replay and another recovery attempt; see Gaps during replay.
Before increasing the queue limit, consider the incoming packet rate, recovery duration, overflow warnings and process memory usage. A larger limit consumes more memory and does not remove a processing bottleneck. Memory limits are especially important in Win32 processes.
The OnixS::CME::MDH::SocketFeedEngineSettings::socketBufferSize setting instead requests a socket receive-buffer size in bytes. The operating system may grant a smaller buffer. The SDK checks the granted size and reports a warning if it is smaller than requested, or if setting or checking the size fails. Socket receive-buffer loss can occur without a QueueOverflow warning: those packets are lost before the handler can enqueue them. Increasing the recovery queue does not prevent this loss.
For processing delays and packet-loss diagnosis, see Keeping callbacks responsive, Tuning network packet gap detection and Connectivity troubleshooting.
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.
Callbacks should return promptly so the handler can keep up with incoming traffic, including during recovery replay. Long callbacks can exhaust receive buffers and cause packet loss. See Keeping callbacks responsive for guidance on moving expensive work to a worker.
