Design and Evaluation of a WideArea Event Notification Service

1
Design and Evaluation of a Wide-Area Event
Notification Service
ANTONIO CARZANIGA, University of Colorado at
BoulderDAVID S. ROSENBLUM, University of
California, IrvineALEXANDER L. WOLF, University
of Colorado at Boulder

• PRESENTED BY
• Manan Shah
• David Woollard

2
What is Event Notification?

• Producers of events publish event notifications
• Consumers of events subscribe to receive
  notification
• Notifications should be filtered for relevant
  content
• Delivery should be guaranteed

3
What is SIENA?

• SIENA a wide-area event notification service
• Nodes and servers (access points)
• Event notifications filters
• Publish/subscribe protocol advertisements
• Identities and handlers
• Filtering

4
Nodes and Access Points

• SIENA is an event notification framework built on
  a network of servers
• Servers act as access points for nodes
• Nodes communicate with a server to publish and
  receive event notifications

5
Event Notifications Filters

• Event notifications are sets of attributes
• Each attribute has a name, a type, and a value
• Event matching
• Filters specify attributes and constraints of
  the values of the attributes
• Patterns match multiple event notifications with
  filters and the combination they form

6
Publish, Subscribe Advertise

• Nodes publish event notifications to access
  points
• Nodes subscribe to access points in order to
  receive event notifications
• Specified by filters and/or patterns
• Advertisements defines the event notifications a
  node may possibly generate using the same
  semantics as filters

7
Identities and Handlers

• Identities are unique identifiers for each node
  in SIENA
• Handlers are mapped 11 with identities and
  indicate the underlying protocol for connecting
  the node to its access point
• CLAIM abstraction of framework through
  separation aids in scaling and mobility

8
Filtering

• The goal of filtering only deliver messages of
  interest to nodes, reducing the overall traffic
  across the network
• The system is aided by use of advertisements

9
Architecture Topologies and Protocol

• Hierarchical client/server architecture
• Peer to peer architecture
• Acyclic peer to peer
• General peer to peer
• Hybrid architectures

10
Hierarchical Architecture

• Servers interact with each other in an asymmetric
  client-server fashion
• Server is not distinguished from objects of
  interest or interested parties
• Potential overloading of server stationed at
  higher level of hierarchy
• Failure of one node in hierarchy causes all the
  nodes below that node to fail

11
Acyclic Peer to Peer Architecture

• Servers communicate with each other symmetrically
  allowing bi-directional flow of subscriptions,
  advertisements and notifications.
• Servers are required to be connected in acyclic
  fashion as failure to do so may result in failure
  of routing algorithm.
• The problem with this system is scale.
• Lack in redundancy constitutes limitation in
  assuring connectivity.
• Administration boundary is not clearly defined.

12
General Peer to Peer Architecture

• Servers communicate with each other symmetrically
  allowing bi-directional flow of subscription
  advertisement and notification
• Requires less co-ordination and offers more
  flexibility
• Redundant connections among the servers makes
  them more robust
• Existence of cycles requires a special routing
  algorithm
• Scale is still a problem
• Administration boundary is not defined properly

13
Hybrid Architectures

• A wide-area large scale de-centralized service
  poses different requirements at different levels
• We can combine the basic topologies, making the
  system more robust in terms of failure and
  scalability
• E.G. General peer to peer architecture can be
  used within clusters while high level
  architecture could be hierarchical or acyclic
  peer to peer

14
Routing Algorithms

• Server must establish appropriate routing path to
  ensures that notification published by objects of
  interest are correctly delivered to all the
  interested parties that subscribed to them
• Simplest strategy is to maintain the
  subscriptions at their access point and broadcast
  the notification throughout the network
• Least efficient
• Consumes lots of bandwidth

15
Routing strategy in SIENA

• Central idea is to send the notification towards
  the event servers that have clients that are
  interested in that notification (possibly using
  shortest path)
• Downstream replication
• Notification should be replicated only downstream
  and as close as possible to parties interested in
  it

subscribe
publish
Replication
subscribe
16
Routing strategy in SIENA

• Upstream evaluation
• Filters are applied and patterns are assembled
  upstream as close as possible to the source of
  notification

Filter X
Subscribe x y
Publish x
assemble x - y
Filter Y
Publish y
17
Routing strategy in SIENA

• Subscription forwarding
• Routing paths for notification are set by
  subscriptions which are propagated throughout the
  network so as to form a tree that connects
  subscribers to all the servers in network
• Advertisement forwarding
• Subscriptions are send towards those objects of
  interest that intent to generate notifications
  that are relevant to that subscription
• Every advertisement is propagated throughout the
  network

18
Implementation Issues

• Server keep track of previous requests their
  relationship using data structure which
  represents a partially ordered set of filters
  called poset

2
Poset of server 1
Airlines UA
Airline UA
a
Airlines UA
1
b
a
19
2
Poset of server 1
Airline UA
a
Airlines UA
1
Airline UA Dest DEN
Airline UA Dest DEN
b
a
b
Poset of server 1
Airline ANY
2
Airlines ANY
Airline UA
a
Airlines ANY
1
Airline UA Dest DEN
Airline UA Dest DEN
b
a
b
20
Simulation

• Goal
• Evaluate the combination of architectures and
  algorithms in terms of the communication induced
  by the application behaviors
• Simulation framework
• Configuration of servers and clients map onto the
  sites of wide-area network
• An assignment of application behaviors to objects
  of interest and interested parties

21
Simulation

• Assumptions
• Cost of computation and communication through
  links are linear function of load
• Links have constant latency
• Sites and links have infinite capacity
• Communication cost inside the site is zero.
• Scenario generation
• Random network topology is generated
• Generated topology is combined with the parameter
  file which specify the notification service
  topology and application behavior

22
Simulation Results

• When there are more then 100 parties total cost
  is essentially constant
• All the architectures scale sub linearly when the
  number of interested parties is lt 100
• As no of of objects of interest party increases,
  hierarchical architecture performs worse than
  peer to peer architectures

23
Simulation Results

• Acyclic peer to peer architecture with
  advertisement forwarding displays strikingly
  unstable cost profile for low densities of
  interested parties
• For low number of objects of interest and low
  number of interested parties costs are dominated
  by message passing cost internal to systems
• Hierarchical architecture does well with low
  number of interested party and low number of
  objects of interest

24
Simulation Results

• Peer to peer architecture with subscription
  forwarding does extremely well when there is high
  number of objects of interest
• Cost per subscription and notification are
  primarily dependant on the density of interested
  parties
• Hierarchical client/server has lower per
  subscription cost then the acyclic peer to peer
  system

25
Embedded Systems Issues

• Embedded system put more constrains on the
  networking topologies and routing protocol
  because
• Real time constraints
• Resource constraints
• Mobility
• Ad hoc-ness

26
Conclusions

• The paper is a general overview of a wide-area
  event-based system with good formalism
• We believe that designing such system for an
  embedded system requires answers to the following
  questions
• What if a node disconnects it self and rejoins
  later with different server (mobility, QoS)?
• How should ad hoc-ness be handled?
• How well does it realistically scale(sensor
  networks applications)?
• On a resource-constrained environment, how well
  will the system handle filtering?
• With best-effort delivery, will there be timing
  issues for real-time systems?
• How would the systems pattern matching perform
  given a deliver exactly once network strategy?