Fuego Event Service: Towards Modularity in Event Routing Sasu Tarkoma Rutgers-Helsinki Workshop 9.5.2006.
Post on 22-Dec-2015
217 Views
Preview:
Transcript
Fuego Event Service: Towards Fuego Event Service: Towards Modularity in Event RoutingModularity in Event Routing
Sasu Tarkoma
Rutgers-Helsinki Workshop
9.5.2006
ContentsContents
•Introduction
•Content-based routing
•Challenges
•Fuego event service
•Routing blocks: posets and forests
•DoubleForest
•Conclusions
IntroductionIntroduction
•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 Event-based Systems and Publish/subscribePublish/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
SubscriptionsSubscriptions
•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 RoutingContent-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 Example of Siena-style Content-based RoutingRouting
B
C
Publisher
Subscriber
A
I want to publish
information
I want information that
matches my interests.
OverlayRouting
infrastructure
ChallengesChallenges
•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 continuedChallenges 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 HandoverExample 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 ObjectivesMain 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 MethodologyResearch 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 SystemFuego 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 BlocksRouting Blocks
Filters Poset
k neighbours + local clients
Forest (PF)
n local clients
Forest (NRF)
k neighboursn 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 Peer-to-peer HierarchicalExternal 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 BlocksMerging Blocks
Filters Poset
k neighbours + local clients
Poset-derived Forest
n local clients
Root Merger
Aggregate Merger
Non-redundant Forest
1 master routerk slave routers
Poset-derived Forest
n local clients
Root Merger
Root Merger
SlaveSlave
master
Filters and ContextFilters 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
DoubleForestDoubleForest
•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 StructureDoubleForest Data Structure
aa
ccbb
dd ee
Profiles P = { a,b,c,d,e }
Type=locationSubtype=officeX = 10Y = 20Diameter = 400
Type=locationSubtype=officeX = 10Y = 20Diameter = 400
11
3322
44
55
Type=locationSubtype=officeX [7,14]Y [18, 22]
Type=locationSubtype=officeX [7,14]Y [18, 22]
Queries Q = {1,2,3,4,5}
MAPPINGSMPQ: P (Q)MQP: Q (P)
Updated onadd and del operations
for the structures.
MAPPINGSMPQ: P (Q)MQP: Q (P)
Updated onadd and del operations
for the structures.
Query matches profile
DataSpace ArchitectureDataSpace Architecture
ProfileStore
Object and dir. sync.
When to sync?
Client Terminal
6. Context sync rules
3.Context Objecttracking rules
CollectionContents based on context
Augment objects withcontext
Synchronization Server
PoliciesACRs
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 &QueryStore
Add new object with context profile to the
directory
1. Context
ConclusionsConclusions
•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
top related