Gossip protocol

1. Gossip protocol Michael Gustus Dmitriy Mosheyev Supervisor : Roie Melamed

2. Introduction

3. Introduction Consider the problem of designing a protocol that broadcasts messages to all of the processors in a network. One can be interested in different metrics of a broadcast protocol, such as: • the number of messages it generates, • the time needed for the broadcast to complete, • or the reliability of the protocol .

4. Introduction • Gossip protocols are probabilistic in nature: a node chooses its partner node with which to communicate randomly. • They are scalable because each node sends only a fixed number of messages, independent of the number of nodes in the network.

5. Introduction • In addition, a node does not wait for acknowledgments nor does it take some recovery action should an acknowledgment not arrive. • They achieve fault-tolerance because a node receives copies of a message from different nodes. • No node has a specific role to play, and so a failed node will not prevent other nodes from continuing sending messages. Hence, there is no need for failure detection or specific recovery actions.

6. Project Definition

7. Goal • The goal of this project is to implement the Gossip protocol in the GloMoSim network simulator.

8. Network Gossip Structure • Araneola dynamically constructs an overlay network, and spreads information by gossiping over this overlay.

9. Gossip Structure Neighbors:The immediate neighbors of the peer (the peer it is connected to). Receiving this vector of neighbor allows each peer to easily calculate vector-2, a vector of all the peers within a radius of two from the peer (the immediate neighbors of the peer are one link away from the peer where each neighbor of one of its immediate is two links away from it).

10. Gossip Structure Local View:Each peer maintains a local view, which contains random peers it is not connected to. These random peers are gossiped in order to: • avoid graph partition. • calculate the number of disjoint paths between any two peers.

11. The Join Mechanism • Each connection in the overlay is a duplex connection . • The number of duplex connections of a peer is called the peer’s rank. • Each peer strives to achieve a small constant rank, independent to the number of peers in the system. Typical values for this rank are 4 or 5. • A duplex connection in the overlay is created when one peer sends a join request to another peer and this request is accepted by the other peer.

12. Join? OK The Join Mechanism There are two opposite tendencies: • integrate a peer into the system as fast as possible; • maintaining a small rank by every peer. Araneola defines two kinds of requests with different priorities: • URGENT JOIN request • JOIN request

13. URGENT JOIN JOIN JOIN The Join Mechanism • An URGENT REQUEST will most likely be accepted where a “regular” JOIN request may be rejected. • Typically, upon joining the system, a peer will issue one URGENT JOIN request in order to integrate into the system and several other JOIN requests in order to achieve a higher reliability. Network Network

14. The Join Mechanism • Araneola defines four thresholds: • URGENT LOW • LOW • HIGH • URGENT HIGH • Every peer strives to achieve a rank equals to LOW. • Typical values for URGENT LOW is 1 and for LOW is 4-5, which means that the first request is an URGENT JOIN request while the following requests are JOIN requests.

15. The Join Mechanism • Accepting URGENT JOIN request: • If the rank of the peer who received the urgent request is lower than URGENT HIGH threshold, then the request is accepted. • Accepting JOIN request: • The rank of the peer who received the JOIN request is lower than HIGH threshold. • To avoid partitions in the overlay graph, the peer that receives the join request checks if accepting this request will create a “small” circle in the graph (a circle which consists of four or less peers connecting to each other).

16. Disconnecting Circles Whenever a peer’s rank exceed the LOW threshold, the peer tries to disconnect several of its connections until it reaches to a rank of LOW. • Periodically, though in small frequency, every peer exchanges its vector-2 with every other peer that is two links away from it. • Exchanging these vectors enables each peer to calculate vector-4, a vector, which includes every peer within a radius of four links from the specific peer. Network Network

17. Disconnecting Circles • A connection to a specific peer is removed only if there is a known other path to this peer (i.e., if there is a circle which contain the two peers in vector-4). • If such a circle is discovered, a disconnect request is issued trying to disconnect the circle. • Upon receiving a disconnect request, the peer checks if accepting this request will not result in truncation of vector-4 . This check is done in order to avoid a situation where simultaneously disconnect requests partition the graph. Network

18. GloMoSim simulator

