| Philip Levis and Gilman Tolle | |
| Draft-Created: | 10-Dec-2004 |
|---|---|
| Draft-Version: | 1.6 | +
| Draft-Version: | 1.7 |
| Draft-Modified: | 2006-12-12 | +
| Draft-Modified: | 2007-06-14 |
| Draft-Discuss: | TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu> |
Note
This memo documents a part of TinyOS for the TinyOS Community, and @@ -318,15 +313,15 @@ requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.
The memo documents the interfaces, components, and semantics for disseminating small (smaller than a single packet payload) pieces of data in TinyOS 2.x. Dissemination is reliably delivering a piece of data to every node in a network.
Dissemination is a basic sensor network protocol. The ability to reliably deliver a piece of data to every node allows administrators to reconfigure, query, and reprogram a network. Reliability is @@ -355,15 +350,15 @@ rejoins the network it will only see the most recent. The rest of this document describes a set of components and interfaces for a dissemination service of this kind.
Small-value dissemination has two interfaces: DisseminationValue and DisseminationUpdate. The former is for consumers of a disseminated value, the latter is for producers. They are as follows:
interface DisseminationValue<t> {
command const t* get();
- event void changed();
+ event void changed();
}
interface DisseminationUpdate<t> {
@@ -391,8 +386,8 @@ network might reach consensus when nodes have different values. The
dissemination protocol therefore MUST have a tie-breaking mechanism,
so that eventually every node has the same data value.
A dissemination service MUST provide one component, DisseminatorC, which has the following signature:
@@ -401,7 +396,7 @@ generic configuration DisseminatorC(typedef t, uint16_t key) {
provides interface DisseminationUpdate <t>;
}
-The t argument MUST be able to fit in a single message_t[tep111_] after +
The t argument MUST be able to fit in a single message_t [TEP111] after considering the headers that the dissemination protocol introduces. A dissemination implementation SHOULD have a compile error if a larger type than this is used.
@@ -421,8 +416,8 @@ implementation {Two different instances of DisseminatorC MUST NOT share the same value for the key argument.
One issue that comes up when using this interfaces is the selection of a key for each value. On one hand, using unique() is easy, but this means that the keyspaces for two different compilations of the same @@ -438,7 +433,7 @@ namespace are separated by their most significant bit. A component author might write something like this:
#include <disseminate_keys.h>
-configuration SomeComponentC {
+configuration SomeComponentC {
...
}
implementation {
@@ -449,7 +444,7 @@ implementation {
#endif
components SomeComponentP;
components new DisseminatorC(uint8_t, DIS_SOME_COMPONENT_KEY);
- SomeComponentP.ConfigVal -> DisseminatorC;
+ SomeComponentP.ConfigVal -> DisseminatorC;
}
To override, you can then make a disseminate_keys.h in your app @@ -464,8 +459,8 @@ protocol. The GUID enables nodes to detect versions from other binaries and not store them. This GUID won't be part of the external interface, but will be used internally.
An application can use this low-level networking primitive to build more complex dissemination systems. For example, if you want have a dissemination that only nodes which satisfy a predicate receive, you @@ -473,15 +468,15 @@ can do that by making the <t> a struct that stores a predicate and data value in it, and layering the predicate evaluation on top of the above interfaces.
An implementation of this TEP can be found in tinyos-2.x/tos/lib/net. This dissemination implementation uses network trickles [2]. Each dissemination value has a separate trickle.