The Feed Engine concept encapsulates data reception aspects to let the Handler focus on market data processing. It also provides advanced facilities on utilizing system resources to achieve the best performance and latency characteristics.

The concept of the Feed Engine was designed to make things more efficient. The Feed Engine machinery pushes extracted market data to the associated Handler instances. Multiple Handler instances can share a single instance of the Feed Engine implementation.

The concept is exposed as a set of abstract classes. Implementing them allows users to build their machinery extracting market data from various sources, including network, file-based stores, etc.

The primary entity of the concept is the OnixS::CME::ConflatedUDP::NetFeedEngine class. The given class serves as a factory for feed links. The Handler allocates feed links through the interface of the given class.

The OnixS::CME::ConflatedUDP::NetFeedLink abstract class encapsulates manipulations related to market data transmission (extraction). The Feed Engine allocates instances of the given class descendants upon a request. The Handler passes an instance of the OnixS::CME::ConflatedUDP::NetFeed class containing all feed attributes, including connectivity information. When a link is constructed, the Handler binds it to the feed instance and further manipulation is performed through the instance of the OnixS::CME::ConflatedUDP::NetFeed class to which the allocated link was bound.

When the Handler needs to get data from a particular feed (source), it spawns data reception using the corresponding instance of the OnixS::CME::ConflatedUDP::NetFeed class. That instance calls the OnixS::CME::ConflatedUDP::NetFeedLink::link member to establish a connection or join a multicast group depending on the feed type. Once the feed is connected, the Handler expects the Feed Engine will push market data through the OnixS::CME::ConflatedUDP::NetFeedConsumer class instance bound to the corresponding feed.

Warning: The OnixS::CME::ConflatedUDP::NetFeedConsumer class represents an abstraction of a shared recipient. It assumes the instance is to be acquired for further manipulations before other members are invoked. This requirement is dictated by the fact the instance of the OnixS::CME::ConflatedUDP::NetFeedConsumer class may be associated with multiple feeds and thus can be busy processing data from the other feed. The acquisition and release are made with the help of the OnixS::CME::ConflatedUDP::NetFeedConsumer::tryAcquire() and OnixS::CME::ConflatedUDP::NetFeedConsumer::release() members. The returned value of the first member indicates whether the consumer was acquired or not. If not, the Feed Engine may keep trying to acquire access to the consumer again or switch processing other events for the other feeds, thus making the entire data reception machinery more efficient.

When the Handler needs to stop receiving data from a particular feed, it invokes the OnixS::CME::ConflatedUDP::NetFeed::disconnect member, which, in its turn, calls the OnixS::CME::ConflatedUDP::NetFeedLink::unlink member. Since that moment, the Feed Engine must stop pushing events of any kind to the OnixS::CME::ConflatedUDP::NetFeedConsumer associated with the feed.

Feeds of OnixS::CME::ConflatedUDP::FeedType::Historical feed type assumes sending requests while interacting with the counterpart. Therefore, the OnixS::CME::ConflatedUDP::NetFeedLink::send member must support data transmission.

When the Handler stops processing market data, it destroys all feeds used during the session. That causes all allocated instances of the OnixS::CME::ConflatedUDP::NetFeedLink class to be released using the OnixS::CME::ConflatedUDP::NetFeedLink::release member. It is guaranteed no other members of the OnixS::CME::ConflatedUDP::NetFeedLink class are invoked for the instance after it was released.

The OnixS::CME::ConflatedUDP::NetFeedEngine::process member runs the Feed Engine machinery. The concept does not restrict implementations regarding whether the given member must be invoked cyclically or a single time only. It is all up to the implemention whether to choose single-threaded execution or to support simultaneous invocation by multiple threads to achieve maximal efficiency.

Note: It's highly recommended to describe behavioral policies for a particular implementation.

A few predefined implementations are exposed by the SDK as ready-to-use solutions for certain cases:

Implementation	Description
OnixS::CME::ConflatedUDP::SocketFeedEngine	This is the default implementation of the Feed Engine concept offered by the SDK for handling live network data. It uses standard socket API while manipulating the network layer. The implementation supports simultaneous invocation of the OnixS::CME::ConflatedUDP::NetFeedEngine::process member and thus can be used in combination of the OnixS::CME::ConflatedUDP::FeedEngineThreads class.
OnixS::CME::ConflatedUDP::SolarflareFeedEngine	This implementation is based on the Solarflare ef_vi SDK using zero-coping and kernel-bypass techniques. Warning The given feed engine is available on the Linux platform only and requires Solarflare network cards to be run on. The implementation supports simultaneous invocation of the OnixS::CME::ConflatedUDP::NetFeedEngine::process member and thus can be used in combination of the OnixS::CME::ConflatedUDP::FeedEngineThreads class.
OnixS::CME::ConflatedUDP::replayLogFiles	The given function uses internal implementation of the Feed Engine concept which extracts data from the previously recorded log files and pushes it into the given Handlers. The processing is synchronous. Advanced parameters are offered to customize the behavior of the replay.
OnixS::CME::ConflatedUDP::replayPcapFiles	The given function uses internal implementation of the Feed Engine concept which extracts data from the .PCAP (Packet Captures) files and pushes it into the given Handlers. The processing is synchronous. Advanced parameters are offered to customize the behavior of the replay.