supporting disconnected operations in publish subscribe systems
Download
Skip this Video
Download Presentation
Supporting Disconnected Operations in Publish/Subscribe Systems

Loading in 2 Seconds...

play fullscreen
1 / 35

Supporting Disconnected Operations in Publish/Subscribe Systems - PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on

Supporting Disconnected Operations in Publish/Subscribe Systems. Vinod Muthusamy Joint work with Milenko Petrovic, Ioana Burcea, H.-Arno Jacobsen, Eyal de Lara University of Toronto. 2004 IEEE International Conference on Mobile Data Management. Agenda. Part I – Publish/Subscribe

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Supporting Disconnected Operations in Publish/Subscribe Systems' - ferris


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
supporting disconnected operations in publish subscribe systems

Supporting Disconnected Operations in Publish/Subscribe Systems

Vinod Muthusamy

Joint work withMilenko Petrovic, Ioana Burcea, H.-Arno Jacobsen, Eyal de Lara

University of Toronto

2004 IEEE International Conference on Mobile Data Management

agenda
Agenda
  • Part I – Publish/Subscribe
    • Centralized/distributed models
    • Benefits
    • Applications
  • Part II – Mobile Publish/Subscribe
    • Disconnected operation in distributed publish/subscribe systems
      • Motivation and Problem
      • Solutions
    • Evaluation
      • Factors
      • Results
  • Conclusions
the publish subscribe model

Notification

Notification

The Publish/Subscribe Model

TSX

Stock markets

NASDAQ

NYSE

Publisher

Publisher

AMGN=58

Publications

IBM=84

ORCL=12

JNJ=58

HON=24

INTC=19

MSFT=27

Broker

Subscriptions:

IBM > 85

ORCL < 10

JNJ > 60

Subscriptions

Subscriber

Subscriber

distributed publish subscribe
Distributed Publish/Subscribe

Broker

  • Hierarchy of brokers [Siena, JEDI]
  • Subscriptions to root
  • Publications to root and multicast down to interested subscribers

Broker

Broker

Broker

Broker

Broker

