odin-detector/odin-data

# Overview

The design goal for odin-data is to provide a generic, high-performance, scalable data
capture and processing framework upon which specific detector data acquisition systems
can be built with dynamically loaded plugins.

The framework consists of two separate C++ applications; the frameReceiver and
frameProcessor. The frameReceiver focuses on data capture - receiving data from a
network interface into system memory buffers. The frameProcessor listens on a ZeroMQ
channel for messages from the frameReceiver containing a pointer to a data buffer in
shared memory, which it will then pass through a set of plugins, before notifying the
frameReceiver that it can re-use the shared memory.

The intended use case is to run multiple frameReceiver-frameProcessor pairs (nodes),
possibly across multiple servers, depending on the data throughput and procesing
requirements. However, an individual node does not communicate with other nodes - it is
simply made aware of the total number of nodes and its own rank in the overall system.
This lets each node verify that it is receiving the correct frame numbers (in temporal
mode), or the correct data channels (in geographical mode).

## IPC Interface

The `--ready` and `--release` arguments of the frameReceiver and frameProcessor
configure the ZeroMQ channels used to send and receive messages to manage access to
shared memory buffers.

Without an application to listen to the frameReceiver ready messages and send release
messages in response, it will exhaust the shared memory buffers and then ignore all
further data. However, the frameProcessor can be used as a diagnostic without doing
anything with the shared buffers: if no plugins are configured, the application will
still communicate with the frameReceiver and immediately releasing the shared buffers it
receives.

Where possible, the frame data transferred through a shared memory buffer is processed
in place to minimise the number of copies. However some processing requires a new memory
buffer to output to. This is a decision to be made for each individual process plugin.
See [Types of Frame] for more details.

[Types of Frame]: ../how-to/frame-processor-plugin.md#types-of-frame