Host

Concept

A central host receives all data messages and manages the client connections. Each client can subscribe to one or more data nodes in order to use that node’s data in its own internal processes. Furthermore, each client can publish data onto the network by creating a node. A new client can query the network concerning which nodes are present and is informed when new nodes appear after the client has been registered.

A data node can be understood as a collection of data that belongs together, e.g., data coming from the same sensor device or the output of a particular device such as the DMX control stream for theatrical light. Within each node there are slots which represent single data values, for example, a data node representing a 3-axis accelerometer has three slots, with each slot corresponding to one axis. If a client is only interested in one slot of a node, he can subscribe specifically to that slot.

Integration with the MiniBee network

We have specifically integrated the connection to the Sense/Stage MiniBee network, by providing options to configure, send and receive data from the sensor network, through the host of the DataNetwork.

The host communicates with the wireless network through a serial protocol. It manages all the incoming and outgoing data from and to the wireless nodes. The data from a MiniBee will appear onto the network as a DataNode, while each attached sensor is a data slot in this data node. Clients can then subscribe to this node to receive its data. Furthermore, a client can send a message to map the data that is on a data node the client has created to the digital outputs or pulse width modulation outputs of a MiniBee, in order to control, for example, lights or motors.

Auto-recovery

Practical lessons derived from rehearsal and performance experiences remind us that software applications and processes can be unexpectedly and fatally interrupted (i.e., crash). For this reason, a fast and automatic recovery of all previously instantiated connections is critical.

The following methods are implemented to enable fast and automated recovery in such situations. Following (re)start of the host server and (re)establishment with the network, an announce message is broadcast on several ports. In addition, the server updates a publicly readable file with the current active listening port. Moreover, the host can restore previously connected clients from information stored in a server readable file.

In turn, the client has read access over the network to the host configuration file and automatically retrieves the port information to which it has to register. Further, the client implements an auto-configuration process triggered upon receipt of a host announce message and a response from the host indicating the client has successfully registered.

SuperCollider implementation

The SuperCollider (host) implementation is done via a set of custom written classes:

  • SWDataNetwork base class for the network.
  • SWDataNode base class for a data node.
  • SWDataSlot base class for a data slot.
  • SWDataNetworkSpec implements the labelling of the nodes and slots of the network.
  • SWDataNetworkOSC implements the OSC interface
  • SWDataNetworkOSCClient keeps track of a connected client

Data nodes have both unique IDs (integer numbers) and human readable labels (e.g., node “3” has the label “accelerometer”). Data slots are automatically numbered, according to the order in which they appear, as they are set in the network; they can also be given a label. The labelling is not done automatically, so that the naming becomes a conscious and integral part of establishing shared nomenclatures for the collaboration. This encourages consideration by the users of what the data represents and its potential use. The label specification (the “spec”) can be stored between sessions so it can be recalled again upon startup.

Each data node and slot has methods to print debugging messages, set an action to be performed upon new incoming data, scale and/or remap the data and create a control bus on the audio server with the data. Each data node also can specify an action to be taken in case there has been no input to the node for a certain amount of time (e.g., trying to reconnect to an external device).

If a client creates a node, that node is linked to the client (the client becomes the “setter” of the node), and no other client can set data to that node.

Client configuration can also be stored to a file and be used for recovery on startup.

All data from the network can be written to a log-file in a text format containing lines for each time step with tab-separated data values. The log can be opened and played back with the class SWDataNetworkLog.

Finally, a graphical user interface has been implemented to monitor the status of the data network and the state of each node.