Disseminating Information to Mobile Clients Using Publish–Subscribe

Muhl, Ulbrich, Herrmann, Weis

mobile networking manet publish subscribe pub/sub dissemination

@article{muhl:ieee-ic2004,
  title={Disseminating Information to Mobile Clients Using Publish-Subscribe},
  author={M{\"u}hl, G. and Ulbrich, A. and Herrmann, K. and Weis, T.},
  journal={{IEEE} Internet Computing},
  pages={46--53},
  year={2004},
  publisher={{IEEE} Computer Society}
}

Presents Rebeca content-based pub/sub broker system

Information dissemination always involves three "fundamental objectives"

• Making new content available
• Updating existing content
• Revoking obsolete content

Two dimensions of approaches are push/pull and periodic/aperiodic

• Aperiodic pull is not feasible in many systems, as users want data as soon as it changes
• Periodic pull (polling) requires high sample rates to catch data changes quickly
  • Ramps up resource use, wasted if data does not change in that interval
  • But this is what most Web users are doing now with RSS, etc
• Periodic push has similar issues

Aperiodic push offers the following advantages:

• "Sources can initiate communication instantly if and only if the data changes or new data is available"
• "Each interaction requires only a single message"
• "The infrastructure can apply multicast instead of point-to-point communication"
• "The infrastructure can combine aperiodic push with aperiodic pull to allow new clients to gather the current or historical content."

Pub/sub

• Consumers register subscriptions
• Producers post notifications
• Notification service delivers notifications to consumers with matching subscriptions
• Producers may also post advertisements to express their publishing intent

Loose coupling between producers and consumers is most important feature of pub/sub

• Periodic and aperiodic both work, but aperiodic usually makes the most sense

Adding a federated broker network can substantially improve scale

Given wireless connections, must reduce amount of traffic sent to mobile users

• Only push updates to mobile users if it deviates significantly from previous data
  • Clients must be able to specify this policy
  • Simple form of model based comms control as seen in some sensor work
• Applies some simple QoS, e.g. dropping queued messages if a more recent update arrives
  • How to determine quickly if they're the same? Isn't matching the big hold up in the queue in the first place?
    • Base drop decision on source & a simple tag? That would be semantically incorrect for large classes of queries/user configurations
• Clients also stipulate durations, how long subscriptions should stay active
• Clients specify their delivery requirements, e.g. at what rate data should be delivered
  • This information needs to be pushed up the tree so that messages are not delivered to edge brokers, only to be dropped for being over the client's rate limit

Middleware provides persistent connections

• Simplified sliding window scheme used to ensure no loss or duplicates
• If a client reconnects to a new broker, the old broker passes on the connection state

When clients subscribe, they specify a replay period

• Brokers forward past matching notifications within that period
• Provides a mechanism for rapidly getting back up to speed
  • Easy, less robust case: Producers story this data
  • Other case: Sets of brokers store data; but how to determine who stores, and how to prevent duplicates from being forwarded on?

Of note:

• Broadcast discs: Push content according to schedule, with rates based on popularity
• Subscription is a kind of infrequent pull
• Identity and covering tests, filter mergers
  • Carzaniga et al, Design and Evaluation of a Wide-Area Event Notification Service, ACM Trans. Computer Systems
  • Muhl, Large-Scale Content-Based Publish/Subscribe Systems, thesis
• Partially reimplement transport functionality
• In-network event aggregation