Network Types: Language Support for Messaging in the Heterogeneous Networks

UC Berkeley WEBS Project

Last updated 16 December 2004

Description
Network Types are an extension to the nesC programming language designed to support heterogeneous networking. Network Types are available in nesC version 1.1.3, available from the downloads area of nesC's SourceForge project page.

Introduction

Development of network communication in a homogeneous sensor network environment is straightforward as the nodes can share message layouts simply by letting the compiler lay out messages in an arbitrary fashion and using the same executable code on all nodes. But in a heterogeneous network environment, this simple approach does not work, as different processors may have different representations or alignment requirements for basic types:
One approach to solve this problem is to manually insert marshalling/unmarshalling routines to convert values between network and host representations in each protocol layer. A TinyOS component can call these functions just after receiving from, and just before sending the packets. However, doing so has a few disadvantages. First, the code may not be portable as C provides few guarantees as to data structure layout. This portability problem can be avoided by using only arrays of characters addressed via constant offsets, but this makes code unreadable and hard to maintain. Second, adding the manual conversion functions is a tedious and error-prone process

Network types, our extension to nesC for platform-independent networking, address the issue of portability, heterogeneity, and maintenability. Using network types the programmer defines a simple data structure using syntax very similar to existing C type declarations, which matches the packet layout, and just accesses it like a regular C type. The compiler ensures that this type has the same representation on all platforms and generates any necessary conversion code.

Network types have no alignment restrictions, network structures contain no padding, and the network base types use a 2's complement, little-endian representation. Thus their representation is platform-independent, and any arbitrary section of memory can be accessed via a network type. The endianness of the base types is little-endian for two reasons: all our current platforms are little-endian, and TinyOS does not yet need to support arbitrary existing protocols. Future versions will also include big-endian base types.

Downloads and Instructions

nesC 1.1.3, which includes Network Types, is available from nesC's SourceForge project page. User documentation for network types is available in the doc/network-types.txt file, reproduced here.

If you wish to use network types to support heterogeneous micaz and telos networks in TinyOS, please follow these instructions:

With these patches, the CntToRfm, CntToLedsAndRfm, RfmToLeds, OscilloscopeRF and Surge applications can communicate between micaz and telos. Additionally, Surge is modified so that it can run on telos (you must compile with make SENSORBOARD=telos, however). The patch also changes basic networking (GenericComm), simple flooding (tos/lib/Brodacast) and routing (tos/lib/MintRoute) to use network types.

Changing other applications and libraries to use network types is straightforward: in all types used to describe message formats, change struct to nw_struct, uint8_t to nw_uint8_t, int16_t to nw_int16_t, etc. For example, the original IntMsg.h used by CntToRfm, CntToLedsAndRfm and RfmToLeds was changed as follows:

Before the changes: 
typedef struct IntMsg {
  uint8_t src;
  uint16_t val;
} IntMsg;
After the changes: 
typedef nw_struct IntMsg {
  nw_uint8_t src;
  nw_uint16_t val;
} IntMsg;