Ferry: A P2P-Based Architecture for Content-Based Publish/Subscribe Services

Abstract

We propose Ferry, an architecture that extensively yet wisely exploits the underlying distributed hash table (DHT) overlay structures to build an efficient and scalable platform for content-based publish/subscribe (pub/sub) services. Ferry aims to host any and many contentbased pub/sub services: any pub/sub service with a unique scheme can run on top of Ferry, and multiple pub/sub services can coexist on top of Ferry. For each pub/sub service, Ferry does not need to maintain or dynamically generate any dissemination tree. Instead, it exploits the embedded trees in the underlying DHT to deliver events, thereby imposing little overhead. Ferry can support a pub/sub scheme with a large number of event attributes. To deal with skewed distribution of subscriptions and events, Ferry uses one-hop subscription push and attribute partitioning to balance load.

Scalable Content-Based Publish/Subscribe Services over Structured Peer-to-Peer Networks

“…Previous work in our group has introduced a novel framework Ferry [20] for building content-based pub/sub services on top of a DHT. It exploits the embedded trees in the DHT to aggregate and deliver events from the rendezvous point (RP for short) nodes.…”

Ferry: An Architecture for Content-Based Publish/Subscribe Services on P2P Networks

“…Please refer to [24] for more detail. Table 1 shows the performance of Ferry with different configurations for 10, 000 subscriptions and 100, 000 events, where PNS represents Chord uses proximity neighbor selection (PNS).…”

“…Due to space constraints, we omit the discussion of RndRP algorithm which aims to evenly distribute subscriptions over RP nodes. Please refer to our technical report [24] for more detail.…”

“…The second purpose is to reduce the message size from a RP node to its finger table nodes (at this point, no subscriber ID list is carried in the messages) and therefore the bandwidth cost. For more detail of one-hop push, please refer to our technical report [24].…”

“…We may need to use a more efficient mechanism to publish the event to the RP nodes instead, e.g, multicast techniques. More discussion of this is presented in [24].…”