210 likes | 339 Views
Fuego Event Service: Towards Modularity in Event Routing. Sasu Tarkoma Rutgers-Helsinki Workshop 9.5.2006. Contents. Introduction Content-based routing Challenges Fuego event service Routing blocks: posets and forests DoubleForest Conclusions. Introduction.
E N D
Fuego Event Service: Towards Modularity in Event Routing Sasu Tarkoma Rutgers-Helsinki Workshop 9.5.2006
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
Publisher Subscriber Example of Siena-style Content-based Routing I want to publish information C Overlay Routing infrastructure A B I want information that matches my interests.
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
Subpath that must be updated 1. Advertise 2. Subscribe 4. Update topology 5. Transfer buffered, possible teardown Subscriber Subscriber 3. Roam Example Handover Producer C A B
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
Filters Poset k neighbours + local clients Filters Poset k neighbours + local clients Forest (NRF) k neighbours n local clients Forest (NRF) 1 master k slave routers n local clients Notifications. Forest (PF) n local clients Forest (PF) n local clients Efficient Matcher n local clients notify Add/del Routing Blocks External matchers Peer-to-peer Peer-to-peer Hierarchical This is a set of generic building blocks for filter cover-based routing. Can be extended with optimizations such as pruning and caching.
master Aggregate Merger Root Merger Filters Poset k neighbours + local clients Non-redundant Forest 1 master router k slave routers Slave Slave Root Merger Root Merger Poset-derived Forest n local clients Poset-derived Forest n local clients Merging Blocks
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.
Profiles P = { a,b,c,d,e } Queries Q = {1,2,3,4,5} a 1 5 MAPPINGS MPQ: P (Q) MQP: Q (P) Updated on add and del operations for the structures. b c 2 3 d e 4 Type=location Subtype=office X = 10 Y = 20 Diameter = 400 Type=location Subtype=office X [7,14] Y [18, 22] Query matches profile DoubleForest Data Structure
Add new object with context profile to the directory Collection Contents based on context DataSpace Architecture Synchronization Server Client Terminal Augment objects with context 2. Make object available / unavailable 7. Sync object / directory (peer-to-peer) 1. Context Object and dir. sync. When to sync? Keep track of context subscriptions and notify when an object is added/removed that matches with the subscr. 4. Sub/Unsub 5. Updates Policies ACRs Profile & Query Store Profile Store 3.Context Object tracking rules 6. Context sync rules
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: www.hiit.fi/fuego/fc/demos • Thesis available on the web: ethesis.helsinki.fi