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. 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

 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 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 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 many messages each node forwards. Once one reaches 50, it “kills” that node and resets the count on each node 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