Claustrophobia: Tiny Tuple Spaces for Embedded Sensors

1
Claustrophobia Tiny Tuple Spaces for Embedded
Sensors

• Vladimir Bychkovskiy and Thanos Stathopoulos

2
Motivation

• How to program interactions for sensor network
  applications?
• message passing (traditional approach)
• pro flexibility gt energy
• con complexity gt development time
• Types of interactions
• reliable transport, routing
• voting, distributed mutual exclusion (scheduling)
• leader election (beamforming, tracking)
• many-to-many reliable communication (processing
  and aggregation)
• Goal
• develop a set of high level communication
  primitives, based on Linda1, to augment message
  passing

3
Related Work

• Why re-implement? Why not use JavaSpaces2!
• wireless communication
• long periods of link fading
• low bandwidth
• different failure modes
• failed node may never come back
• resource intensive
• Why not use Directed Diffusion3?
• very good for data collection (pull)
• unreliable one-way stream-based communication
• lack of consistency guarantees
• very hard to implement agreement protocols

4
Tuple Spaces in Sensor Networks

• Linda1
• pro agreement protocols are easy to implement
• cons
• requires reliable communication
• too communication intensive for general use
• provides more than we want to pay for
• a lot of communication gt high energy usage
• Adapted Linda
• pro
• agreement protocols are still easy to implement
• specifically designed for failure modes for
  sensor networks
• lower energy usage when only probabilistic
  guarantees are required
• cons under-the-hood complexity

5
The Demo Scheduling

• Scheduling and mutual exclusion
• Serialization of execution
• Demonstrates
• take()
• write()
• read()implicit in take()

if (ID INITIATOR) write(count,
1) while(1) take(count, ?cnt)
display(cnt) sleep() cnt write(count,
cnt)
6
Problems and Solutions

• Problems
• Low bandwidth, flaky connectivity
• Reliability is expensive in terms of energy
• Solution Replication of tuples on multiple nodes
• majority rule4
• Not necessary to get all replies when doing a
  read() or write() operation
• Only r w needed, s.t. r w gt N
• Corrolary cheap reads or writes
• Can be tuned to optimize energy consumption
• Reliable write() impossible?
• Even demanding that a write() needs to reach w
  nodes is expensive
• 2-phase commit does not work in the presence of
  arbitrary link and node failures
• Last ack problem

7
Proposed Solution read() and write()

• Assumptions
• packet loss
• Low level write()operation is best effort
• Single attempt, no guarantees just like
  broadcast
• Versioning
• Tuples have nodeId and sequence numbers
• read() needs the majority to agree on the value
• Tie-breaker if majority cant agree, pick value
  with lowest nodeId and lowest sequence number
• guarantees consistency
• Reliable write() is possible
• Keep writing and reading until the read() returns
  the value written

8
Proposed solution take()

• take() a special write()
• more strict than read()
• majority must always be reached in order to make
  a decision
• request includes requesters nodeId and sequence
  number
• If tuple exists in local cache
• mark it as taken
• send it to the first requestor
• Notes
• taken tuple is not discarded from the cache
• subsequent requests from the same node will be
  honored only if the sequence number matches (a
  retransmission)
• subsequent requests from other nodes will get a
  NACK reply
• At most once semantics
• Exactly once, if the write is successful
• Solution verify the write()!

9
Conclusions Future Work

• Conclusions
• An implementation of a Linda-like system is
  feasible on very small sensor nodes.
• Group communication is cheap within a single
  broadcast domain most of the time.
• Future work
• precisely evaluate energy requirements
• implement an energy-aware version of Linda
• use probabilistic responses to save energy
• explore fault-tolerance issues
• evaluate a possibility of tuple space over
  multiple broadcast domains

10
References

• 1 "Generative communication in Linda", David
  Gelernter, ACM Transactions on Programming
  Languages and Systems(TOPLAS), January 1985,
  Volume 7, Issue 1
• 2 JavaSpaces v1.1 Specification (JavaSpaces is
  a trademark of Sun Microsystems.)
  http//www.sun.com/jini/specs/js1_1.pdf
• 3 "Directed diffusion a scalable and robust
  communication paradigm for sensor networks",
  Chalermek Intanagonwiwat and Ramesh Govindan and
  Deborah Estrin. Proceedings of the sixth annual
  international conference on Mobile computing and
  networking, 2000,1-58113-197-6, p. 56-67, Boston,
  Massachusetts, United States
• 4 Weighted voting for replicated data, David
  K. Gifford, Proceedings of the seventh symposium
  on Operating systems principles (SOSP),
  1979,0-89791-009-5, pp150-162, Pacific Grove,
  California, United States