Transact: A Transactional Programming Framework for Wireless Sensor/Actor Networks

1. Transact: A Transactional Programming Framework for Wireless Sensor/Actor Networks Murat Demirbas SUNY Buffalo CSE Dept. transactions WSANs data-race conditions optimistic concurrency control write-all wireless broadcast consistency & coordination conflict serializability Multi-robot cooperative control distributed control

2. Ubiquitous computing • Instead of us interacting with the computers in the virtual world, the computers should interact with us in our physical world • PC processors are only 2% of all processors, the rest goes to automotive; communications; electronics; industrial equipment • Communication technology is now available via CMOS radios • Networked deployments have already started in the form of WSNs • Environmental monitoring; Precision agriculture; Military surveillance

3. Wireless sensor networks (WSNs) A sensor node (mote) • 8K RAM, 4Mhz processor • magnetism, heat, sound, vibration, infrared • wireless (radio broadcast) communication up to 100 feet • can cost ~$1 (right now costs ~$100)

4. Wireless sensor/actor networks (WSANs) • WSNs serve only as data collection & aggregation networks • WSANs possess actuation capability as well; applications are: • Factory automation & process control systems • vibration control, valve control • Multi-robot cooperative control • robotic highway safety/construction markers • automated mobile search & surveillance • Multimedia WSNs • video-based coordinated surveillance/tracking of suspected individuals in an urban setting • resource/task allocation in multimedia WSNs (as our running example) WSANs

5. WSANs programming challenges • Consistency and coordination In contrast to WSNs, where eventual consistency & loose synchrony is sufficient, distributed control & coordination are needed for WSANs • Effective management of concurrent execution • For safety reasons concurrency needs to be tamed to prevent unintentional nondeterministic executions • On the other hand, for real-time guarantees concurrency needs to be boosted to achieve timeliness data-race conditions

6. Transact: A transactional programming framework for WSANs • Transacteliminates unintentional nondeterministic executions while retaining the concurrency of executions • Conflict serializability: any property proven for the single threaded coarse-grain executions also holds for the concurrent fine-grain executions • Transactfacilitates consistency and coordination • Transact introduces a novel “consistent write-all” paradigm that enables a node to update the state of its neighbors consistently and simultaneously • “Consistent write-all” may enable development of more efficient control and coordination programs transactions

7. Outline of this talk • Inner-workings of Transact • Implementation and simulation results • Multihop networks extensions

8. Overview of Transact • A transaction is an execution of a nonlocal method • requires inter-node communication, and is structured as read*[write-all] • Each read operation reads variables from some nodes in singlehop, and write-all operation writes to variables of a set of nodes in singlehop • Optimistic concurrency control (OCC) idea • Read values and write to a sandbox • Commit if the transaction did not conflict with another transaction • Abort, otherwise • A write-all operation may fail when a conflict is reported • Since write-all is placed at the end, if it fails no state is changed; transaction aborts without any side-effects optimistic concurrency control

9. Challenges &opportunities inTransact • In contrast to database systems, in distributed WSANs there is no central database repository or arbiter • The control and sensor variables, on which the transactions operate, are maintained distributedly over several nodes • Singlehop wireless communication opens novel ways for optimizing the implementation of Transact • A broadcast is received by the recipients simultaneously • Useful for ordering operations deterministically at all nodes • Broadcast allows snooping • Useful for detecting conflicts between transactions in a decentralized manner wireless broadcast

10. Conflicting transactions • Any two transactions t1 and t2 are conflicting iff • a read-write incompatibility introduces a causality from t1 to t2 • and a write-write or a read-write incompatibility introduces a causality from t2 to t1 t1.write-all(l.x) t1.read(l.x) j read-write incompat. write-write incompat. k t2.write-all(l.x) conflict serializability

11. Conflict detection • To enable decentralized and low-cost detection of conflicts, nodes act as proxies by snooping over broadcast messages l’ t1.write-all(l’.y) t2.write-all(l.x,l’.y) j conflict_msg k t1.read(l.x) t2.write-all(l.x,l’.y) l conflict serializability

12. Timeline of a transaction Time-out based commit conflict_msg read-request(…) write-all(…) abort read-reply ack ack read-reply ack ack Time-out based commit Timeout-based commit is used for consistency

13. bool become_leader(){ X=read(*.leader); if (X=Ø) then return write-all(*.leader=ID); return FAILURE; } bool consensus(){ X=read(*.vote); if (|X|=1) then return write-all(*.vote=X); return FAILURE; } bool resource_allocation(){ X=read(*.allocated); X’=subset of nonallocated-X; return write-all(X’.allocated =ID); } Transact programs

14. Probabilities of being independent/dependent/conflicting given the number of shared variables between two transactions Analysis results

