Debugging distributed applications is hard

1
Motivation and Goals
User Experience

• Debugging distributed applications is hard
• Component dependencies and race conditions
• Unreliable communications
• Debugging sensornet applications presents further
  challenges
• Resource constraints (energy, memory, processing)
• Increased asynchrony (natural phenomena, sensors)
• Highly limited feedback channels (LEDs, serial)
• Problem How to efficiently enable debugging that
  is both
• Configurable Flexible to enable the programmer
  to diagnose his/her own bugs
• Familiar Seamless to integrate into programmers
  normal debugging practices

command result_t MsgLogger.nprintf(uint8_t mode,
const char format, ...) command void
MsgLogger.set(uint8_t mode, uint8_t
interface) uint8_t mode Debugging identifier
(e.g. USR1, USR2, etc.) const char format
Formatted string (e.g. d s\n, just like
printf - also takes variable-length list of
arguments) uint8_t interface Output channel
(e.g. RADIO, UART, STORAGE)
Complete API for VWdeBug. The nprintf() command
reads state variables to forward the mode to the
appropriate interface. These variables can be
changed using the set command or Java tools on
the PC.

• API Extremely simple - 2 commands
• Typical use
• Step 1 Programmer inserts nprintf() calls into
  application code
• Step 2 Programmer compiles and installs
  application on the motes
• Step 3 In serial/radio case, programmer logs
  data at the PC. In storage case, programmer waits
  and requests logs using a Java tool on the PC.

VWdeBug Architecture
Mote Level
MultiHop Network Level
MOTE
MOTE
Related Work
MOTE

• Common debugging methods used for sensornets
• Simulators (TOSSIM, PowerTOSSIM)
• Hardware-in-the-loop Evaluation (TOSHILT)
• Visualization at the sink (Moteview, Spyglass)
• Code invariants (H-SEND)
• Network state monitoring (PyTOS/Marionette,
  Nucleus)
• Logging (Sympathy)

MOTE
MOTE
MOTE
Programmers PC
MOTE
MOTE
JAVA
Conclusion and Future Work
MOTE

• Despite limitations with nesC (including variable
  arguments) and the serial port (TinyOS resource
  sharing), it is possible to provide useful data
  to the programmer on demand
• printf is an intuitive addition for sensornet
  platforms
• Future Work
• Use of Lamport clocks to provide relative time
  sync
• Reliability in collection layer
• Point-to-point dissemination
• Packet translations at the sink
• Hooks for nesC variable querying/monitoring/sett
  ing

Each mote in the network has multiple types of
message logging (1) local logging (to
onboard flash memory), (2) wireless
transmission to a gateway (via a multihop
network), or (3) sending over an available
serial connection (i.e. in a testbed). For radio
and serial messages, VWdeBug provides message
fragmentation and reassembly services. The
reassembly can handle out-of-order reception. The
PC runs Java tools for collecting and sequencing
logs. Additionally, there is a message generation
tool that allows retasking debugging messages
(i.e. messages should be written to storage
instead of sent over the radio).