• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • CommentGo Back
Download
 
Compositional gossip: a conceptual architecture fordesigning gossip-based applications
Étienne Rivière Roberto Baldoni Harry Li José PereiraIRISA / Rennes 1 Univ. Roma Univ. "La Sapienza" Univ. of Texas at Austin Univ. of MinhoFrance Italy USA Portugal
eriviere@irisa.fr baldoni@dis.uniroma1.it harry@cs.utexas.edu jop@di.uminho.pt
ABSTRACT
Most proposed gossip-based systems use an ad-hoc design.We observe a low degree of reutilization among this propos-als. We present how this limits both the systematic devel-opment of gossip-based applications and the number of ap-plications that can benefit from gossip-based construction.We posit that these reinvent-the-wheel approaches poses asignificant barrier to the spread and usability of gossip pro-tocols.This paper advocates a conceptual design framework basedupon aggregating basic and predefined building blocks (B
2
).We show how to compose building blocks within our frame-work to construct more complex blocks to be used in gossip-based applications. The concept is further depicted withtwo gossip-based applications described using our buildingblocks.
Categories and Subject Descriptors
D.2.11 [
Software Engineering
]: Software Architectures;D.2.13 [
Software Engineering
]: Reusable Software
General Terms
Design, Algorithms, Standardization
Keywords
Gossip-based computing, Distributed Applications, Designframework
1. INTRODUCTION
The impact of global-scale applications such as file sharing(with BitTorrent, Overnet, ...) or the service platform un-derlying broadly used shopping sites such as Amazon, haveled to a surge in research in large scale distributed and de-centralized applications. Such applications demand a com-bination of fault-tolerance, decentralized control, and adapt-ability in dynamic settings that challenges established dis-tributed programming frameworks. Most strikingly, some-thing as basic as knowing the list of participant nodes isunachievable in this setting, thereby rendering many exist-ing techniques obsolete.In this context, gossip-based protocols have garnered in-creasing attention. Gossip protocols, sometimes referred asepidemic or probabilistic protocols, are deceptively simple.They are simple in that each process takes actions basedupon partial local information that is repeatedly exchangedwith a small set of peers. And they are deceptive in thatthose local steps lead to desirable global behavior such aseventually consistent states despite process and link failures.Starting from the early proposal from Demers
et al.
fordatabases maintenance [10], many distributed systems re-searchers and devolopers recognized the advantages thatgossip protocols offer to large-scale systems. As a result,further instances of successful gossip-based solutions existin multiple key application areas, among which we can citemulticast [31], membership management [1, 36], overlay con-struction [35, 13], eventual consistency [4] or publish andsubscribe systems [3, 34]. Despite some work identifyingseveral abstractions that promote separation of concernsfor gossip protocols and application design, and thereforemake a step towards the reuse of code among multiple pro-tocols [32, 20, 2, 17], there is no systematic approach todecompose applications into abstract entities capturing ba-sic gossip-based operations.This paper moves in that direction by presenting a concep-tual framework whose aim is to highlight the gossip-basedbuilding blocks (B
2
) of a distributed software architecture
1
.Such a conceptual framework would allow us to map novelapplications to existing solutions. This will turn out in amajor advantage for practitioners designing gossip based ap-plications by reusing gossip based B
2
s. In addition, it wouldhelp researchers to focus on well defined, self-contained prob-lems, and better compare their competing proposals.Section 2 presents a brief overview of gossip and its pros& cons. Section 3 proposes the generic abstract pattern of a gossip component. Section 4 focuses on identifying gos-sip B
2
s. Finally, in Section 5, we apply the framework todecompose two different publish/subscribe applications [3,
1
It is important to note that such applications are intrin-secally peer-to-peer, and we will not distinguish betweencomputing entities based on roles, although the proposedimplementation can obviously take into account node het-erogenety in their design rationales.
 
34], conveying the ability of our model to describe complexcomposed systems.
2. GOSSIP-BASED PROTOCOLS
In a typical gossip protocol, each node maintains a (partial)view of the nodes participating in the protocol. Periodically,each node exchanges messages with a randomly selected peerfrom its view. In some gossip protocols, the initiating node
pushes
information to its peer. In others, the initiating node
pulls
information from the peer.This simple communication pattern provides a robust wayto disseminate information in large-scale distributed sys-tems. Demers
et al.
[10] pioneered gossip in distributed sys-tems by using an epidemic approach to maintain consistencyacross databases on Xerox’s Clearinghouse servers. Birmanet al. [5] later used gossip to build a probabilistically reliablemulticast primitive. More recently, some have even lever-aged gossip to create the structure of logical networks andoverlays. This task is made easier by basic gossip-based pro-tocols that maintain up-to-date membership information.
When Gossiping is Good (or Bad).
In this paragraph, webriefly state what is our vision of gossip and what are the—current— best uses it has, from the application designerpoint of view. We invit the reader not to take it as a fixedconsensus, but rather as a position based on the currentstate of the art, a position that is prone to evolve with newadvances in research.Using gossip to solve distributed systems problems usuallytrades off safety guarantees for liveness and/or performance.We therefore should be careful both that probabilistic guar-antees are adequate for an application’s requirements andthat the target environment satisfies the probabilistic as-sumptions.Gossip is appropriate in non time-crictical systems, wherethe following properties are required or desired for the appli-cation: adaptivity and self-organization, scalability, robust-ness and simplicity of design & implementation. Most dis-tributed applications on the Internet present these require-ments. Notably, content distribution networks and theiraffiliated mechanisms are candidates to a gossip-based im-plementation ; as are communication systems, at the mid-dleware layer (event notification mechanisms, resource dis-covery). Other potential application we envision as primarytarget for a gossip-based implementation include monitoringand fault detection algorithms, and communication plat-forms and tools (such as RSS feeds update dissemination,discovery and maintenance of syndications systems, publickeys dissemination, and more). On should note that gossipproves also useful in applications with limited scalability.Specifically, gossip has been used in detecting failures forimplementing view synchronous group communication[30],garbage collection[14], and even for consensus[28]. The keyadvantage in these proposals is reducing the number of mes-sages each process sends and receives from quadratic (all-to-all) to linear (gossip).Gossip is inappropriate when a failure to meet a guaranteecan lead to catastraphic failure. As a rule of thumb, prob-abilistic safety guarantees are adequate when the output of the gossip protocol has a limited timespan and consequences.In contrast, the well-known use of group membership for se-lecting a primary for passive replication is not compatiblewith probabilistic safety guarantees, as even a transient fail-ure to identify a unique primary could lead to irreversibleinconsistency. Even when gossip seems to be a good fit fora problem, there is an additional danger. Analytical modelsand simulations of gossip protocols make a number of as-sumptions that are a poor fit with real world scenarios, es-pecially in wide area networks. In particular, assuming thatlinks and processes fail independently is at odds with real In-ternet topologies. Furthermore, assuming that all processesfail benignly in a system composed of thousands of machinesleaves an obvious security hole in many gossip protocols.Challenging traditional assumptions in gossip protocols anddesigning secure solutions is an active research area.
3. GENERIC BUILDING BLOCKS (B
2
S
)
In a gossip-based protocol, each node possesses a small lo-cal view of the network state: other nodes, shared data orvalues, .... A gossip-based protocol relies on local viewsat each node being eventually consistent, according to somedesired property. A protocol’s objectives are to: (i) havelocal views converge towards this properties
asap
and (ii)to cope with dynamicity be having these views as coherenti.r.t. the whole system as possible, at any time. These twoproperties are important also if this protocol is the basis foranother protocol functionnalities.We can define the use and construction of such views as thenetwork component sampling service. This service providesaccess to a set of samples from the global network; samplescan be the set of latest data items sent in the network (thusproviding a notification service); if it is a uniformly randomsample of nodes, the service is a peer sampling service. Thepeer sampling service is a sound basis to provide more com-plex protocols [2, 34]. We present this service as one of theblocks in section 4.1.Gossip-based protocols present common general function-nalities: (i) selecting peers with which to exchange infor-mation, (ii) determining which set of information to sharebetween nodes and (iii) updating the new local view.We observe two key sets here. First, we will denote SEL(
sel
ect) the set of nodes (IP adresses) from which a peer togossip with may be chosen. Second, we will denote EXC(
exc
hange) as the set of information (network componentsamples, that is, nodes, data, etc. ; depending on the pro-tocol) that is used as the local view and that is exchangedbetween peers.We will in the following consider these two sets as the maininputs the application designer has to link to any gossip-based protocol provided as an application B
2
. A gossip-based protocol has the goal to provide a local view to thenode that rely on some global desired property. This viewis the
out
put OUT of the block, and if it contains nodes itcan be used as a entry for the SEL and EXC sets of anotherblock. This provides the possibility to pile up gossip-basedprotocols to provide more complex protocols and propertiesto the application. Figure 1 depicts the generic principleof a B
2
in our framework, with its input and output. Note
 
 Local view Local view,