15. Implementation results • Tmote-invent, Tmote-Sky, CC2420 radio • Our Transact component in TinyOS is 1500 lines of NesC code • We also implemented resource/task allocation over Transact • Initially, each initiator is assigned a random subset of the resource nodes to read, and a random subset of their read-sets to write to—in order to allocate those resources. • Initiators cannot complete their tasks with partial resources. The application code is aware of the transaction status and the failed transactions are retried • All nodes are within singlehop • We synchronize the initiators through a synchronization message broadcasted from the basestation, and this way start all the transactions at the same instant.

16. Settling time

17. Consistency of transactions

18. Simulation results • We perform large-scale (multihop network) experiments using the Prowler simulator for WSNs • Our code for Transact is 1500 lines of distributed/per-node code • Our experiments are performed on a 10x10 grid of 100 nodes, where each node has 8 neighbors. • We compare Transact with 4 other transactional protocols: • Locking: strict 2-phase locking approach to transaction processing • Reliable: waives conflict-detection; cancels if not all write-acks received • Ev-reliable: forgoes the cancellation, and instead re-transmits write-all • Unreliable: waives the write-acks, and performs a bare-bones write-all

19. Settling times

20. Consistency of transactions

21. Middleware for building Multihop programs • Transact can be used for efficient realizations of high-level programming abstractions, Linda & virtual node (VN) • In Linda, coordination is achieved via in/out operations using which tuples can be added/removed from a shared tuplespace • Transact is useful for maintaining the consistency of the shared tuplespace against concurrent execution of in/out operations at different nodes • VN provides stability and robustness against mobility of nodes

22. Related work • Database transactions are centralized with single arbiter • Software-based transactional memory is limited to threads interacting through memory in a single process • Programming abstractions for WSN provide loosely-synchronized, eventually consistent view of system states • Seuss also provides a reduction theorem • requires a compile-time semantic compatibility check and inserts pre-synchronization between incompatible methods • requires a proof of partial orders on methods at the compile-time

23. Our ongoing work • Roomba-Create + motes running Transact to implement multi-robot cooperative control • Future work • Verification support: Transact already provides conflict serializability, the burden on the verifier is significantly reduced • Transact patterns: programmers can adapt commonly occurring patterns for faster development Multi-robot cooperative control

24. Our other research interests • MAC layers for robust single-hop communication • Geometric infrastructures for resilient WSN services • Programming abstractions for robust computing • Real-world deployments of robust WSN • Theory of self-stabilization

25. MAC-layer support for lightweight singlehop collaboration • The idea is to use receiver-side collision detection (RCD) for lightweight singlehop collaborative feedback • Pollcast: Does P hold for the neighborhood? • Initiator performs binary probing instead of full-fledged read in Transact • Nodes where P holds answer simultaneously • Initiator uses RCD to detect whether there are answers • Countcast: The idea is generalizable to achieve an approximate count of the number n of nodes that P hold in logn rounds

26. Geometric infrastructures for resilient WSN services For scalability, local operations are needed over global structures By exploiting the geometry of WSNs, we can design efficient, minimal, and resilient infrastructures • Querying structures: Glance, DQT, PeeR-tree • O(d) time for querying, where d is the distance to the nearest answer • Graceful resilienceto the face node failures via simplicity of design • Tracking structures: Stalk, Trail • O(d) time for querying • O(m*logm) for update, where m is the distance the evader moved • Local self-healing via containment wave idea & stretch-factor idea

27. Real world deployments of robust WSN • Line in the sand: surveillance service for DARPA-NEST • Detect, track, and classify trespassers as car, soldier, civilian • LiteS: 100 nodes in 2003, ExScal: 1000 nodes in Dec 2004 • Insight: INternet Sensor InteGration for HabitaT monitoring • Single-hop network; basestation serves webpage • Deployed for monitoring the greenhouse at UB • Elvis: In-building personnel tracking extension • Cellphone as a healthcare platform : Ongoing work on air pollution risk assesment of individuals via using time-activity data collected from GPS built-in cellphones

28. Theory of self-stabilization • Self-stabilization is the ability of a system to recover within bounded steps from arbitrary states to states from where the system exhibits desired behavior • Arbitrary state corruption provides a clean abstraction of how many systems are perturbed by their diverse environments • Self-stabilization provides a viable method to deal with state corruption • Case-by-case analysis of faults and recovery is shunned in favor of a uniform mechanism • Self-stabilizing systems do not need any initialization • Self-configuring! • Graybox self-stabilization • Improves over the whitebox and blackbox approaches tried so far • Compositional reasoning for self-stabilization • Modular design and verification of self-stabilization

29. Transact: A Transactional Programming Framework for Wireless Sensor/Actor Networks Murat Demirbas SUNY Buffalo CSE Dept. transactions WSANs data-race conditions optimistic concurrency control write-all wireless broadcast consistency & coordination conflict serializability Multi-robot cooperative control distributed control