Fuego Event Service: Towards Modularity in Event Routing Sasu Tarkoma Rutgers-Helsinki Workshop

Contents Introduction Content-based routing Challenges Fuego event service Routing blocks: posets and forests DoubleForest Conclusions

Introduction Information dissemination solutions are needed by many distributed applications –Content delivery News, alerts, stock market information, metadata, presence information,… –Monitor data (sensors) –Control data (actuators, robots,…) Motivates research and development of efficient distributed dissemination systems –Event-based systems and Publish/Subscribe –Reusable building blocks for high-level routing

Event-based Systems and Publish/subscribe Event delivery from publishers to subscribers –Event is a message with content –One-to-many, many-to-many –Builds on messaging systems and store-and-forward A frequently used communication paradigm –Decoupling in space and time –Solutions from local operation to wide-area networking –Proposed for mobile/pervasive computing The event service is a logically centralized service –Basic primitives: subscribe, unsubscribe, publish Various routing topologies and semantics

Subscriptions Subscriptions are described using filters –Filter: a stateless Boolean function Defines a subspace of the content space A single event is a point in the content space –Selects a subset of published events –Expressive interest definition and content-matching –Content model typically typed tuples or XML

Content-based Routing Filters select events based on the content of event messages Can be seen as content-based addressing More expressive than topic, subject, or header-based routing Research projects and prototype systems Siena, Rebeca, Hermes,.. Three central design considerations –Router topology –Interest propagation mechanism –Filtering language

Example of Siena-style Content-based Routing B C Publisher Subscriber A I want to publish information I want information that matches my interests. Overlay Routing infrastructure

Challenges How to manage large numbers of filters? –Covering relations (Siena) Prevent propagation of filters that are covered by existing filters The covering relation is a partial order Filters poset (partially ordered set) [0,10] covers [2,5] –Filter merging (Rebeca) Combine two or more input filters into a single filter Reduces processing overhead [0,10] or [9,20] can be merged to [0,20]

Challenges continued How to cope with mobile users? –Disconnected operation Buffering and queue management –Mobile subscribers / publishers Handover protocol for relocating subscriptions and updating the topology Multiple indirection points on the overlay network Covering/merging complicate mobility support –General requirements fast convergence of the subscription topology mobility-safety: no false negatives

Example Handover B C Producer Subscriber A 1. Advertise Subscriber 3. Roam 4. Update topology 5. Transfer buffered, possible teardown Subpath that must be updated 2. Subscribe

Main Research Objectives Only a few data structures have been proposed for filter-based content-based routing. Is it possible to develop more efficient structures? How to take context information into account? How to modularize the routing process with reusable components? How to integrate filter merging with routing data structures? What handover protocols are efficient? What topologies are mobility friendly and efficient?

Research Methodology Content-based routing and data structures –Formal definition –Analysis of correctness –Prototype implementation –Empirical evaluation with benchmarks Mobility support –Formal definition –Analysis of correctness –Evaluation using simulation

Fuego Event System Scalable distributed event framework for mobile computing The Fuego event router consists of two parts: –access server functionality with buffering and handover support for mobile clients, and –extensible routing core for distributed operation New data structures for efficient content-based routing: –poset (partially ordered set)-derived forest –the forest is considerably more efficient than dag (directed acyclic graph) - based structures Rendezvous-based mobility support for fast handovers and subscription topology updates –RP or paths to RP are updated instead of the whole topology

Routing Blocks Filters Poset k neighbours + local clients Forest (PF) n local clients Forest (NRF) k neighbours n local clients Forest (NRF) 1 master k slave routers n local clients Filters Poset k neighbours + local clients Forest (PF) n local clients Efficient Matcher n local clients Notifications. Add/del notify Peer-to-peer Hierarchical External matchers This is a set of generic building blocks for filter cover-based routing. Can be extended with optimizations such as pruning and caching.

Merging Blocks Filters Poset k neighbours + local clients Poset-derived Forest n local clients Root Merger Aggregate Merger Non-redundant Forest 1 master router k slave routers Poset-derived Forest n local clients Root Merger Slave master

PosetBrowser

Filters and Context We propose to represent context using filters –Support for points and subspaces (for example ranges) –Use filters for both queries and profiles. A query defines a collection and is matched against profiles. A profile describes the context of an object Two semantics: cover and overlap A set of user interest  context query  filter  subspace of context space A set of context metadata  context profile  filter  subspace of context space

DoubleForest DoubleForest data structure –Combines two poset-derived forests for generic context matching. –One forest for queries, one for profiles. Support for both subspace matching and temporal profiles. Mappings are updated during add/del. Optimizations possible using forest structure. Significantly better performance to set-based iteration using filter covering. Experimental results indicate that overlap based matching has more overhead than cover.

DoubleForest Data Structure a a c c b b d d e e Profiles P = { a,b,c,d,e } Type=location Subtype=office X = 10 Y = 20 Diameter = 400 Type=location Subtype=office X = 10 Y = 20 Diameter = Type=location Subtype=office X  [7,14] Y  [18, 22] Type=location Subtype=office X  [7,14] Y  [18, 22] Queries Q = {1,2,3,4,5} MAPPINGS M PQ : P   (Q) M QP : Q   (P) Updated on add and del operations for the structures. MAPPINGS M PQ : P   (Q) M QP : Q   (P) Updated on add and del operations for the structures. Query matches profile

DataSpace Architecture Profile Store Object and dir. sync. When to sync? Client Terminal 6. Context sync rules 3.Context Object tracking rules Collection Contents based on context Augment objects with context Synchronization Server Policies ACRs 5. Updates 7. Sync object / directory (peer-to-peer) 2. Make object available / unavailable 4. Sub/Unsub Keep track of context subscriptions and notify when an object is added/removed that matches with the subscr. Profile & Query Store Add new object with context profile to the directory 1. Context

Conclusions The poset-derived forest data structure for efficient filter cover-based routing Construction of routing systems using reusable building blocks, namely posets and forests A formal framework for filter merging and integration with the routing structures The DoubleForest data structure that extends the basic content-based routing model with temporal content and allows content defined using subspaces A formal treatment of client mobility in publish/subscribe and analysis of different mobility support protocols Live demos on the web: Thesis available on the web: ethesis.helsinki.fi