Process separation is the most important principle employed in the backend design to provide robustness to the system. The lag frame processing functionality of the backend is clearly divided into two stages: the input stage, which sorts and orders the WIDAR lag frames arriving from the WIDAR baseline boards via an Ethernet network; and the lag processing stage, which applies a sequence of various transformations and side-effect producing operations to the complete lag sets[6] produced by the input stage. These two stages are separated through the mechanism of process isolation. As described below, the input stage is likely to be relatively stable, while the lag processing stage is likely to be less stable; therefore, process isolation is used to prevent faults in the lag processing stage from causing faults in the input stage. Because the lag processing stage comprises multiple pipeline processes (see the section called “Lag processing stage design”), this design also ensures that a fault in any lag processing pipeline process is isolated to that single process.
By design, the function of the input stage is invariant across all instances of the WIDAR correlator backend. If the backend uses the software under discussion in this document, it is, by definition, using the input stage of this software.[7] The central role of the input stage in all backend instances requires that it be implemented efficiently and operate robustly. For these reasons, the input stage cannot be (dynamically) extended with new functionality.
In contrast to the input stage, the lag processing stage functionality is quite broad, and subject to different requirements in different backend instances. This stage is where most of the ongoing development of backend functionality will occur. The GStreamer framework, through its mechanisms for pipeline extensibility, provides the greatest benefit to the backend software in this stage.
Note that both transformations, such as lag normalization, Fourier transformations, and backend integration, and side-effect producing operations, such as output creation and data duplication, may occur in this stage. This may be a point of confusion insofar as the general conception prior to the present design separated the “data processing” from the “output” functionality. The present design is superior in that it reinforces the distributed nature of output production that is foreseen as the standard output mode of the backend. In this design, pipeline elements that produce output may co-exist simultaneously in multiple pipelines.
Communication between the two backend stages requires some form of inter-process communication (IPC) because the stages run in distinct processes. The current design uses datagram-oriented Unix domain sockets as the IPC mechanism for this purpose. The benefits of this method are primarily in its ease of use when compared with stream-oriented sockets or shared memory. Another important benefit of using this method is that the backend stages are loosely coupled as a consequence (as long as the sockets operate in non-blocking mode). Loose coupling of the two stages is promoted by the independence of communication endpoints resulting from the use of this IPC method.
Lag data are passed in binary form as lag sets. Each lag set is passed in one message over a socket. Of course, lag data are passed from the input stage to the lag processing stage only.
Message passing in the backend system is built on the message bus facility of GStreamer. However, because the two backend stages do not run in a single process, the backend software must include an additional mechanism to pass messages between processes. This is accomplished by serializing as text application messages received on the message bus of the transmitting pipeline, sending the text over a socket in a single datagram (i.e., socket message), and then deserializing the text and posting the message to the message bus of the receiving pipeline.
As described in the section called “Application interface”, the input stage process is effectively the master process of the backend system, and application messages should be posted on the message bus of the input stage pipeline only. All messages posted in the lag processing stage pipelines will be sent to the input stage, but nothing about this design precludes also using the message bus internally in any pipeline of the backend system.
Events also cross the interface between backend stages via datagram-oriented Unix domain sockets. Events are passed in a binary form for efficiency (and the flexibility of serializing arbitrary data types is not needed). GStreamer events received by the sink element of the input stage pipeline are converted to a simple binary form, sent via socket messages to the lag processing stage pipelines[8], and are then converted by the source elements in the lag processing stage pipelines into GStreamer events.
As described in the section called “Events”, the backend system uses only downstream GStreamer events, and, therefore, events are only passed between the two backend stages in the downstream direction.
[6] I use the term lag set to describe the Cartesian product of a lag spectra, a set of phase bins, and a set of polarization products i.e. lag spectrum ⊗ phase bins ⊗ polarization products
[7] Of course, it is conceivable that another, improved input stage could be developed; but, in that case, the new input stage would likely be adopted as the standard input stage.
[8] Sending an event from the input stage to the lag processing stage requires a fanout of the event from the single input stage process to all of the lag processing stage processes in the active configuration.