You are here

GNUnet's TESTBED Subsystem

Primary tabs

The TESTBED subsystem facilitates testing and measuring of multi-peer deployments on a single host or over multiple hosts.

The architecture of the testbed module is divided into the following:

  • Testbed API: An API which is used by the testing driver programs. It provides with functions for creating, destroying, starting, stopping peers, etc.
  • Testbed service (controller): A service which is started through the Testbed API. This service handles operations to create, destroy, start, stop peers, connect them, modify their configurations.
  • Testbed helper: When a controller has to be started on a host, the testbed API starts the testbed helper on that host which in turn starts the controller. The testbed helper receives a configuration for the controller through its stdin and changes it to ensure the controller doesn't run into any port conflict on that host.

The testbed service (controller) is different from the other GNUnet services in that it is not started by ARM and is not supposed to be run as a daemon. It is started by the testbed API though a testbed helper. In a typical scenario involving multiple hosts, a controller is started on each host. Controllers take up the actual task of creating peers, starting and stopping them on the hosts they run.

While running deployments on a single localhost the testbed API starts the testbed helper directly as a child process. When running deployments on remote hosts the testbed API starts Testbed Helpers on each remote host through remote shell. By default testbed API uses SSH as a remote shell. This can be changed by setting the environmental variable GNUNET_TESTBED_RSH_CMD to the required remote shell program. This variable can also contain parameters which are to be passed to the remote shell program. For e.g:

export GNUNET_TESTBED_RSH_CMD="ssh -o BatchMode=yes -o NoHostAuthenticationForLocalhost=yes %h"

Substitutions are allowed int the above command string also allows for substitions. through placemarks which begin with a `%'. At present the following substitutions are supported

  • %h: hostname
  • %u: username
  • %p: port

Note that the substitution placemark is replaced only when the corresponding field is available and only once. Specifying %u@%h doesn't work either. If you want to user username substitutions for SSH use the argument -l before the username substitution. Ex: ssh -l %u -p %p %h

The testbed API and the helper communicate through the helpers stdin and stdout. As the helper is started through a remote shell on remote hosts any output messages from the remote shell interfere with the communication and results in a failure while starting the helper. For this reason, it is suggested to use flags to make the remote shells produce no output messages and to have password-less logins. The default remote shell, SSH, the default options are "-o BatchMode=yes -o NoHostBasedAuthenticationForLocalhost=yes". Password-less logins should be ensured by using SSH keys.

Since the testbed API executes the remote shell as a non-interactive shell, certain scripts like .bashrc, .profiler may not be executed. If this is the case testbed API can be forced to execute an interactive shell by setting up the environmental variable `GNUNET_TESTBED_RSH_CMD_SUFFIX' to a shell program. An example could be:

export GNUNET_TESTBED_RSH_CMD_SUFFIX="sh -lc"

The testbed API will then execute the remote shell program as: $GNUNET_TESTBED_RSH_CMD -p $port $dest $GNUNET_TESTBED_RSH_CMD_SUFFIX gnunet-helper-testbed

On some systems, problems may arise while starting testbed helpers if GNUnet is installed into a custom location since the helper may not be found in the standard path. This can be addressed by setting the variable `HELPER_BINARY_PATH' to the path of the testbed helper. Testbed API will then use this path to start helper binaries both locally and remotely.

Testbed API can accessed by including "gnunet_testbed_service.h" file and linking with -lgnunettestbed.