Block lectures on Gossip-based protocols

Transcription

1 Block lectures on Gossip-based protocols Lecture 1: dissemination, randomness and aggregation Dr. Etienne Rivière University of Neuchâtel Lectures funded by the EU commission as part of the H2020 Twinning project EBSIS

2 2 Introduction and context Unprecedented scale for distributed systems Peer-to-peer systems for file sharing, telephony, etc. The blockchain and emergent consensus Ad-hoc systems and mesh networks Support infrastructure for Cloud computing Nodes are not necessarily under the control of a single administrative domain Cannot use traditional client-server solutions

3 3 Example: peer-to-peer networks Peers run on normal users machines Application typically tied to the needs and available resources of the user Autonomous systems must implement some form ` of self-management Low level of trust and typically low nodes involvement Typical applications: file sharing, IP telephony,... a view of the Gnutella file sharing network Large-Scale Distributed Systems E. Rivière

4 4 Impact of scale on system design Large size (thousands, millions nodes) No global knowledge of the system Each node knows only a small subset of the system This subset is called the node s view Dynamic: nodes are leaving and joining all the time Consider failures as the common case and not as an exceptional event; use self-organizing designs Large-Scale Distributed Systems E. Rivière

5 5 Gossip-based protocols Simple yet powerful protocols for large-scale and dynamic distributed systems Based on simple interactions between pairs of peers Each peer knows a small subset of the system Peers exchange about what they know and update their local information as a result No complex protocol involving multiple nodes or distributed coordination Robustness based on randomness and diversity Ensure self-organizing properties The system continuously evolves towards a correct state regardless of its starting state Correction of faults is intrinsic to self organization

6 6 Objective of these block lectures Introduce the gossip-based paradigm and its applications Data dissemination Overlay creation and maintenance Aggregation computation Discuss implementation algorithmic tradeoffs made when implementing gossip-based protocols Present an example of a system composing multiple gossip-based protocols Publish/subscribe system

7 7 Outline Today Introduction Gossip-based data dissemination The Peer Sampling Service Gossip-based Aggregation Tomorrow Gossip-based overlay construction Introduction to publish/subscribe Case study: building a publish/subscribe network with combined Gossip-based protocols Conclusion

8 8 Gossip-based dissemination

9 9 Gossip-based dissemination Goal: spread a message to all peers Pair-wise exchange of information between peers Repeated, periodic interactions... with a random choice of communication partner... such that eventually, all peers have the message (with high probability) Coming next: 1. Case study: database replicas synchronization 2. Large-scale systems and random interactions

10 10 Demers et al s database replication and synchronization Considered as the first instance of gossip protocol Context: geo-distributed (medium scale) collection of database servers ClearingHouse system (for Xerox s corporate intranet) Database fully replicated to each of the servers Update from clients applied to a single (closest) replica Problem: how to propagate the updates to all other copies efficiently and for a low cost? Solution 1 (naive): Direct mail Solution 2: Anti-entropy Solution 3: Rumor mongering Combination

11 11 Direct mail (the naive idea) Each update has a timestamp Upon update u, notify all other sites immediately Update value if local timestamp < received timestamp Conflicts resolution is left to the application (also the case for other protocols) B D G I x No guarantees on message delivery Destination unreachable temporarily Incorrect destinations list (membership) x Generates n messages (1 per Site) for each update A C E F H

12 12 First gossip-based mechanism: Anti-entropy Each server lazily maintains the list of all other servers Periodically, each server Selects a partner at random in the list of all servers and perform a pair-wise sync of the entire DB with that server Period is a parameter e.g., every 60 minutes (depends on the rate of updates vs. risk of inconsistency) All server eventually see all updates Can be modeled using theory of epidemics Like a disease in the human population, the information spreads by pair-wise infections between individuals Infected = the server with a new/updated version of a row Virgin = the server with an old/previous/inexistent version

13 Anti-entropy 13 B D G I A E H C F A selects G at random A and G synchronize their database

14 Anti-entropy 14 B D G I A E H no effect! C F D selects A at random A and D synchronize their database C selects G at random C and G synchronize their database G selects F at random G and F synchronize their database

15 Anti-entropy 15 B D G I A no effect! E no effect! H no effect! C no effect! no effect! F no updates --> useless anti-entropy requests! (constant network traffic)

16 16 Anti-entropy (continued) How to synchronize databases using updates timestamps? Push: if local item is more recent, tell remote copy to update Good when most sites are virgin need the update Pull: ask remote node if its copy is newer. If so, update local copy Good when most sites are already up-to-date Push-pull: do both For each item keeps the newest version on any of the two machines All nodes get all updates even if membership lists are incomplete x Dissemination delay is high due to slow initial propagation, and depends on the gossip frequency x Gossiping more frequently results in many useless requests

17 Second gossip-based mechanism: Rumor mongering 17 When receiving an update, propagate it to f other sites These f nodes then propagate the update further Exponential growth of the number of infected nodes This is not a periodic protocol (but can be modeled as one) Also referred to as (controlled) flooding Similar to the spread of a rumor in a human population Requires a stop condition When must a node stop propagating a message it has received? No stop condition = the number of messages will grow exponentially

18 18 Rumor mongering: stop conditions (1/2) Stateless conditions Probability-based: stop with probability 1/k Feedback-based: stop with prob. 1/k if a destination site is already infected Simple and stateless x Setting k appropriately requires knowing the size of the network Condition based on node s state Maintain a memory of messages delivered to the application Only further propagate a message when received for the first time Simple x State can grow indefinitely (should we keep all messages identifiers?) x Effectiveness of the dissemination highly dependent on random choices at first peers

19 19 Rumor mongering: stop conditions (2/2) Conditions based on message state Hops-to-Live: messages start with a counter Each propagation decreases the counter, stop when counter = 0 Helps limit the number of messages x Fraction of the network reached depends on initial counter values x Difficult to decide on counter value without knowing the number of nodes A mix of these techniques

20 Rumor mongering (with hops-to-live stop condition) 20 B D G I HTL=2 A HTL=2 E H C F A initiates the mongering by selecting f=2 peers which will in turn propagate the value

21 Rumor mongering (with hops-to-live stop condition) 21 B D G I HTL=1 HTL=1 A HTL=1 E H C HTL=1 F C and D propagate further with a HTL decreased by 1 Useless communication to already informed nodes

22 Rumor mongering (with hops-to-live stop condition) 22 B D G I HTL=0 HTL=0 A E HTL=0 H C HTL=0 F E and F propagate further with a HTL of 0; only 1 message is useful Useless communication to already informed nodes

23 Rumor mongering (with hops-to-live stop condition) 23 B D G I A E H C F Rumor mongering has stopped but G and H are never notified

24 Rumor mongering: what is the cost of full coverage? Stop condition: Hops-to-Live Simulation of the dissemination of messages to nodes Coverage plot Average %age of peers that receive the message Complete plot %age of all dissemination that reached all peers Redundant plot Ratio between #sends to infected vs. #sends to virgins = overhead HTL Coverage HTL f HTL Redundant Complete f f 24

25 25 To recap Direct mail is ineffective and expensive Anti-entropy Ensures all nodes get the update x Slow and expensive: constant traffic even when no updates Rumor mongering x No insurance that 100% of the nodes receive the update Fast propagation of updates initially but then lots of useless propagations to notified nodes!

26 26 The best of both worlds Rumor mongering in a first phase Efficient in seeding the network initially Stops before there are too many duplicates Stop condition can be adapted based on autonomous selfobservation Anti-entropy as a complementary mechanism More source nodes from the initial rumor mongering: more efficient anti-entropy Ensures reliability even if membership lists not up-to-date

27 27 Large-scale systems and random interactions

28 Large-scale systems and random interactions Gossip-based dissemination good properties based on possibility of establishing random interactions Xerox medium-scale setting Each server knows all other servers The addition/deletion of a server is broadcasted to all servers by the maintenance team Lazy maintenance but full membership at all node Large-scale setting: impossible to maintain the full list of peers in the system at each node Still need the ability to pick nodes at random From the complete set of nodes Create and maintain a random overlay Each node should have only a local, small size view The view corresponds to the node s neighbors overlay IP network Logical links A Physical nodes B Logical nodes Physical links overlay network principle 28

29 29 The ideal random overlay The overlay is a directed graph V vertices (N nodes), E edges (links) Define c as the out-degree of a node n Number of edges from n ideal = Erdös-Rényi model: for each node n, create c vertices (n, m) with m selected uniformly at random in V \ {n} a random graph The Peer Sampling Service: maintain a random overlay in a large, decentralized distributed system

30 30 Use of the Peer Sampling Service Some node Outside world Gossip-based dissemination gossip-based interactions getpeer () returns a random peer from the entire network Peer Sampling Service gossip-based interactions

31 31 The Peer Sampling Service and its implementations

32 32 Goals of the PSS Maintain a small, dynamic, partial view of the network at each node The overlay between nodes should be as close to a random graph as possible Manages peers additions A new peer is eventually available in the view of some other peers A new peer is provided with its own view of random peers Manages peers deletions A deleted peer is eventually removed from the views of all other peers The Peer Sampling can itself be implemented using gossip

33 33 How to measure the quality of randomness? Compare with the Erdös-Rényi random graph Each node linked with c other nodes random picked at random Expected graph properties for the overlay Low diameter No clustering Balanced in-degree What do these properties mean?

34 How to measure the quality of randomness? 1. path length and diameter 34 Path length p(n,m) between two nodes n and m = smaller number of hops (consecutive links to follow) to reach m starting from n Directed graph: p(n,m) and p(m,n) can differ Diameter = maximal path length max(p(n,m)) Impact on dissemination x Large diameter: more exchanges for the last node to get the message (longest path) x Large average path length: more exchanges on average between the the creation at the source and the reception at any destination x Partition (diameter = + ): some nodes never get the message Objective: small diameter A random graph has both a small average path length and diameter, both in O(log N) hops

35 How to measure the quality of randomness? 2. clustering 35 Clustering: measure the presence of structures of aggregates Social network: high clustering Random graph: very low clustering Informally: are my neighbors neighbors themselves? Expressed as a ratio for each node: (directed) pairs of neighbors that are neighbors themselves = total possible (directed) pairs of neighbors Consider the average or the distribution of the ratio

36 How to measure the quality of randomness? 2. clustering D x1 B 36 x2 x2 A x2 H E G x1 x1 F x2 C x1 I Neighbors of A : B C D F G H 6 x 5 = 30 possible pairs clustering for A = 12 / 30 = 0.4

37 37 A social network has a high avg. clustering image by Brendan Griffen

38 How to measure the quality of randomness? 2. clustering 38 Impact on dissemination x High clustering: many redundant messages with rumor mongering x High clustering: less chance to choose a peer owning a new message with anti-entropy x High clustering: more risk of leading to large path length and to partitions if part of the system fails Low clustering: robustness to partitions, optimal spread Objective: minimal clustering (maximize randomness)

39 How to measure the quality of randomness? 3. in-degree distribution In-degree of a node n = how many nodes have n in their views (i.e. have links to n) Out-degree: by definition, fixed to the size of the view, c Random graph: Gaussian in-degree distribution around c Average in-degree is always c but distribution can vary between nodes 39 Impact on dissemination x Nodes with small in-degree: less chances to receive message in dissemination x Nodes with high in-degree: with rumor mongering, receive lots of replicates x In-degree imbalance: general load imbalance and impair convergence properties Objective: balanced distribution of in-degrees around c

40 40 PSS: basic operation Periodically picks a neighbor in the local view (selectpartner()) The information exchanged is a subset of the view itself selecttosend() to know what entries/links to send, selecttokeep() to decide what entries to keep from the union Active thread (peer P): while (true) { wait(gossip_period) Q = selectpartner() buf = selecttosend(local view) send buf to Q (wait) receive bufr from Q local view = selecttokeep() [ process local view ] } Passive thread (peer Q) while (true) { } receive bufr from any P buf = selecttosend(local view) send buf to P local view = selecttokeep() [ process local view ]

41 40 PSS: basic operation Periodically picks a neighbor in the local view (selectpartner()) The information exchanged is a subset of the view itself selecttosend() to know what entries/links to send, selecttokeep() to decide what entries to keep from the union Active thread (peer P): while (true) { wait(gossip_period) Q = selectpartner() buf = selecttosend(local view) send buf to Q (wait) receive bufr from Q local view = selecttokeep() [ process local view ] } Passive thread (peer Q) while (true) { } receive bufr from any P buf = selecttosend(local view) send buf to P local view = selecttokeep() [ process local view ] what is exchanged are links towards other nodes (view entries)

42 41 PSS: view entries and creation View composed of c entries IP:port (contact information for a peer) -- forming a link p q Each entry/link is associated with an age Entries are created with an age of 0 The protocol exchanges and copies view entries Each cycle increases the age of all entries in the view by 1 Creation of entries At each exchange, the 2 peers create entries with their identity and age 0 There is no other link creation During each cycle, each peer gets on average 1-2 new link(s) towards itself x Requires that the period of gossiping is the same for all peers, or peers with higher frequency may get higher in-degrees

43 42 selectpartner() The gossip partner is selected in the view itself RAND policy Select an entry uniformly at random TAIL policy Select the entry with the highest age Rationale: an entry will be tested to check if the peer is alive no later than c cycles after its creation

44 43 View exchange selecttosend() and selecttokeep() decide on which entries to send and which entries to keep from the union of the current view and the received entries Behavior controlled by two parameters H and S Exchange exch entries with H + S exch Typically, exch = c/2

45 44 View exchange: H (for Heal) Controls how many old entries (highest ages) should be discarded after each gossip exchange A higher value of H allows entries to stay in the system for a shorter time A dead peer is no longer creating entries to itself, and existing entries will die out faster H controls the ability to the system to quickly discard failed nodes from other nodes views x Both peers keep same entries that have lowest age Entry duplication In-degree of peers in these entries incremented (+1), and decremented (-1) in discarded entries: in-degree inbalance Creates clustering G age = 0 A H = exch = c / 2 = 1 entry to A created and sent to B B replies with entry to itself and newest entry D A combines, removes H=1 oldest entry (D) A increases ages G age = 1 age = 0 A H age = 2 age = 1 age = 0 age = 1 H B B D age = 1 D

46 45 View exchange: S (for Swap or Shuffle) H Controls the number of links that will be definitely swapped A swapped link is kept by the partner but not kept by the sender The age of entries is not relevant for swapping links x Links to failed peers may stay longer in the system The in-degree stays the same for all peers (since each peer creates one incoming link to itself per exchange) G age = 0 G A S = exch = c / 2 = 1 entry to A created and sent to B entry to H swapped from B to A A increases ages age = 0 A age = 3 age = 2 age = 1 H age = 0 age = 1 B B D age = 1 D age = 1

47 46 Wrapping it up Gossip-based conception framework for the Peer Sampling Pseudo-code of the algorithm provided in handout Based on simple table manipulations based on the values of H and S Implements the policies seen in previous slides Let s follow an example

48 On node P c = 8 ; exch = 4 S = 2 ; H = 1 ; TAIL On node Q 47 selectpartner() R L Z Q A M W E TAIL selects Q N L V B U F D S M W E A 1 L Q Z R 2 shuffle view selecttosend() M W E A 1 P 0 L Z R Q oldest H item to end of view M W E M W E P 0 tosend buffer of exch=4 entries exch-1 first entries, append self D S U N B F V L D S 3 4 U 5 Q 0 shuffle view, move H item to end of view D S 3 4 U 5 Q 0 tosend buffer of exch=4 entries exch-1 first entries, append self selecttosend()

49 On node P c = 8 ; exch = 4 S = 2 ; H = 1 ; TAIL On node Q 48 M W E A L Z R Q D S U Q D S U N B F V L M W E P append received items to view append received items to view selecttokeep() M W E A L Z R D S remove duplicates M W A L Z R D S U remove H=1 oldest item U 5 Q 0 Q 0 D S 3 4 U N B F V M W E remove H=1 oldest item P 0 selecttokeep() A L Z R D S U Q remove S=2 head items U N B F V U 5 M W E remove S=2 head items N B V M W E trim randomly to c=8 P 0 P 0 A 2 L Z R D S U increment ages Q 1

50 49 Examples of instances Blind: exch=c/2, H=0, S=0 Peers keep blindly a random set No aging mechanism Healer: exch=c, H=c, S=0 RAND partner selection Peers exchange their complete views On both sides, keep the c freshest entries out of the 2c entries Newscast protocol Swapper: exch=c/2, H=0, S=c/2 TAIL partner selection Exchange subset of views (c/2) Swap links between peers Cyclon protocol

51 50 Example 1: blind (the naive protocol)

52 Blind: example (the naive protocol) 51 B D G I A E H C F id B G E F

53 Blind: example (the naive protocol) 52 B D G I A E H C F id B G E F id D C I H A selectpeer() RAND policy

54 Blind: example (the naive protocol) 53 B D G I A E H C F id B G E F id D C I H A and E selecttosend H=0 S=0 peers chosen randomly

55 Blind: example (the naive protocol) 54 B D G I A E B C A E H C F id B G E F id D C I H A and E exchange

56 Blind: example (the naive protocol) 55 B D G I A E H C id B E F C id D I B A F random selection of 4 peers in the union of the view and received entries

57 56 Example I1: Healer (the NewsCast protocol)

58 Healer: example (the NewsCast protocol) 57 B D G I A E H C F id D H C B age

59 Healer: example (the NewsCast protocol) 58 B D G I A E H C F id age D 3 H 4 C 2 B 1 id age E 4 D 3 F 1 G 2 A selectpeer() RAND policy A selects C

60 Healer: example (the NewsCast protocol) 59 B D G I A E H C F id age D 3 H 4 B 1 C 0 E 4 D 3 F 1 G 2 selecttosend() exchange complete views + own fresh link (only shown for C)

61 Healer: example (the NewsCast protocol) 60 B D G I A E H C F id age C 0 F 1 B 1 G 2 selecttokeep() A keeps the freshest entries

62 Healer: example (the NewsCast protocol) 61 B D G I A E H C F id age C 0 F 1 B 1 G 2 id age A 0 B 1 F 1 G 2 selecttokeep() C keeps the freshest entries (details omitted)

63 Healer: example (the NewsCast protocol) 62 B D G I A E H C F id age C 1 F 2 B 2 G 3 id age A 0 B 1 F 1 G 2 Increase Ages increase the age of all entries in the active peer view

64 63 Example 1II: Swapper (the Cyclon protocol)

65 Swapper: example (the Cyclon protocol) 64 B D G I A E H C F id D H C B age

66 Swapper: example (the Cyclon protocol) 65 B D G I A E H C F id age D 3 H 4 C 2 B 1 A selectpeer() TAIL policy H has oldest age id age I 1 E 2 G 1 F 3

67 Swapper: example (the Cyclon protocol) 66 B D G I A E H C id age D 3 H 4 C 2 B 1 selecttosend() S=exch=c/2=2 H=0 A chooses one peer and sends its identity with age 0 H chooses randomly 2 entries -> shuffle links F id age I 1 E 2 G 1 F 3

68 Swapper: example (the Cyclon protocol) 67 B D G I D 3 A 0 A E H C I 1 H 0 F id D H C B Exchange id I E G F age age

69 Swapper: example (the Cyclon protocol) 68 B D G I A E H C F id age C 2 B 1 I 1 H 0 selecttokeep() replace sent links and partner with received links id age G 1 F 3 D 3 A 0

70 Swapper: example (the Cyclon protocol) 69 B D G I A E H C F id age C 3 B 2 I 2 H 1 Increase Ages increase the age of all entries in the active peer view id age G 1 F 3 D 3 A 0

71 70 Evaluation Experimental evaluation using simulations nodes View size c = 20 entries exch = 10 entries exchanged for each gossip exchange Metrics path lengths clustering in-degree distribution and convergence self-healing behavior and dynamic membership Compared to the random graph

72 Average path length 71 Swapper/Cyclon Healer/NewsCast Random/uniform

73 Clustering 72 Healer/NewsCast Swapper/Cyclon

74 In-degree distribution 73 Most concentrated in-degrees = Swapper/Cyclon Healer/Newscast is unbalanced Blind is the worst

75 Robustness / #partitions 74 Swapper/Cyclon Healer/NewsCast Random/uniform

76 Self-healing behavior 75 At some point, we kill half of the network Measure the % of dead links in nodes views and # of cycles to remove all dead links Depends mostly on the H parameter (how many age-based drops) Selection with rand or tail has a small impact

77 Self-healing behavior: real-world churn 76 Traces from the Gnutella file sharing system H=0 is bad, always even H=1 makes a difference

78 77 blind H=0, S=0 Swapper(Cyclon) H=0 S=c/2* healer(newscast) H=c/2* S=0 average path length small small (eq. to random) small clustering small small (eq. to random) high in-degree distribution very unbalanced balanced (eq. to random) unbalanced but balanced over time self-healing very bad bad good * : c/2 means half of the view

79 78 Gossip-based aggregation

80 79 Aggregation protocols Collective estimation of system-wide properties Each node holds an initial value Nodes exchange information though gossiping Eventually, all nodes are in possession of an aggregate of all local values Minimum value Maximal value Average value Variance Sum Product (these ones based on average) Large-Scale Distributed Systems E. Rivière

81 80 Assumptions Nodes contact each other at random Using the Peer Sampling Service Nodes update their local value based on its previous value and the received value from the other peer Large-Scale Distributed Systems E. Rivière

82 81 Computing min, max Consider the min / the max as the latest update and use gossip-based dissemination Use anti-entropy (maybe with rumor mongering) Nodes keep the minimal / maximal value after each exchange, and this value eventually replaces all higher / smaller values Large-Scale Distributed Systems E. Rivière

83 82 Computing the average Base operation for other computations Principle: P has a some value a[p] P selects Q, Q has value a[q] P and Q keeps (a[p] + a[q]) / Large-Scale Distributed Systems E. Rivière

84 83 Operation After each exchange The average over all nodes is not changed The variance is reduced If the graph is connected Each node converges towards the global average The variance converges to 0 The more you gossip, the closer to the real value How fast do we converge? Large-Scale Distributed Systems E. Rivière

85 84 A run of the protocol Large-Scale Distributed Systems E. Rivière

86 85 Computing other functions Min/Max: update(a,b) = min/max(a,b) Averages arithmetic avg: update(a,b) = (a+b)/2 geometric avg: update(a,b) = (a.b) ½ Others derived from averages Sum = average * N Product = (geometric mean) N Variance = average(x 2 ) - (average (x)) 2 But how do we know N??? Large-Scale Distributed Systems E. Rivière

87 86 Decentralized size estimation Large-Scale Distributed Systems E. Rivière

88 87 Motivation Estimating the size is often required for other protocols Setting the initial values of HTL and f for rumor mongering in the gossip-based dissemination protocol so as to effectively seed the network while avoiding duplicates For some aggregations System size can be estimated using gossipbased aggregation Large-Scale Distributed Systems E. Rivière

89 88 Estimating system size using gossip-based aggregation One node starts with 1, the others with 0 Compute the average using gossip-based aggregation Expected average: 1/N Let s consider that we can decide on the starting node for now Large-Scale Distributed Systems E. Rivière

90 Effect of massive failure ( nodes network) 89 x axis: time since the start of the epoch where 50% of the network is killed Large-Scale Distributed Systems E. Rivière

91 Effect of link failures ( nodes network) 90 Large-Scale Distributed Systems E. Rivière

92 Effect of message omissions ( nodes network) 91 Large-Scale Distributed Systems E. Rivière

93 92 Selecting the aggregation source Problem 1: how to select the node starting the aggregation? Problem 2: how to reduce the impact of aggregation being influenced by churn or early termination? Two birds with the same stone: run concurrent instances of the counting protocol each instance is led by a different node exchanged messages feature several ongoing aggregations aggregations have a limited lifespan (similar to HTL) control the number of ongoing aggregations: peers decide to start a new aggregation with a probability depending on previous size estimation Large-Scale Distributed Systems E. Rivière

94 Nodes failures and multiple instances ( nodes network) 93 Large-Scale Distributed Systems E. Rivière

95 Nodes failures and message omissions ( nodes network) 94 Large-Scale Distributed Systems E. Rivière

96 95 Varying size Large-Scale Distributed Systems E. Rivière

97 96 Intermediate conclusion Gossip-based protocols allow autonomous, self-organizing behaviors Randomness required for convergence/termination Role of the Peer Sampling Service Calculate global statistics and network size using gossip Tomorrow Constructing overlay using a gossip-based approach Application of all protocols covered to the problem of providing topic-based publish/subscribe

98 97 References Alan J. Demers, Daniel H. Greene, Carl Hauser, Wes Irish, John Larson, Scott Shenker, Howard E. Sturgis, Daniel C. Swinehart, Douglas B. Terry: Epidemic Algorithms for Replicated Database Maintenance. PODC 1987: 1-12 Norbert Tölgyesi, Márk Jelasity: Adaptive Peer Sampling with Newscast. Euro-Par 2009: Spyros Voulgaris, Daniela Gavidia, Maarten van Steen: CYCLON: Inexpensive Membership Management for Unstructured P2P Overlays. J. Network Syst. Manage. 13(2): (2005) Márk Jelasity, Spyros Voulgaris, Rachid Guerraoui, Anne-Marie Kermarrec, Maarten van Steen: Gossip-based peer sampling. ACM Trans. Comput. Syst. 25(3): 8 (2007) Márk Jelasity, Alberto Montresor, Özalp Babaoglu: Gossip-based aggregation in large dynamic networks. ACM Trans. Comput. Syst. 23(3): (2005)

99 98 Additional slides

100 99 Peer insertion How to insert a new peer p new? Create a new view for that peer Let other know about its existence Contact one existing peer p insert Perform a random walk from that peer c steps: p insert - p p i - - p c at each step, insert p new in the view of the peer p i get one peer from p i s view