19. GloMoSim simulator • GloMoSim is a scalable simulation environment for wireless and wired network systems. • It is being designed using the parallel discrete-event simulation capability provided by Parsec. • GloMoSim currently supports protocols for a wired, purely wireless network and hybrid network with both wired and wireless capabilities.

20. GloMoSim simulator • Most network systems are currently built using a layered approach that is similar to the OSI seven layer network architecture. The proposed protocol stack will include models for the channel, radio, MAC, network, transport, and higher layers. The protocols being shipped with the current library include the following:

21. Parsec Language • PARSEC - for PARallel Simulation Environment for Complex systems • is a C-based discrete-event simulation language. It adopts the process interaction approach to discrete-event simulation. An object (also referred to as a physical process) or set of objects in the physical system is represented by a logical process. • Interactions among physical processes (events) are modeled by timestamped message exchanges among the corresponding logical processes.

22. Parsec Language • One of the important distinguishing features of PARSEC is its ability to execute a discrete-event simulation model using several different asynchronous parallel simulation protocols on a variety of parallel architectures. PARSEC is designed to cleanly separate the description of a simulation model from the underlying simulation protocol, sequential or parallel, used to execute it. • PARSEC provides powerful message receiving constructs that result in shorter and more natural simulation programs. • File Extensions: .pc – C source code .h - C header files .pi – Message file created and maintained internally by Parsec (don’t edit)

23. Project Structure

24. Main Modules • The program is divided into four main modules: • Gossip - the Gossip protocol implementation in the single node. Includes all the connectivity and lifetime implementation of Gossip algorithm. • Gossip_LinkedList - the data structures used in the program to implement the LocalView and other different data bases stored in the single node.

25. Main Modules • Gossip_TX_Data - in this module we implemented the data sharing algorithm as it was defined in the Gossip protocol. This is the flow of data packets over the network in order to reach every node in the system. • Gossip_utility - this is the master module from which we control the processes in the Gossip network, like: • to know when the connectivity stage of the protocol is over. • when to start sending packets. • who produces new data packets and all its parameters. • of packets to be sent by each producing node.

26. Gossip Module • The protocol behavior defined by the messages each node sends and receives. • There are 8 different message types: • MSG_APP_UrjentJoin – urgent join request from another node. • MSG_APP_Join – join request from another node. • MSG_APP_WakeUp – when received this message the node if it is not participating in the Gossip will try to enter the Gossip network by throwing a coin. This message can be sent by the utility node or the node itself. • MSG_APP_Accept_Join – the message is received when node’s Join request was accepted by another node.

27. Gossip Module • MSG_APP_Decline_Join – the message is received when node’s Join request was declined by another node. • MSG_APP_Disconnect – the message is received when the node was disconnected from other node from any reason. • MSG_APP_ProduceDataPacket – the message is received by the producing node then it is time to produce a new data packet. • MSG_APP_DataPacket– the message is received when a new data packet is arrived.

