[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.