wcbe_console is a command line application that can be used to control and monitor the WIDAR backend compute node application. The execution of this application is independent of the backend application itself; the command line application can create and destroy backend application instances, but it can also connect to a running backend application (input stage process).[11] Because the backend compute node application instances are named, it is possible to allow multiple instances of the application to run simultaneously.[12]
The wcbe_console application is a Python application that runs from the command line. The application opens an interactive console that can be used to control and monitor backend compute node application instances. The command synopsis to start the command line application follows.
wcbe_console [[[--name] | [-n]]NAME] [[[--sockdir] | [-s]]SOCKDIR]
nameThe name of the backend compute node application instance to select initially. The instance name can be set interactively from this application's console, so the need for this option is minimal.
sockdirThe directory in which the compute node application instance directories exist. The default value of this option corresponds with the default value used by the wcbe application. Not used in most cases.
Once the application is started, the user is presented with
a command line console. The console implements a command
history saving mechanism, command editing and tab completion
for commands. A help command has
not been implemented, but is planned. The first thing a user
ought to do is create and/or select a backend compute node
application instance. When an application instance has not
been selected, the prompt consists of a simple
>; when an instance has been selected,
the instance name serves as a prefix to the prompt, for
example cbe0>. When the socket that
would connect with the selected compute node application
instance is not found, the command line application will
spawn a new compute node application with the given name;
this provides a simple way to start up the compute node
application. To create and/or select a backend instance, the
command is set name [name].
To destroy a compute node application instance from the
command line application, the instance must first be
selected. After the instance is selected (an action that
could fail if the compute node application were not
responding), the instance can be terminated with the
kill command.
A brief description of other commands available from within the wcbe_console application follow. Further details concerning the effects of these commands may be gleaned by referring to the section called “Message types”.
quitQuit the wcbe_console application. Note that this does not change the state or configuration of any compute node backend application instances.
get nameGet the name of the selected compute node backend application instance.
set name [NAME]Select a compute node application instance by name. Creates a new instance if an instance with the supplied name cannot be found.
get src, set src [URI]Get or set the lag frame source URI.
get flow, set flow [on|off]Get or set the pipeline flow state.
get framedump, set framedump
[ascii|binary|none]Get or set the frame dump option.
get live_ts, set live_ts
[true|false]Get or set the “live timestamps” option (useful for file-based lag frame source only).
get rate, set rate [RATE]Get or set the lag frame rate (useful for file-base lag frame source only).
get configsGet the list of all existing configurations and pending configuration actions. The state of each existing configuration is indicated in the resulting output.
get config, set config [NAME]Get or set the active configuration.
get allGet all compute node application instance parameters.
create [NAME]
[FILE]Create a configuration named “NAME” using the XML backend configuration document in the file “FILE”.
destroy [NAME]Destroy the named configuration. Note that the named configuration will not be immediately destroyed if it is the active configuration; however, it will be destroyed after another configuration is activated. You cannot undo a destroy operation, even when the destruction has been deferred because the configuration is active at the time the command is given.
killTerminate the currently selected backend compute node application instance.
get pipelines [config]
Get the list of pipelines in the configuration named
config. Note that the input
stage pipeline, INPUT_STAGE, only appears in the
pipeline list for the active configuration.
get elements [pipeline]
Get the list of elements in the pipeline named
pipeline. The format of the
pipeline parameter is
[config name]/[pipeline
name].
get pads [element]
Get the list of pads for the element named
element. The format of the
elment parameter is
[config name]/[pipeline name]/[element
name].
get caps [pad]
Get the caps for the pad named
pad. The format of the
pad parameter is
[config name]/[pipeline name]/[element
name]/[pad name].
get peer [pad]
Get the peer of the pad named
pad. The format of the
pad parameter is
[config name]/[pipeline name]/[element
name]/[pad name]. The format of the
returned string is [element name]/[pad
name], where the returned element name
refers to an element in the same pipeline as the pad
named in the query.
get properties
[element]
Get the list of properties of the element named
element. The format of the
element parameter is
[config name]/[pipeline name]/[element
name].
get property
[property]
Get the value of the property named
property. The format of the
property parameter is
[config name]/[pipeline name]/[element
name]/[property name].
set property [property]
[value]
Set the value of the property named
property to
value. The format of the
property parameter is the
same as described above for the get
property command. The parameter
value is a string that should
be convertible to the proper type for the property.
[11] The command line application is, in essence, a front end to the backend compute node application. To limit overloading the terms front end and back end yet further, this document will refer to the front end application as the “command line application”, or something similar.
[12] It would be wise to use different lag frame sources for different backend application instances; since the lag frames arrive via UDP socket, there is no way to guarantee that a particular lag frame is pulled from the socket by a particular backend application instance. There is, however, no mechanism to prevent such (mis)configuration.