No abstract

Do you need to know how to write systems, services, and applications using the TinyOS operating system? Learn how to write nesC code and efficient applications with this indispensable guide to TinyOS programming. Detailed examples show you how to write TinyOS code in full, from basic applications right up to new low-level systems and high performance applications. Two leading figures in the development of TinyOS also explain the reasons behind many of the design decisions made and, for the first time, how nesC relates to and differs from other C dialects. Handy features such as a library of software design patterns, programming hints and tips, end-of-chapter exercises, and an appendix summarizing the basic application-level TinyOS APIs make this the ultimate guide to TinyOS for embedded systems programmers, developers, designers, and graduate students.

Many paralle1 programs are written in SPMD style, i.e. by running the same sequential program on alI processes. SPMD programs include synchronization, but ii is easy to write incorrect synchronization patterns. We propose a system that verifies a program's synchronization pattern. We also propose language features to make the synchronization pattern more explicit and easily checked. We have implemented a prototype of our system for Split-C and successfully verified the synchronization structure of realistic programs.

Declarative Networking is a programming methodology that enables developers to concisely specify network protocols and services, which are directly compiled to a dataflow framework that executes the specifications. This paper provides an introduction to basic issues in declarative networking, including language design, optimization, and dataflow execution. We present the intuition behind declarative programming of networks, including roots in Datalog, extensions for networked environments, and the semantics of long-running queries over network state. We focus on a sublanguage we call Network Datalog (NDlog), including execution strategies that provide crisp eventual consistency semantics with significant flexibility in execution. We also describe a more general language called Overlog, which makes some compromises between expressive richness and semantic guarantees. We provide an overview of declarative network protocols, with a focus on routing protocols and overlay networks. Finally, we highlight related work in declarative networking, and new declarative approaches to related problems. intRoDuctionOver the past decade there has been intense interest in the design of new network protocols. This has been driven from below by an increasing diversity in network architectures (including wireless networks, satellite communications, and delay-tolerant rural networks) and from above by a quickly growing suite of networked applications (peer-topeer systems, sensor networks, content distribution, etc.) Network protocol design and implementation is a challenging process. This is not only because of the distributed nature and large scale of typical networks, but also because of the need to balance the extensibility and flexibility of these protocols on one hand, and their robustness and efficiency on the other hand. One needs to look no further than the Internet for an illustration of these hard trade-offs. Today's Internet routing protocols, while arguably robust and efficient, make it hard to accommodate the needs of new applications such as improved resilience and higher throughput. Upgrading even a single router is hard. Getting a distributed routing protocol implemented correctly is even harder. Moreover, in order to change or upgrade a deployed routing protocol today, one must get access to each router to modify its software. This process is made even more tedious and error-prone by the use of conventional programming languages.In this paper, we introduce declarative networking, an application of database query language and processing techniques to the domain of networking. Declarative networking is based on the observation that network protocols deal at

The wireless sensor network community approached networking abstractions as an open question, allowing answers to emerge with time and experience. The Trickle algorithm has become a basic mechanism used in numerous protocols and systems. Trickle brings nodes to eventual consistency quickly and efficiently while remaining remarkably robust to variations in network density, topology, and dynamics. Instead of flooding a network with packets, Trickle uses a "polite gossip" policy to control send rates so each node hears just enough packets to stay consistent. This simple mechanism enables Trickle to scale to 1000-fold changes in network density, reach consistency in seconds, and require only a few bytes of state yet impose a maintenance cost of a few sends an hour. Originally designed for disseminating new code, experience has shown Trickle to have much broader applicability, including route maintenance and neighbor discovery. This paper provides an overview of the research challenges wireless sensor networks face, describes the Trickle algorithm, and outlines several ways it is used today. WiReLess sensoR netWoRKsAlthough embedded sensing applications are extremely diverse, ranging from habitat and structural monitoring to vehicle tracking and shooter localization, the software and hardware architectures used by these systems are surprisingly similar. The typical architecture is embodied by the mote platforms, such as those shown in Figure 1. A microcontroller provides processing, program ROM, and data RAM, as well as analog-to-digital converters for sensor inputs, digital interfaces for connecting to other devices, and control outputs. Additional flash storage holds program images and data logs. A low-power CMOS radio provides a simple link layer. Support circuitry allows the system to enter a low-power sleep state, wake quickly, and respond to important events.Four fundamental constraints shape wireless embedded system and network design: power supply, limited memory, the need for unattended operation, and the lossy and transient behavior of wireless communication. A typical power envelope for operating on batteries or harvesting requires a 600 µW average power draw, with 1%% of the time spent in a 60 mW active state and the remainder spent in a very low power 6 µW passive state.Maintaining a small memory footprint is a major requirement of algorithm design. Memory in low-cost, ultra-lowpower devices does not track Moore's Law. One indication of this is that microcontroller RAM costs three orders of magnitude more than PC SRAM and five orders more than PC DRAM. More importantly, SRAM leakage current, which grows with capacity, dictates overall standby power consumption and, hence, lifetime. Designs that provide large RAMs in conjunction with 32-bit processors go to great lengths to manage power. One concrete example of such nodes is the Sun SPOT, 20 which enters a low-power sleep state by writing RAM contents to flash. Restoring memory from flash on wakeup uses substantial power and takes considerable time. The al...