Skip to content
This repository was archived by the owner on Aug 25, 2020. It is now read-only.

Testbedservice

Jump to bottom
Marvin Frick edited this page May 28, 2013 · 1 revision

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:

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

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

  • Set OPT_ENABLE_PROTOBUF to ON
  • Set LIB_PATH_GOOGLE_PROTOBUF and INCLUDE_PATH_GOOGLE_PROTOBUF to appropriate paths
Clone this wiki locally