The Handler API is enclosed in the OnixS::CME::MDH namespace. The master OnixS/CME/MDH.h header file collects all header files.

Choose a workflow

First, install and link the SDK. Then choose a market-data workflow:

Offline replay (recommended first): Follow the offline replay quickstart with the Replay sample and bundled market data. This workflow does not require CME entitlement or live multicast connectivity, but it still requires an SDK license and a connectivity configuration file.
Live CME channel: Follow the live CME channel quickstart when an SDK license, CME entitlement, a current connectivity configuration file, and a multicast-capable network are available.

Constructing and configuring the handler

The OnixS::CME::MDH::Handler class encapsulates the market data processing logic in the bounds of a CME MDP 3.0 channel. The OnixS::CME::MDH::HandlerSettings class contains parameters controlling various aspects of market data processing.

Default values configure the likely behaviour of the handler instance. However, some parameters must be set explicitly before starting market data processing:

Handler handler;
 
// Selects the CME MDP 3.0 channel and specifies the configuration file's location.
handler.settings().channel(310).connectivityConfigurationFile("config.xml");
 
#if !defined(_WIN32)
// Specifies network interfaces.
handler.settings().feeds().feedANetworkInterfaces(NETWORK_INTERFACE_FOR_FEEDS_A)
                          .feedBNetworkInterfaces(NETWORK_INTERFACE_FOR_FEEDS_B);
#endif

See also: Adjusting Handler's settings

Licensing

The SDK needs a valid license for successful execution. If the licensing subsystem is not able to find a valid license, it throws an exception when the OnixS::CME::MDH::Handler::start is called.

By default, the handler looks for a license in the application’s current directory. To instruct the handler where to look for a valid license, use the OnixS::CME::MDH::LicenseSettings::licenseStore method.

Note: The licensing subsystem looks for a valid license in the specified folder and selects the best one. If multiple licenses are available, it selects the most significant one (for example, a production license is selected instead of a trial one if both are available).

The following example shows how to specify the license location:

// The folder in which the license is stored.

handler.settings().licenseSettings().licenseStore("license");

Binding an explicit Feed Engine (optional)

A Feed Engine receives data and delivers it to the Handler for processing.

By default, each OnixS::CME::MDH::Handler uses an internally managed default Feed Engine backed by OnixS::CME::MDH::SocketFeedEngine and an internal worker thread pool. No Feed Engine setup is required.

For production applications, prefer an explicit Feed Engine to control reception and processing threads; see Default and explicit engines.

Bind an explicit Feed Engine to use the Solarflare Feed Engine, share an engine between Handlers, or configure reception independently. The application must run its processing logic. The following example declares the engine before the Handler so that it outlives the binding, and uses a thread pool to run it in the background:

// Declared first so the engine outlives the Handler and the thread pool.
SocketFeedEngine feedEngine;
Handler handler;
 
// Selects the CME MDP 3.0 channel and specifies the configuration file's location.
handler.settings().channel(310).connectivityConfigurationFile("config.xml");
 
#if !defined(_WIN32)
// Specifies network interfaces.
handler.settings().feeds().feedANetworkInterfaces(NETWORK_INTERFACE_FOR_FEEDS_A)
                          .feedBNetworkInterfaces(NETWORK_INTERFACE_FOR_FEEDS_B);
#endif
 
// Binds the Handler to the explicit engine.
handler.settings().feeds().engine(&feedEngine);
 
// Runs the Feed Engine on a background thread.
FeedEngineThreadSettings threadSettings;
FeedEngineThreadPool feedEngineThreads(feedEngine, threadSettings);

Note: The application owns an explicitly bound engine. Keep it alive while it is bound to a Handler and while any processing pool or application-managed thread uses it. Keep the pool alive while it is needed to process the engine. Calling OnixS::CME::MDH::Handler::stop does not remove the binding.

Subscribing to market data events

After constructing and configuring an OnixS::CME::MDH::Handler, subscribe to the events that provide the required market data (e.g., order book updates).

See also: Event listeners

Starting market data processing

To start market data processing, call the OnixS::CME::MDH::Handler::start method.

handler.start();
 
std::cout << "Press Enter to stop." << std::endl;
std::cin.get();

Note: The default Feed Engine runs on internally managed threads, so no additional processing step is required. When an explicit Feed Engine is bound, run it using a OnixS::CME::MDH::FeedEngineThreadPool, as shown above, or invoke OnixS::CME::MDH::NetFeedEngine::process repeatedly.

To stop market data processing, call the OnixS::CME::MDH::Handler::stop method.

handler.stop();

Configuring logging (optional)

Handlers and Feed Engines can log the market data they process and other events that occur during processing. They select their loggers independently: a Handler uses the library-managed file logger by default, while a Feed Engine uses OnixS::CME::MDH::NullLogger by default.

The OnixS::CME::MDH::Logger abstract class encapsulates the logging subsystem. File-based logging is a good choice for most cases. When using an explicit Feed Engine, configure its logger through the Feed Engine settings before constructing it, and configure the Handler logger separately.

The following example configures one file logger for both components:

FileLoggerSettings loggerSettings;
loggerSettings.filename(makeLogFilename(310));
loggerSettings.severityLevel(LogSeverity::Debug);
 
// The logger must outlive the Feed Engine and Handler that use it.
FileLogger logger(loggerSettings);
 
SocketFeedEngineSettings feedEngineSettings;
feedEngineSettings.logger(&logger);
SocketFeedEngine feedEngine(feedEngineSettings);
 
Handler handler;
handler.settings().feeds().engine(&feedEngine);
handler.settings().logging().logger(&logger);

Note: Handlers and Feed Engines do not manage the lifetime of a custom logger. Keep it alive until every component using it has been destroyed.

See also