SELEXC
 Local view
Gossip−based protocol
Options and parameters
from the application or other block 
OUTGeneric Building Block
including nodes
Figure 1: A generic B
2
.
that only the SEL block itself is mandatory for any block,the presence and need for other depends on the protocol be-ing implemented. We present in the following section somefundamental blocks and examples of blocks composition.
4. BASIC B
2
SWe present basic B
2
of existing protocols that are promisingfoundations of more complex gossip-based applications. Welater show how to integrate these conceptual blocks to createmore complex services.
4.1 Fundamental services
Peer sampling service.
The peer sampling service [17] isresponsible for keeping the network consistent. It provideseach node running the service with a random sample of par-ticipating nodes. It is also in charge of discovering nodesthat have joined and nodes that have left, eventually inte-grating such information into local views. A goal of such aservice is to provide a set OUT of nodes samples that sharesproperties with random graphs [32, 6]. Each node shouldhave the same probability of being in another node’s viewas any other node. With high probability, random graphsremain connected. It has been shown that without a peersampling service, most upper level protocols never convergeto the desired state, as some nodes may never be discoveredand present in some other node view. Set OUT eventuallycontains only alive nodes drawn at random, and no failednodes. A newly joined node needs to appear in some othernodes’ OUT sets rapidly.Figure 2 presents the peer sampling
B
2
. This service re-quires only the node adress as an input, and uses a loopbackapproach from OUT to SEL to select random nodes to gos-sip with. The implementations of the peer sampling serviceare out of scope of this paper, and we refer the interestedreader to [17, 32]. One of the approaches is to shuffle thesets of peers for the two new OUT sets of nodes communi-cating during a gossipp phase, and has shown to be efficientyet very simple.
 Broadcast.
