Supporting disconnected operations in publish subscribe systems
Download
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 Systems

  • 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 Systems

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 Systems

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 Systems

  • 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 Systems

  • 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 Systems

  • 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 Systems

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

t Systems1

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

t Systems1

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

t Systems1

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

t Systems1

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

t Systems1

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

t Systems1

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

t Systems1

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 Systems

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

t Systems1

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: SystemsLogging

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: SystemsHome-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 Systems

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 Systems

  • 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 Systems

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: SystemsAverage 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: SystemsTotal 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 Systems

  • 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: SystemsAverage 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: SystemsEffect 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: SystemsEffect of Log Size

  • For Logging approach

  • Log size 0, 400, 800, 1200 events

  • Diminishing returns of increasing log size


Pervasive scenario
Pervasive Scenario Systems

  • 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: SystemsAverage Overhead

  • Event migration is small portion of state transfer overhead

  • Similar overhead (except home-broker)

    • Due to very short disconnec-tions


Conclusions
Conclusions Systems

  • 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


Thank you
Thank You Systems


Pub sub optimizations
Pub/Sub Optimizations Systems

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 Systems

  • 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 Systems

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