28. Gossip_TX_Data Module • In this module we define the structure that each node holds when sending/receiving data packets: typedef struct gossip_tx_data_str { FILE* recFile; // pointer to log-file of received packets FILE* prodFile; // pointer to log-file of produced packets int** packetSeqNum; // seqNums of received packets from other nodes BOOL producePackets; // do I produce my own packets int packetsToProduce; // number of packets I need to produce int mySeqNum; // next seqNum of my packet double produceDelay; // delay between packets in seconds } GossipTXData;

29. Gossip_utility Module • This module uses one network node as the utility node. This node doesn’t participate in the Gossip protocol and it is used only to control the processes in the Gossip network. • We use it to know when we have reached the static mode after the connectivity stage of the protocol is over. • When to start sending packets. • To set the parameters of the producing nodes.

30. User Guide

31. Environment To run the simulation on the Microsoft Windows platform, first we need the following products to be installed on the computer: • Microsoft Visual Studio 6 • Parsec compiler • GloMoSim simulator The Parsec compiler and GloMoSim simulator you can download here: http://pcl.cs.ucla.edu/projects/glomosim/obtaining_glomosim.html

32. Installing Parsec and Glomosim • Download the compressed Parsec and Glomosim files to your machine. • Uncompress the Parsec file into some directory: • unzip parsec.zip • Move the platform specific Parsec directory tree to the desired place on your disk.

33. Parsec environment using VC++ • Set global environmental variables: • set PATH = %PATH%; ......\parsec\windowsnt-4.0-vc6\bin • set PCC_DIRECTORY = ......\parsec\windowsnt-4.0-vc6 • Set environmental variables of Visual Studio 6 by running the file VCVARS32.BAT that is found in the Visual Studio folder.

34. Installing Glomosim • Uncompress the Glomosim library. • Change the directory to main. • make (or “makent” on NT), to build Glomosim.

35. Compiling the project • To compile the program: • open the cmd session. • run the VCVARS32.BAT file from the Visual Studio. • go to directory main in the glomosim. • compile the project by running the file make.bat.

36. Running the project • If the compiling stage finished successfully the main executable file glomosim.exe is created in the bin directory. • To run the project you need 2 configuration files to be set as will be explained later. • The configuration files are: • config.in • app.conf • To run the program: • go to directory bin in the glomosim. • configure the config.in and app.conf to your needs. • in the cmd session run: “glomosim config.in”

37. Configuration files • There are two configuration files containing the project parameters that can be changed. • config.in NUMBER-OF-NODES - This parameter represents the number of nodes being simulated. • app.conf GOSSIP<numOfProduceNodes> <itemsToSend> <delay> <probability> where: • <numOfProduceNodes> – number of nodes that produce new packets. • <itemsToSend> – number of new packets each producing node must send. • <delay> – delay between packets in seconds. (NanoSecond = 0.000000001 sec). • <probability> – the probability for data packet to be lost, and not to get to its destination. Probability range is 0-100: 0 - no loses, 100 - 100% loses.

38. Results Processing During the execution, the program generates two output files for each node in the network. One file is for the received packets, and the other file is for the new packet that this node produced and sent. These files are located in the results directory. We used the Perl script calc.pl to process these result files. calc.pl usage: perl calc -orr all output.csv

39. Results

40. Protocol performance with packet loss • Test purpose: • To show the loss packet probability affect on reliability of the protocol. • Test parameters: • Thresholds: • Urgent Low = 1 • Urgent Low = 4 • High = 10 • Urgent High = 15 • Number of sending nodes = 1 • Number of sent packets for each sending node = 50 • Number of nodes = 100

41. Protocol performance with packet loss • The first row indicates the loss packet probability. • The first column indicates the number of rounds it took to protocol to distribute the packets. • Results: • In the following table we collected the results from the tests with different packets loss probability.

42. Protocol performance with packet loss

43. Protocol performance with packet loss Explanation: • Here we can see that the bigger percentage of packet loss probability the less reliability, moreover the protocol remain pretty reliable even with 50% packet loss. • The number of rounds it takes to distribute packets is bigger for packets with high packet loss probability. • More than 80% of the packets arrive to their destination at the fourth round. This happens due to the fact that the protocol builds graph, and for current configuration (the thresholds and number of nodes) the depth of the spanning tree of this graph is ~4, so it takes ~4 rounds to distribute packets to their destination.

44. Probability dependence of packets loss This is another way of looking on how the packet loss probability affects the reliability. For the packet loss probability less than 50%, the reliability is pretty good (~90%).

45. Packet loss between 0% and 30% • Test purpose: • To show the packet loss probability affect on reliability of the protocol in the range 0f 0 to 30%. This is very interesting due to the fact that real internet conditions are quite similar to these values. • Test parameters: • Thresholds: • Urgent Low = 1 • Urgent Low = 4 • High = 10 • Urgent High = 15 • Number of sending nodes = 1 • Number of sent packets for each sending node = 50 • Number of nodes = 100

46. Protocol performance with packet loss • Results: • In the following table we collected the results from the tests with different packets loss probability.

47. Protocol performance with packet loss

48. Protocol performance with packet loss • The results in the range of 0-30% packets loss show pretty good reliability of the Gossip protocol.

49. Thresholds effect • Test purpose: • To show the affect of thresholds on the reliability results. In this test we set the thresholds to be lower then the original, this means that every node will strive for not more than 2 neighbors. • Test parameters: • Thresholds: • Urgent Low = 1 • Urgent Low = 2 • High = 5 • Urgent High = 8 • Number of sending nodes = 1 • Number of sent packets for each sending node = 50 • Number of nodes = 100

50. Thresholds effect In the following table we collected the results from the tests with different packets loss probability.