Broadcasting was the first problem for whichgossip-based solution were analyzed by researchers. Theseminal paper by Demers
et al.
[10] presents a gossip-basedprotocol to disseminate database consistency information,and show the inherent potential of such an approach. Thebroadcasting service selects nodes to gossip with in a nodesample view and exchange its set of data item with it. Theexchange is either uni-directionnal or bi-directionnal (push
Peer samplesCurrent node
OUTPeer Sampling Service
Size of the view, cycle period
EXCSEL
Figure 2: The peer sampling service B
2
.
*: Eventually contains all data sent to the network represented by the peer sample view
Broadcast
update mode (push, pull, both)
SELEXC
Set of data items*
OUT
Peer samples New data
Figure 3: A broadcasting service B
2
.
or pull approach, versus push-pull approach). Eventually,all nodes get new data items in O(log
N 
) steps of retrans-mission, provided the underlying node sample is uniformlydrawn from the set of nodes to which the data should bedisseminated
2
. The reliability of broadcast protocols basedupon gossip-based dissemination follows a bimodal distribu-tion [5, 7, 31, 15, 12, 11]. Broadcast protocols have beenproposed in different settings, such as replication mainte-nance [10], ad-hoc networks [16] and eventual consistency[4].Figure 3 represents the broadcast service. SEL is a set of peer samples from the set of nodes to which data has to bedisseminated, and EXC the data to disseminate (includingnew data from the node). The actual implementation of the broadcast protocol is left to the programmer, and a li-brary of blocks with diverse behaviors and possibilities willbe available to tackle all potential needs for gossip-baseddissemination.
4.2 Group composition
The following protocols share the common following goal.Their output (OUT set) is similar to the output of the PeerSampling service, in that they present a set of nodes as aview for the application or other B
2
s. However, these nodesare selected only among the nodes that satisfy some prop-erties, or predicates. We distinguish between membershipmanagement, where groups of nodes are formed based ontheir advertised memberships, network slicing where a set of nodes is constructed based on the size of the set relativelyto the whole network size (or sub-network, as group com-position blocks can be piled up), node provisioning wherea set of nodes of a desired size emerges and finally inter-est proximity-based composition where nodes with similar(expressed) semantics are grouped together.
2
That is the reason why using the peer sampling servicemakes sense here.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...