|
|
Technical Approach | |
|
Meteor is an infrastructure for content-based decoupled interactions in pervasive Grid environments providing services for content routing, content discovery and associative interactions. It is essentially a dynamic P2P network of Rendezvous Peers (RP). To use Meteor, applications must have access to at least one RP and can post messages to this RP. A schematic overview of the Meteor stack is presented in Figure. It consists of 3 key components: (1) a self-organizing overlay, (2) a content-based routing infrastructure (Squid), and (3) the Associative Rendezvous Messaging Substrate (ARMS). |
|
| Overlay Network: The Meteor overlay network is composed of RP nodes, which may be access points or message forwarding nodes in ad-hoc sensor networks and servers or peer nodes in wired networks. RP nodes can join or leave the network at any time. | |
| Content-based Discovery and Routing (Squid): Content-based discovery and routing services in Meteor are provided by Squid. Squid builds on top of the overlay to enable flexible content-based routing. Squid effectively maps complex queries consisting of keyword tuples (multiple keywords, partial keywords, wildcards, and ranges) onto clusters of identifiers, which is provided by overlay, and guarantees that all peers responsible for identifiers in these clusters will be found with bounded costs in terms of number of messages and the number of intermediate RP nodes involved. |
 |
|
Associative Rendezvous Messaging Substrate (ARMS): Associative Rendezvous (AR) is a paradigm for content-based decoupled interactions with programmable reactive behaviors. AR extends the conventional name/identifier-based rendezvous in two ways. First, it uses flexible combinations of keywords (i.e, keyword, partial keyword, wildcards, ranges) from a semantic information space, instead of opaque identifiers (names, addresses) that have to be globally known. Interactions are based on content described by keywords, such as the type of data a sensor produces (temperature or humidity) and/or its location, the type of functionality a service provides and/or its QoS guarantees, and the capability and/or the cost of a resource. Second, it enables the reactive behaviors at the rendezvous points to be encapsulated within messages increasing flexibility and expressibility, and enabling multiple interaction semantics (e.g. broadcast, multicast, notification, publish/subscribe, mobility, etc.). |
|
|
Implementation Overview The current implementation of Meteor builds on
Project JXTA, a general-purpose peer-to-peer framework. JXTA defines
concepts, protocols, and a network architecture. Note that JXTA is an
application level technology and does not introduce any limitations on the
underlying infrastructure or the routing protocols.
Each layer exposes an API for the upper layer Chord interacts directly with JXTA, it uses: (1) JXTA discovery mechanism to find other nodes already in the group; (2) JXTA resolver service to send messages between peers. Squid uses Chord's lookup primitive, to route clusters to their destination. Squid's API consists one primitive: post(AR_Message) -- routes based on the keywords extracted from the message's profile. Associative Rendezvous (AR) Messaging layer: API
consisting of a single function: post(header, action, data) is provided
to end-applications.
| |
|
Status To test the proposed approach, we currently have implemented the meteor programming framework. For this purpose, Meteor uses JXTA Technology to enable discovery between peers as well as a p2p messaging substrate. The Meteor development team chose JXTA because it offered all the services and mechanisms that they needed to build their application. An ad-hoc testbed prototype is being instrumented to support programming and prototype studies in the sensor environments. | |