Intent
Provide a global namespace for referring to
distinct elements or data types. Motes running
different applications can communicate using the
keys.
Also Known As
global ids
Example TinyOS Components
GenericComm, DripC, TinyDB
Motivation
Communication is a critical aspect of TinyOS programs, but
in order for motes to communicate effectively, they must
be able to name the data they exchange. Every mote must agree on
the name used, so that different programs using the same
system (such as a routing layer) can interoperate.
Examples include protocol IDs, sensor types, and management
queries. A protocol ID should be unique not just within a
particular application, but also across applications: if two
physically copresent networks disagree, then they can start
sending data to one another that confuses their protocols.
Similarly,if an external program (say, a Java tool)
needs to communicate with motes, then it must know the
names or identifiers for the data it sends, whether they
be command numberss, system names, or protocol IDs.
The Global Keyset provides a solution to this problem.
A Global Keyset is essentially just a set of constants, whose
meanings are agreed on by all programs. However, because these
keys must be globally meaningful, they are often sparse: although
the full set may be packed tightly, the fact that a given
mote only uses a few keys.
A Global Keyset is a set of constants allocated by
TinyOS components that need keys. For example, TinyOS provides
256 types of Active Messages; protocols use one or more
AM IDs for their traffic. The
Dispatcher pattern uses a Global
Keyset to identify which component to dispatch to.
Applicability
Use the Global Keyset pattern when:
- You need to identify services or data that motes exchange or use
- These indentifiers can be concise (integer values)
- All programs should have the same key-value binding, for interoperability
Consequences
By agreeing on a key-value binding, motes can communicate
using a Global Keyset. Additionally, external programs/tools
can refer to elements of the keyset and communicate with mote
networks.
Although the Global Keyset pattern assumes that keys are
unique, nesC/TinyOS has no mechanism to ensure this is the case.
If a program uses a Global Keyset in a parameterized interface,
such as in the Dispatcher pattern, then nesC can detect
at compile-time if a key is multiply bound in a single
program through combine functions. If the command or event
associated with a key fans out to multiple components,
then its return value can be a non-combinable type; as nesC
has no way to combine the result of the multiple calls,
it will issue a warning, which indicates that the key
is multiple bound.
Sample Code
Two networking protocols have keys in the AM global keyset
for AM IDs:
enum {
AM_EPIDEMICMSG = 20,
};
EpidemicC.Receive -> GenericComm.Receive[AM_EPIDEMICMSG];
enum {
AM_ROUTEMSG = 43,
}
RouteC.Receive -> GenericComm.Receive[AM_ROUTEMSG];
Known Uses
GenericComm uses a Global Keyset for Active Message types.
DripC uses a Global Keyset for referring to configurable
variables.
TinyDB uses a Global Keyset for its sensor types; in this
case, however, the keyset is composed of strings, which
are then mapped to a Local Keyset at runtime.
Related Patterns
The Local Keyset provides a way to allocate keys in
an efficient and compact fashion, but those keys are only
valid within a single program. The compacted key space
allows for more efficient state management than a sparse
Global Keyset. The Keyset Map provides a way to
map between Global and Local Keysets.
The Dispatcher pattern typically uses a Global Keyset
for its dispatch identifiers.
|