A backend instance must be configured, in both stages, before it can process any lag frames from the WIDAR correlator baseline boards. The backend software allows the creation of multiple backend configurations, only one of which is active at any moment. Backend configurations may also be destroyed after they are no longer needed. There are only three “commands” to a backend system that are needed to control the backend configuration: create, which creates a named configuration; activate, which causes a named configuration to become the active backend configuration; and destroy, which destroys a named configuration (except when the named configuration is the active configuration, in which case the configuration's destruction is deferred until another configuration is activated).
Configuration commands are implemented as downstream, serialized events in the backend system. This ensures that configuration commands arrive at the pipeline elements in the correct order and can be inserted between lag frames precisely (and will maintain their position in the data stream). Configuration deactivation, which occurs implicitly just before the active configuration changes, causes internal buffers in the pipeline elements to be flushed, ensuring that a new active configuration will not apply to any lag data in the pipeline ahead of the activation event.
Backend configurations in general are specified as XML documents. To limit the number of pipeline elements that need to parse XML documents, only elements in the input stage pipeline will have access to XML configuration documents. This guideline is intended to simplify the development of elements that are designed for pipelines in the lag processing stage. Although the current design follows this guideline, it is somewhat uncertain at this time whether the guideline can be maintained in the future. The uncertainty stems from doubts about being able to supply configuration parameters to all pipeline elements efficiently. The use of GStreamer bins may slightly mitigate against some measure of inefficiency, but whether this is actually the case remains to be seen.
Because the input stage pipeline of the backend is always running, while the lag processing stage pipelines are configuration specific, configuration changes are handled somewhat differently by the two stages. Some of these differences are described below.
As alluded above, the input stage contains a single pipeline. The primary tasks of the input stage are to sort the WIDAR lag frames into lag sets, and to direct a time-ordered sequence of complete lag sets to the proper lag processing stage pipeline. Both of these tasks may be considered as a kind of sorting, where the sorting “instructions” are (partly) defined by the backend configuration. The relatively static nature of the input stage functionality requires only a single pipeline in the input stage. When a new configuration is activated, all that is required of the pipeline elements is to flush (and possibly free) some internal pipeline buffers under the old configuration, initialize buffers for the new configuration, and change the sorting instructions.
The processing specification for the lag processing stage of the backend is equivalent to the specification of a set of processing pipelines (and their inputs), so each processing pipeline in this stage exists as part of only one configuration. Therefore creating (or destroying) a configuration corresponds to creating (or destroying) a set of pipelines. Activating (or deactivating) a configuration requires no action on the part of the lag processing stage because the input stage sends a flush event into each of the pipelines belonging to the deactivated configuration after the final lag set under the deactivated configuration has been sent to that pipeline.