The given section guides through major changes and helps to make migration from previous releases painless.
Previously, the Feed Engine concept was represented by the ready-to-use
OnixS::CME::ConflatedUDP::FeedEngine class providing the default implementation for the machinery manipulating multicast/TCP feeds and working threads.
The concept of the Feed Engine was improved to let the users build and use custom implementations. As a result, the SDK exposes the OnixS::CME::ConflatedUDP::NetFeedEngine abstract class serving as a base for the actual implementations. Thus, the given class instances cannot be constructed any more and now the class serves only to identify use of the Feed Engine.
The new class OnixS::CME::ConflatedUDP::SocketFeedEngine was added to the API to provide the functionality of the eliminated
OnixS::CME::ConflatedUDP::FeedEngine class. The new class implements the Feed Engine concept using standard Socket API for the network-related operations. The new OnixS::CME::ConflatedUDP::FeedEngineThreads class was introduced to run the Feed Engine machinery on a predefined set of threads, thus providing behavior similar to the previous one.
Previous restrictions required the users to define values for almost all settings for the Handler at the instance construction time. Some configuration steps had to be done after instance construction. Now, the Handler allows changing its parameters any time the Handler is not busy with the market data processing. Also, all settings, which available for modifications, are gathered into the OnixS::CME::ConflatedUDP::HandlerSettings class and exposed for editing by the OnixS::CME::ConflatedUDP::Handler::settings member.
The new groups of parameters like OnixS::CME::ConflatedUDP::HandlerSettings::listeners and OnixS::CME::ConflatedUDP::HandlerSettings::session were added to provide unification in more flexibility while manipulating settings.
See Adjusting Handler Settings for the list of all available groups and other information.
Also, previously, the parameters related to the market data processing session must be supplied to the Handler at the moment of processing initiation as the argument to the OnixS::CME::ConflatedUDP::Handler::start member. Now, the parameters related to the market data processing session are a part of OnixS::CME::ConflatedUDP::HandlerSettings collection and can be accessed using the OnixS::CME::ConflatedUDP::HandlerSettings::session member.
TCP recovery service and settings became a part of the market data processing session parameters. See the OnixS::CME::ConflatedUDP::AdvancedSessionSettings::tcpRecovery member and the OnixS::CME::ConflatedUDP::TcpRecoverySessionSettings class for more details.
The Log Replay functionality was improved and now it is based on the same Feed Engine concept as processing market data transmitted by the MDP. As a result, market data, extracted from the logs, passes the feed layer thus raising same feed-related events as during processing of market data coming via the network. This functionality was missed in the previous releases. Also, due to certain restrictions in the previous design, the improperly configured processing could lead to the issues in processing flow which were hard to detect. All those issues are eliminated in the updated Log Replay.
Also, the Log Replay was enhanced with the new features and offers much wider functionality in compare to the previous releases. See Replaying Logs, PCAPs CME DataMine/Historical Data for more details.