REDS: A Reconfigurable Event Dispatching Infrastructure Gianpaolo Cugola Dipartimento di Elettronica...

REDS: A Reconfigurable Event REDS: A Reconfigurable Event Dispatching InfrastructureDispatching Infrastructure

Gianpaolo CugolaDipartimento di Elettronica e Informazione

Politecnico di Milano, [email protected]

http://www.elet.polimi.it/~cugolajoint work with

G. P. Picco, P.Costa, D.Frey, C. Ghezzi, M.Migliavacca, A.L.Murphy

IS-MANET Meeting, July 21st 2004 2

Politecnico di Milano

Publish-SubscribePublish-Subscribe

Application components can publish asynchronous messages (event notifications), and/or declare their interest in message classes by issuing a subscription

Subscriptions are collected by a message dispatcher component, responsible for routing messages to matching subscribers

High degree of decoupling among components Message

Dispatcher

C1 C2 C3C1

Temperature > 20 oC Temperature =

25 oC

C4

Temperature < 40 oC

C4



Design SpaceDesign Space

Existing publish-subscribe middleware differ along several dimensions:– The format of messages– The expressivity of the subscription

language– The architecture of the dispatcher– The routing strategy (in presence of a

distributed dispatcher)– The forwarding strategy



Format of MessagesFormat of Messages

Untyped sequences of values– Tuples

Untyped, record-like, messages– Sequences of fields, each with a name and

a value

Typed, record-like, messages– Similar to the above case with typed fields

Typed objects– Full-fledged objects with their own

attributes and methods



Subscription LanguageSubscription Language

The expressivity of the subscription language allows one to distinguish between:– Subject-based

• The set of subjects is determined a priori• Analogous to multicast

– Content-based• Subscriptions contain expressions (message filters)

that allow clients to filter messages based on their content

• The set of filters is determined by client subscriptions

• A single message may match multiple subscriptions



Architecture of the DispatcherArchitecture of the Dispatcher

Centralized– A single component is in

charge of collecting subscriptions and forward messages to subscribers

Distributed– A set of message brokers

organized in an overlay network cooperate to collect subscriptions and route messages

– The topology of the overlay network and the routing strategy adopted may vary

MessageDispatcher



Unrooted Tree TopologyUnrooted Tree Topology

Message forwarding– Every broker stores only subscriptions coming from

directly connected clients– Messages are forwarded from broker to broker...– ...and delivered to clients only if they are subscribed



Unrooted Tree TopologyUnrooted Tree Topology

Subscription forwarding– Every broker forwards subscriptions to the others– Subscriptions are never sent twice over the same link– Messages follow the routes laid by subscriptions



Tree TopologyTree Topology

Hierarchical– Both messages and subscriptions are

forwarded by brokers toward the root of the tree

– Messages flow down only if a matching subscription had been received along that route



Forwarding StrategyForwarding Strategy

Each time a broker or the unique, centralized dispatcher receives a message it has to match it against the list of received filters to determine the list of recipients

The efficiency of this process may vary, depending on the complexity of the subscription language, but also on the forwarding algorithm chosen– It greatly influences the overall

performance of the system



ReconfigurationReconfiguration

In presence of a distributed dispatcher, topological reconfiguration of the dispatching infrastructure should be considered

They can be caused by:– Physical mobility of the message brokers– Changes in the overlay network induced by

application requirements (e.g., in P2P networks) or by system optimizations (e.g., for load balancing)

No publish-subscribe system to date deals with such kind of topological reconfiguration– Some deal only with the mobility of clients



Dealing with ReconfigurationDealing with Reconfiguration

Involves solving three problems:– Reconstruct the overlay Reconstruct the overlay

networknetwork• Currently we have:

– MAODV-like approach for mobility– Custom, optimized solution for large-

scale P2P environments• In some environments, may be under

control of some user (e.g., sysadm)– Rearrange the subscription Rearrange the subscription

tablestables• Content-based, subscription

forwarding routing defines a new problem, for which the existing subject-based or multicast solutions are no longer applicable

– Minimize message loss Minimize message loss • We have a solution based on

epidemic algorithms [ICDCS04]

HW + Network

Overlay Maintainance

ReconfigurableSubscription Forwarding

Message Recovery

physicallink break

logicallink break



A Strawman ApproachA Strawman Approach

Problem: a potentially very large number of subscriptions may end up removed and immediately re-inserted

The endpoints of a vanishing link behave as if they received unsubscriptions from the other end (and similarly subscriptions for those on the new link)

A B

C

D



Understanding PropagationUnderstanding Propagation

A subscription is propagated following the unique route up to the closest splitter, if it exists; to the whole tree, otherwise– A splittersplitter is either a subscriber, or a dispatcher whose

routing table has two or more entries for the given subscription

A B

C

