Marionette: Using RPC for Interactive Debugging of Wireless

Embedded Networks

Kamin Whitehouse, Gilman Tolle, Jay Taneja, Cory Sharp, Sukun Kim, Jaein Jeong, Jonathan Hui, Prabal Dutta , and David Culler.

http://www.cs.virginia.edu/~whitehouse/pubs/whitehouse06marionette.pdf

Presentation by Sam Oates

Introduction

Sensor network code generally written as “batch programs”

No runtime visibility or control Significant amount of code required to

implement any remote reads/writes of variables or RPC functionality

Introduction Implications:

Debugging is extremely difficult if one can’t use a simulation tool

No easy way to observe or change node attributes

No generic way to re-task network Adding any of the above functionality is doable

but requires a significant amount of coding by the programmer for each case

Introduction

Introduction Previous solutions:

Software to facilitate messaging between the network and a PC DiagMsg/MessageCenter (Vanderbilt) MIG (comes with nesC compiler)

Software to facilitate accessing variables and functions Config and Command tools (in TinyOS repository)

All of these still require user definition of a packet formats and message handlers for each case

Introduction

Previous solutions (cont’d): SNMS

Allows a user to “export a set of node ‘attributes’ which can be read or written by name using a Java client tool.

Drawback: programmer still must write new code for each attribute that will be remotely accessible

Introduction

Goals for Marionette: Allow reads and writes to any variables in any

module from a PC RPC functionality Require no extra code from user in node

programs Provide object-oriented interface to nodes Minimize node-side overhead

Functionality

Developing the node-level code The only change required in the node modules

is the marking of functions and interfaces to be made remotely accessible with “@rpc()”

At compile time, user enables Marionette scripts

Must be statically compiled

Functionality

Interacting with the network: Open the Marionette python terminal A single “app” object provides the following

fields: All enumerations as well as struct, type and

message definitions Every node module

Functionality

Interacting with the network (cont’d): Each node module provides fields for

Every heap variable Reads and writes provided by peek() and poke()

member functions Every function that was marked with “@rpc()”

By default, calling a module function sends the request to all nodes and an array is returned

An optional address parameter allows specific nodes to be targeted

Implementation Implementation of the system:

Principle of fat client/thin server Peek() and poke()

Heap variable reads and writes ERPC

“Embedded RPC” PyTOS

Python interface on the PC Drip and Drain

Communication to and from nodes

Fat client, thin server architecture Want to do as much work as possible on the PC All information needed for the PC client is

exported to an XML file A compressed version is stored on the node

Requires less than 20kB Avoids issues with different versions of software. Allows any PC with the client application to work with

the network The file includes

The symbol table RPC function information to eliminate the need at

runtime for function and function parameter lookup

Peek() and Poke() The name, address and type of every variable is stored in

the XML file Allows client (the PC) to handle all casting, pointer

dereferencing, array indexing and conversion to and from the network data types

No protection provided between node modules or between nodes and the PC

Provides ability to read and write to memory addresses This module uses only 13 bytes of RAM and 200 bytes of

storage on the node

Embedded RPC(ERPC) Puts as much overhead as possible on the client side All data is sent using the native format of the server (i.e.

the node) Requires client to be able to interpret the data types of the

node CPU Removes overhead from the node side by shifting it to the PC

RPC interface is parsed from the source code and used to make an ERPC server stub that is linked with the application during compilation

Client side gets RPC interface entirely from the XML file Lets clients work with different networks without recompiling

ERPC cont’d: RPC response can be disabled to reduce the

overhead involved with sending a request No queuing or threading of requests Requires roughly 1KB memory plus 100 bytes for

each registered function Compared to LRPC (Lightweight RPC):

LRPC designed to reduce cost of RPC over security boundaries on one machine

ERPC designed to minimize cost between machines but without protection barriers

PyTOS A python library providing an object-oriented interface to a

Marionette network Based on a “parameterizable type system” that generates

the “app” object from the XML file created at compile-time Creates python types that are identical to the native types

on the nodes Provides type-checking Structs and arrays have the same byte format as they do

onboard the nodes Handles serialization and deserialization for

communication with the network

Drip and Drain Routing protocols used for multi-hop messaging

(simple broadcasting is used for one-hop) Both are designed to minimize the memory and

computation resources used by each node Drip

PC to network protocol that uses flooding “Epidemic Protocol” Chosen for reliability with relatively low overhead

Drain Used for node to PC communication Builds a spanning tree that must be manually refreshed

Analysis

Difficult to quantify benefits Authors showed that Marionette used

significantly less code than hand-coding the functionality

The most significant benefit, however, is the generic and simple means that it provides to view and control a deployed network from a PC basestation.

Example: Surge Traffic Monitoring

Measuring difference between packets transmitted by nodes at the root and at the leaves of the tree in the Surge application Each node keeps “forwarded packets” state

variable Every 60 seconds, PC queries all nodes for the

number of packets they forwarded and plots the data

Surge Traffic Monitoring (cont’d)

Example: Stress Testing a tree

This script checks every minute to see how manymessages each node forwards. Once one reaches50, it “kills” that node and resets the count on eachnode to zero.

Limitations Requires static compilation and burning Drip and Drain protocols

Require a lot of packets, which may interfere with the underlying software being debugged

Are not robust No implementation of breakpoints, stack traces,

watchpoints and so forth Current version can only access variables during

nesC’s “task context.” No security provided