Testbedservice

Introduction

The testbed service module allows the connection of Shawn to other implementations of the [http://www.wisebed.eu/index.php/testbeddescripton/134-wisebedapis Wisebed APIs] (e.g., [https://www.itm.uni-luebeck.de/projects/testbed-runtime/ testbed-runtime]), or alternatively another Shawn instance. Nodes (either simulated or real nodes) are connected via so-called [http://www.ibr.cs.tu-bs.de/users/tbaum/paper/bcdkkmpp-vtref-10.pdf virtual links], where messages are passed transparently for the application between nodes that are not in physical transmission range.

This is basically useful for several purposes:

Enhance debugging possibilities by running the same application in parallel on both Shawn and a real testbed
Allow for very large simulations by connecting multiple Shawn instances

Setup

Requirements

There are a few additional libraries required when compiling Shawn with the testbed service module:

[http://www.cs.fsu.edu/~engelen/soap.html gsoap] (tested with version 2.7.9)
boost::thread and boost::system

Enable Testbedservice Module

Run cmake configuration (via cd buildfiles; ccmake ../src), then

Set MODULE_APPS_TESTBEDSERVICE to ON
Set OPT_ENABLE_SHAWN_REALTIME to ON
Set OPT_ENABLE_BOOST to ON
Set LIB_PATH_BOOST and INCLUDE_PATH_BOOST to appropriate paths

Press c, then g to generate new makefiles.

Prepare Webservices

Change to directory shawn/src/apps/testbedservice/core, then

Type make headers
Type make soaps

This creates the Webservice code based on the included wsdl files.

Connect Shawn to Wisebed API

There are two possibilities to control Shawn and connect it to an implementation of the Wisebed API. First, it can be controlled via Webservice calls - this is especially useful when scripts for controlling other implementations are already available. Second, setting virtual links can be done via a simulation task, which reduces the need for additional scripts, having everything in one Shawn configuration file.

Control Shawn via Webservice Calls

When controlling Shawn via Webservice Calls, there must be several tasks started/options to set in Shawn:

Setting a virtual link transmission model: transm_model=virtual_link. The transmission model is chainable, and no endpoint. Hence, a final transmission model must be added. E.g., by adding the reliable one: chain_transm_model name=reliable
Using a processor that is derived from the TestbedServiceProcessor. An example is to set processors=exampletestbedservice
Start task testbedservice. The task requires data for iWSN management service, and session management: ** testbedservice_server_host=HOSTNAME ** testbedservice_server_port=PORT ** testbedservice_wsdl="ABSOLUTE_PATH_TO_DIRECTORY_CONTAINING_WSDLS" ** session_server_host=HOSTNAME ** session_server_port=PORT ** session_wsdl="ABSOLUTE_PATH_TO_DIRECTORY_CONTAINING_WSDLS"

Then, one can connect to the session management, get an testbed service (iWSN API) instance, and control it via Webservice Calls; e.g., set virtual links, send a message to a node, etc. An example cab be found in shawn/src/apps/testbedservice/start_testbedservice.conf.

Control Shawn via Simulation Task

As an alternative to the control via Webservice calls, Shawn can also be controlled via simulation tasks. This includes basically setting virtual links via a special task. An example call is as follows: webservice_virtual_link_task
action=add
shawn_node_urn=urn:wisebed:tubs:1
virtual_node_urn=urn:wisebed:tubs:2
remote_uri=http://localhost:30200

The possible parameters are decsribed as follows:

action can be either add or remove,
shawn_node_urn is the node urn in Shawn, whereby the last number is important, because it is Shawn's node id
virtual_node_urn is remote urn to which this virtual link is built
remote_uri is the address of the remote iWSN instance, to which virtual link messages are sent

In addition to virtual links, a controller endpoint can be set. This controller endpoint receives status messages, e.g. when a remote instance sends a virtual message to Shawn. As with session_wsdl, testbedservice_server_port etc., there also parameters that can be added to the testbedservice-call:

controller_uri=http://wbgateway.ibr.cs.tu-bs.de:8089/testcontroller
controller_max_parallel=5

An example cab be found in shawn/src/apps/testbedservice/start_testbedservice.conf.

Under Development/Future Work

Alternatively to the Webservice implementation, there is a much faster implementation based on sockets under development (see shawn/src/apps/testbedservice/sockets). It requires additional libraries:

[http://code.google.com/p/protobuf/ protobuf] (version 2.3.0)
boost::asio