[user/user-app-bnet.tex] %\lsection{user:Bnet}{Application: network event building} \label{user-app-bnet-chapter} \lsection[DABC eventbuilder network (BNET)]{user-app-bnet-dabc}{\dabc\ eventbuilder network (BNET)} The full functionality of \dabc\ is shown in the case that the DAQ uses an event building network (BNET), transferring the partial data from $n$ readout nodes to $m$ event building nodes, such that each event builder can work on the full detector data. This scenario is discussed in detail in chapter \paref{prog_exabnet} of the \dabc\ programmer's manual. Appropriate configuration files can be found at \\ {\tt \$DABCSYS/applications/bnet-test} directory. An example setup file {\tt SetupBnet.xml} may look like this: \begin{small} \begin{verbatim} \end{verbatim} \end{small} The setup of such BNET contains several \keyw{} nodes. Generally, the BNET has two types of nodes: \bbul \item One "Controller" node that has a master controller functionality, implemented in the \keyw{} of class "bnet::Cluster". The controller node must be specified at the \dabc\ GUI setup to receive the direct cluster control commands, e.~g.~ state machine transitions commands. In the \dabc\ BNET framework, the controller also keeps a general parameter \keyw{} for the data connection device of the entire DAQ cluster; this can be "dabc::SocketDevice" for tcp/ip, or "verbs::Device" for an {\em InfiniBand} cluster. \item Several "Worker" nodes of an experiment specific \keyw{}. They may be configured for different jobs in the BNET; this example provides an \class{Application} class "bnet::TestWorker" with some boolean parameters to define the functionality. \ebul Note the usage of wildcards "*" in the \keyw{} names to define properties that should be valid for all nodes matching the pattern, e.~g.~ the libraries to load, or the common application setup for all worker nodes. Here there are 4 workers which all produce random event data (enabled in \keyw{}), and all send their data to all others (enabled in \keyw{}). In parallel, they all receive data from the other workers to build the complete event (enabled in \keyw{}). Such BNET setup is best started by means of the \dabc\ GUI. The name of the controller \keyw{} node and the setup file name must be specified in the control panel of the GUI (see section \paref{user:controlDabc}). Then all nodes can be started just by the "Launch" button \icon{connprm}. The configuration and run control of the nodes is done by the state machine buttons of the control panel. \lsection[DABC eventbuilder network (BNET) with MBS]{user-app-bnetmbs}{\dabc\ eventbuilder network (BNET) with \mbs\ } \index{TODO!Mbs BNET example with real mbs nodes instead generators} \index{TODO!Adjust old mbs bnet configurator scripts for new xml format?} A more realistic example of a BNET uses data which is read from $n$ external \mbs\ nodes, each connected to one \dabc\ readout node, and transferred to $m$ \dabc\ eventbuilder nodes. Example file \\ {\tt \$DABCSYS/applications/bnet-mbs/SetupBnetMbs.xml} shows the configuration for an \mbs\ event building with 2 \dabc\ readout nodes, connected with 2 \mbs\ nodes each (simulated by \dabc\ generator modules here), and 2 \dabc\ event builder nodes. A detailled description of this setup is given in section \paref{prog_exabnet_mbs} of the \dabc\ programmer manual. The usage of such configuration is similar to the BNET example as described above in section \paref{user-app-bnet-dabc}: The list of \keyw{} nodes (or the corresponding \keyw{}, resp.) must be edited for the actual node names. Additionally the names of the \mbs\ nodes for readout should be specified. Then the BNET setup may be launched and controlled by the \dabc\ GUI.