The messaging subsystem has been redesigned in the SDK. Previously, a message was representing a FIX container that provided access to the field values using tags as keys. Also, the processing machinery used generic SBE (Simple Binary Encoding) decoder to extract data from the SBE-encoded content transmitted by CME MDP and to build a FIX message.
The given approach of manipulating market data provided certain benefit as it allowed to work with all market data through a unified FIX container. The drawback of the given approach was latency. SBE-encoded content had to decoded and copied to the FIX container on a processing layer.
The messaging subsystem has been redesigned to provide customers with maximal performance, and now the API exposes classes for each type of SBE message defined by SBE coding templates.
The given approach allows the customers to be much closer to the original data transmitted by CME, as the SBE to FIX mapping is rather semantical and thus losses certain important characteristics which the customers may require.
Also, the performance is dramatically improved due to eliminating SBE to FIX transformation subsystem, and now data is directly accessed without any intermediate copying.
Events and listeners, reflecting miscellaneous aspects of the Handler behavior, have been redesigned, and now are more consistent compare to the previous design.
The table below represents a quick overview of major listeners and key improvements.
| Listener | Description |
|---|---|
| OnixS::CME::MDH::HandlerListener | Encapsulates Handler events. Previously, the Handler behavior-related events were spread in a few listeners like a listener for the Handler state and issues (warning, error). Now, everything is gathered into a single listener. The states have been substituted with the correspondent callbacks and enhanced. For example, now the callback identifying the end of recovery exposes the status of recovery completion indicating whether the recovery is succeeded or failed with a detailed description of the last case. |
| OnixS::CME::MDH::MarketDataListener | Encapsulates market data events. The given listener is a close analog to the OnixS::CME::MDP3::MessageProcessingListener exposed by the previous generations of the SDK. However, it was enhanced with packet-related events exposing original data received by Handler instances. |
| OnixS::CME::MDH::SecurityListener | Encapsulates security-related events. Previously, security-related events were raised through a number of listeners like the OnixS::CME::MDP3::TradeListener and the OnixS::CME::MDP3::DirectChangeBookLister. |
Previously, the way how Handler processed market data was defined by which overload of the OnixS::CME::MDH::Handler::start member was used to spawning processing.
Starting with version 4 of the SDK, the OnixS::CME::MDH::SessionSettings class was invented to define market data processing for the session. Settings are supplied to the OnixS::CME::MDH::Handler::start member as a parameter. Currently, settings allow defining whether market data recovery must be done at the beginning of market data processing or in case of data loss or other processing error and so on. Also, settings allow defining which type of market (by price or by order or both) is to be recovered. New parameters offer a wider variety of processing ways compare to previous versions.
Previously, it was not possible to use TCP recovery service while maintaining order books in natural refresh mode. Starting with version 4 of the SDK a TCP recovery facility can be used while processing market data in any selected way.
The users must explicitly configure the Handler concerning which types of order books are to be maintained starting with the given major release. Previously, maintenance was defined by either the Handler's settings or by the fact of associating correspondent book listener with a Handler instance. See Manipulating Books for more information.
What's New and Important Changes section enlists other features and improvements as individual topics.