Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 216 times |
Download: | 0 times |
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