stocks/ibm/*

Publisher

stocks/*

stocks/oracle

publish subscribe benefits
Publish/Subscribe Benefits
  • Simple interface
  • Decoupling of producers and consumers of data
    • Address
      • Content-based routing
      • Anonymity
    • Platform
    • Space
    • Time
    • Representation (semantic)
  • Efficient data dissemination (scalability)
    • Push model
    • Multicast
publish subscribe applications
Publish/Subscribe Applications
  • News dissemination
  • Location based services
  • Workflow management
  • E-commerce
  • Auctions
  • Distributed gaming
  • Software updates delivery
  • Sensor networks
  • Existing systems
    • Research: ToPSS, Siena, JEDI, Gryphon, Hermes
    • Industry: IBM, Precache, TIBCO, Talarian
part ii
Part II
  • How does disconnected operation work in distributed publish/subscribe systems?
  • Why is disconnected operation a problem?
  • What are some solutions?
  • How do these solutions perform?
disconnected operation motivation
Disconnected Operation: Motivation

Broker

  • User’s laptop connected at work
  • Disconnect at the end of the day
  • Reconnect at home
  • Events published while a subscriber is disconnected should be stored somewhere and replayed upon reconnection

Broker

Broker

Subscriber

disconnected operation jedi

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

Subscriber

disconnected operation jedi1

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

Subscriber

disconnected operation jedi2

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

moveout

Subscriber

disconnected operation jedi3

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

Subscriber

disconnected operation jedi4

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

movein

disconnected operation jedi5

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

disconnected operation jedi6

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

Disconnect

Connect

Receive

(moveout)

(movein)

new events

Disconnected Operation [JEDI]

Publisher

  • Subscriber receives publications
  • Subscriber disconnects
  • Broker stores publications
  • Subscriber connects
  • Transfer state to new broker & replay old publications
  • New publications go directly to subscriber

Broker

Broker

Broker

problem unicast state transfer
Problem: Unicast State Transfer

Broker

Broker

Broker

Broker

Broker

Broker

  • State transfer is inefficient [unicast]
  • Publish/subscribe is efficient [multicast]
  • What’s the bandwidth overhead of unicast state transfer?
state transfer optimizations prefetching

t1

t2

t3

t4

At Old Broker

Disconnected

At New Broker

tp

Disconnect

Connect

Receive

(moveout)

(movein)

new events

State Transfer Optimizations:Prefetching

Broker

  • Eagerly migrate state while the user is disconnected
  • Exploits knowledge of future mobility patterns
  • Shortens perceived length of disconnection to the system
  • Less state to transfer
  • State transfer period hidden from user

Broker

Broker

moveout

state transfer optimizations logging
State Transfer Optimizations:Logging

Broker

  • Brokers cache recent publications
  • Exploits locality
  • Only partial state transfer needed if locality exists
  • Overhead could be worse if no locality exists
  • Requires cache space at brokers

Broker

Broker

state transfer optimizations home broker
State Transfer Optimizations:Home-Broker

Broker

  • Mobile client logically reconnects to “home” broker
  • Eliminates state transfer overhead
  • Increases perceived disconnection period
    • Unicast transfer even when connected

Broker

Broker

movein

evaluation factors affecting mobility
Network

Bandwidth and latency of links

Broker placement

Broker topology

Number of brokers

Evaluation:Factors Affecting Mobility

Mobility

  • Connection and disconnection periods
  • Predictive or repetitive mobility
  • Group mobility

Application

  • No. of publishers and subscribers
  • Publication rate
  • Subscription specificity
  • Subscription (interest) locality
  • Message size
evaluation setup
Evaluation: Setup
  • Simulation Environment
    • NS2 network simulator
    • Implemented state transfer optimizations
  • Parameters
    • Topology
      • Metropolitan Area Network
      • 4 levels of degree 4  64 leaf brokers
    • Subscribers: 200, 400, 600, 800
    • Publishers: 100
    • Locality: random, 30%, 60%, 90%
  • Metric
    • Total message traffic
    • State transfer overhead (unicast/multicast)

• • •

• • •

1

64

commute scenario

City center

Outskirts

Outskirts

1

64

Downtown

Commute Scenario
  • Simulate evening commute home
    • Subscribers work downtown (20 inner brokers)
    • Start commute between 4:00 pm and 6:00 pm
    • 40% live in city center (30 inner brokers)
      • Take 15 min to 45 min to commute
    • 60% live in outskirts (34 outer brokers)
      • Take 45 min to 90 min to commute
  • Few total disconnections
  • Long disconnection periods
commute scenario average overhead
Commute Scenario:Average Overhead
  • Standard: almost 100% overhead
  • Logging: Slight improvement
  • Prefetching: negligible overhead
  • Home broker: poor due to sustained unicast
  • Peak overhead results
    • Up to 3x for Standard
    • Up to 27x for Home-broker
commute scenario total message cost
Commute Scenario:Total Message Cost
  • 800 subscribers
  • Same relative performance
  • Message cost tracks # of state transfers
  • Home-broker overhead even after reconnection
  • Max 10% concurrent state transfers
random scenario
Random Scenario
  • More ad-hoc mobility
    • Subscriber starts at random broker
    • Disconnects for 10 min to 30 min
    • Walk (5 km/h), city driving (50 km/h), highway driving (100 km/h)
    • Reconnects to a random broker within range
    • Remains connected for 10 min to 30 min
    • (repeat)
  • More disconnections
  • Shorter disconnection periods
random scenario average overhead
Random Scenario:Average Overhead
  • Standard: 100% overhead
  • Prefetching overhead now noticeable
    • Due to shorter disconnections
  • Logging diverges more from Standard
    • Due to hidden increase in locality with population
    • Due to more disconnections
random scenario effect of locality
Random Scenario:Effect of Locality
  • 800 subscribers
  • Adjust subscription locality by varying % of subscribers with identical subscriptions
  • Logging can approach “ideal” Prefetching
  • Others’ increasing overhead is due to decreasing multicast, and constant unicast
random scenario effect of log size
Random Scenario:Effect of Log Size
  • For Logging approach
  • Log size 0, 400, 800, 1200 events
  • Diminishing returns of increasing log size
pervasive scenario
Pervasive Scenario
  • Persistent connectivity
    • Similar mobility patterns as Random scenario
    • Disconnections are few seconds long
      • E.g. Cellular handoffs between cells
  • Many disconnections
  • Short disconnection periods
pervasive scenario average overhead
Pervasive Scenario:Average Overhead
  • Event migration is small portion of state transfer overhead
  • Similar overhead (except home-broker)
    • Due to very short disconnec-tions
conclusions
Conclusions
  • The publish/subscribe model lends itself well to mobile applications
  • Mobility can break a distributed pub/sub system
    • Network overhead can double with only 10% concurrent movein’s
    • Stored events typically dominate overhead, not subscriptions
    • With sufficient locality, Logging approaches Prefetching
  • Future Work
    • Other scenarios: realistic traces, mobile publishers
    • Investigate effects of state transfer traffic on latency
    • Develop more state transfer optimizations
      • Multicast state transfer
      • Logging at intermediate brokers
      • Smarter cache replacement policies
pub sub optimizations
Pub/Sub Optimizations

Covering

Advertisements

SubscriptionsAdvertisementsPublications

Broker

Broker

stocks/*

stocks/*

Broker

Broker

Broker

Broker

stocks/*

stocks/ibm/*

Publisher

  • Reduce subscription traffic
  • Reduce publication traffic to the root
covering and advertisements
Covering and Advertisements
  • Our scenarios did not benefit significantly from covering and ads
  • Forwarding of events dominate overhead
    • 98% of overhead in Commute and Random scenarios
    • Covering only helps to quench subscriptions
  • There is little subscriber locality (in our scenarios)
    • Most events must propagate to the root broker
    • Ads only help to quench upstream publications
toronto publish subscribe system topss research areas
Toronto Publish/Subscribe System (ToPSS) Research Areas

ToPSS

(matching algorithms)

A-ToPSS

(approximate)

M-ToPSS

(mobile)

p2p-ToPSS

(peer-to-peer)

S-ToPSS

(semantic)

ToPSS

L-ToPSS

(location-based correlation)

Rb-ToPSS

(rule-based)

Information consumers subscribe to information of interest.

Information producers publish information.

ToPSS-broker(s) match and routerelevant information to interested subscribers.

X-ToPSS

(semi-structured data; XML)

Ad hoc-ToPSS

(ad hoc networking)

persistent-ToPSS

(Subject Spaces)

Federated-ToPSS

(federation of ToPSS brokers)

ad