D

Adding a subscription is usually cheap

The more splitters, the shorter the path a subscription must follow



Our First (Simple) Idea [ICDCS03]Our First (Simple) Idea [ICDCS03]

It is fundamental to perform subscriptions before unsubscriptions– This way, the network is kept dense of

subscriptions (and splitters), and the impact of reconfiguration is reduced

Unsubscriptions are delayed using a timer, set by both the end-points of a broken link

This simple idea is:– grounded on a thorough understanding of how the

subscription forwarding strategy works– significantly effective in reducing overhead– easy to implement

An additional optimization is provided for when the broken and new link share a dispatcher



Reconfiguration Path [SAC04]Reconfiguration Path [SAC04]

It is the sequence of dispatchers connecting the old link with the new link

Only the dispatchers on this path are affected Our second algorithm propagates a control

message along the path, carrying the set of subscriptions to be added and/or deleted at each node A B

C

D



REDSREDS

Goal: designing and implementing a reconfigurable publish-subscribe middleware

In which sense “reconfigurable”?– Logical/Software (Static) : a well organized component-

based design allows system integrators to build their REDS system by choosing among a set of predesigned components (or to write their own versions) to determine several aspects• The format of messages and subscriptions• The wire-protocol used to transport messages and subscriptions• The architecture of the dispatcher• The routing and the forwarding strategies

– Physical (Dynamic) : REDS brokers are designed from the ground to deal with reconfiguration

How?– Through an open framework of Java classes, which realizes

the design above and allow system integrators to choose among a set of predefined components or build their own



The Client APIThe Client API



The Architecture of the BrokerThe Architecture of the Broker

**transport layer

routing and forwarding layer



The Architecture of the BrokerThe Architecture of the Broker

The Core– Holds the shared data structures (the subscription table and the list of

neighbors)– Mediates the communication among the other components

• The simplest implementation delegates all its operations to the other modules, without adding any further processing

– Manages internal messages, delivering them to registered “processors”

• Internal messages are used to exchange information among a set of distributed brokers (e.g., to communicate current load or current location)

The Router– Implements the specific routing strategy adopted

The ConnectionManager– Is in charge of managing the dispatching network in presence of

reconfigurations• New clients/brokers appearing• Links/brokers vanishing

The SubscriptionTable– Implements the specific forwarding strategy adopted

The Transport and Neighbor– Implements the specific transport protocol adopted (e.g., TCP based,

HTTP based, ...)– Include methods to open and close links toward other brokers/clients



Currently Available ModulesCurrently Available Modules

A transport layer using TCP links to move messages and filters along the network

A router that implements the subscription forwarding strategy

A simple, but general subscription table that can store any kind of messages and filters

A configuration manager that implements the “delaying unsubscriptions” approach previously described– It can be coupled with an “overlay manager” that

implements an MAODV-like strategy to keep the tree of brokers connected



Modules We Are BuildingModules We Are Building

A core that implements our gossip-based algorithm to recover messages lost due to reconfigurations or link errors

Two subject-based routers– One using a single unrooted tree spanning all brokers– One using different trees, one for each subject, spanning

only the routers that subscribed to the corresponding subject

An overlay manager similar in its interface to the MAODV-like one, but tailored to large-scale p2p environments

A new subscription table implementing a more efficient forwarding strategy designed for record-like messages



Modules We PlannedModules We Planned

A message-forwarding router A hierarchical router A configuration manager that

implements the “reconfiguration path” strategy

An UDP transport layer



Future WorkFuture Work

Adding new modules to REDS Porting to REDS the Jedi mechanism to allow

clients to move from broker to broker Introducing into REDS mechanisms to

automatically rearrange the overlay network of dispatchers (also changing the routing strategy, if necessary) to optimize routing– Can leverage-off our previous work on

reconfiguration– Needs some mechanism to trigger reconfiguration,

measure traffic, and determine best topology/strategy based on the measured traffic profile

– We already have some promising results coming from simulations we are running

Use REDS “in production”



Other Research AreasOther Research Areas

LIME: Linda in a Mobile Environment– A tuple-based middleware for mobile hosts– Based on transliently-shared tuple spaces (host-

level tuple space and federated tuple space) Sensor networks (motes + tiny os)

– Porting LIME on this platform– Goal: provide the ability to access the data

context provided by the sensors in range• Different from TinyDB, which instead provides access

to all the sensors in the network (with high latency)• Emphasis on one-hop rather than multi-hop access• Base stations are mobile, and travel across a space

disseminated of sensors

REDS: A Reconfigurable Event Dispatching Infrastructure Gianpaolo Cugola Dipartimento di Elettronica...

Documents

Transcript of REDS: A Reconfigurable Event Dispatching Infrastructure Gianpaolo Cugola Dipartimento di Elettronica...