Design Decisions

The frameReceiver and frameProcessor are implemented as two separate applications for a few key reasons:

Separation of concerns

There are fundamentally two separate problem domains: data capture - receiving data from the network interface onto the system - and data processing. These two operations can be almost completely isolated with no coordination of the two processes other than to pass pointers to data frames in memory. By splitting the data acquisition process into these two parts they can be developed and debugged in isolation rather than within in a single process with multiple threads.

By focusing one process on data capture, it is possible to optimise as required, such as by allowing it higher priority to ensure sufficient resources. Once data is on the system, it enters the domain of procesing and writing to persistent storage. In this domain bottlenecks in the processing can be overcome by increasing the resources of the processing server, such as by adding more memory, or by optimising the logic of an isolated FrameProcessorPlugin.

Monitoring

The first failure point in the data acquisition pipeline is receiving data from the network interface into system memory. If this is not done quickly enough, packets will be dropped at the kernel layer with no indication of what went wrong. Allowing the frameReceiver to do the minimum work to gather data into memory means this usage can be monitored and when it is exhausted it will be clear where data was lost. This monitoring extends throughout the frameProcessor through processing time metrics for each plugin and watchdog timers around certain I/O to show when a call is blocking for longer than expected.