‫ מכון טכנולוגי לישראל‬- ‫הטכניון‬
Project Book
Gossip protocol
Supervisor:
Roie Melamed
Students:
Michael Gustus
Dmitriy Mosheyev
1.
2.
3.
4.
Introduction............................................................................................................. 3
Protocol Definition ................................................................................................. 7
GloMoSim Simulator ............................................................................................. 12
Project Structure ................................................................................................. 19
4.1
Main Modules ................................................................................................ 20
5. User Guide .............................................................................................................. 25
5.2
Needed programs......................................................................................... 26
5.3
Compiling the project.................................................................................. 27
5.4
Running the project ..................................................................................... 27
5.5
Configuring the program parameters...................................................... 28
5.6
Results processing ....................................................................................... 29
6. Results ..................................................................................................................... 30
6.1
Protocol performance with packet loss ................................................... 31
6.2
Probability dependence of packets loss ................................................. 34
6.3
Packet loss between 0% and 30% ............................................................ 35
6.4
Thresholds effect ....................................................................................... 38
Probability dependence of packets loss .......................................... 41
6.5
Network size effect ................................................................................... 42
1. Introduction
Abstract
Probabilistic gossip-based dissemination (multicast) protocols
provide good scalability and reliability properties. In these
protocols, each member is in charge of forwarding each message to
a set of other, randomly chosen, group members. This pro-active
use of redundant messages provides a mechanism for ensuring
reliability in the face of node crashes and high packet loss rates in
the network. It can also be shown that the load on each node
increases only logarithmically with the size of the group, so these
algorithms are scalable. Receiving multiple copies of each
multicast in gossip-based protocols is considered a “necessary
evil" to achieve the given probabilistic reliability. However, when
the underlying network has few or no message losses and process
failures during the dissemination of a multicast, Flat Gossiping
(“regular” gossip-based dissemination protocol) incurs this
overhead. Recently, Hierarchical Gossiping Protocol was designed.
This Hierarchical Gossiping algorithm imposes a much smaller
network overhead than Flat Gossiping, with only a logarithmic rise
in multicast dissemination latency.
Gossip protocol background
Rumor mongering (also known as gossip) is an epidemiological protocol
that implements broadcasting with a reliability that can be very high. Rumor
mongering is attractive because it is generic, scalable, adapts well to failures
and recoveries, and has a reliability that gracefully degrades with the number
of failures in a run.
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 (where
reliability is the probability that either all or no non-faulty processors deliver
a broadcast message and that all non-faulty processors deliver the message if
the sender is non-faulty).
With the metrics of interest in mind, there are two general approaches one
might approach designing a broadcast protocol.
One approach would be to build upon the specific physical properties of the
network. For example, there are several broadcast protocols that attain very
high reliability for Ethernet networks or redundant Ethernets. Such a
protocol can be very efficient in terms of the chosen metrics because one can
leverage off of the particularities of the network. On the other hand, such a
protocol is not very portable, since it depends so much on the physical
properties of the network.
The other approach is to assume a generic network. With this approach, one
chooses a set of basic network communication abstractions such as sending
and receiving a message. If reliability is a concern, then one can adopt a
failure model that is generic enough to apply to many different physical
networks. There are many examples of reliable broadcast protocols for such
generic networks.
Unfortunately many reliable broadcast protocols do not scale well to large
numbers of processors. A family of protocols for generic networks that are
scalable are called epidemiological algorithms or gossip protocols. Gossip
protocols are probabilistic in nature: a processor chooses its partner
processors with which to communicate randomly. They are scalable because
each processor sends only a fixed number of messages, independent of the
number of processors in the network. In addition, a processor does not wait
for acknowledgments nor does it take some recovery action should an
acknowledgment not arrive. They achieve fault-tolerance because a
processor receives copies of a message from different processors. No
processor has a specific role to play, and so a failed processor will not
prevent other processors from continuing sending messages. Hence, there is
no need for failure detection or specific recovery actions.
A drawback of gossip protocols is the number of messages that they send.
Indeed, one class of gossip protocols (called anti-entropy protocols) send an
unbounded number of messages in non-terminating runs. Such protocols
seem to be the only practical way that one can implement a gossip protocol
that attains a high reliability in an environment in which links can fail for
long periods of time. Hence, when gossiping in a large wide-area network,
anti-entropy protocols are often used to ensure high reliability. However, for
applications that require timely delivery, the notion of reliability provided by
anti-entropy may not be strong enough since it is based on the premise of
eventual delivery of messages.
Another class of gossip protocols is called rumor mongering. Unlike antientropy, these protocols terminate and so the number of messages that are
sent is bounded.
The reliability may not be as high as anti-entropy, but one can trade off the
number of messages sent with reliability.
Rumor mongering by itself is not appropriate for networks that can partition
with the prolonged failure of a few links, and so is best applied to local-area
networks and small wide-area networks.
2. Protocol
Definition
Araneola – Introduction
Araneola is a scalable reliable multicast system for dynamic environment.
Araneola dynamically constructs an overlay network, and spreads
information by gossiping over this overlay. Araneola’s overlay strives to
achieve the main features of Harary graphs, that is to have multiple disjoint
paths between every pair of peers and a bounded degree. Moreover,
Araneola’s overlay strives to achieve a diameter that is logarithmic in the
number of peers. While the system is evolving, some of these desirable
properties may temporarily not hold. However, the system converges to a
state where they do hold. The measurements show that even in highly
dynamic settings, these properties hold most of the time.
Gossip Messages
Each Araneola peer periodically sends gossip messages to all its neighbors.
Each gossip message contains the following information:
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). An optimization
to sending the list of neighbors is sending this list only if it was changed.
Random peers. Each peer maintains a local view, which contains random
peers it is not connected to. These random peers are gossiped in order to: (1)
avoid graph partition; and (2) calculate the number of disjoint paths between
any two peers.
Recent identifiers. Identifiers of messages received since the last gossip
round.
Requests for transmission. Identifiers of messages the peer did not receive.
Attached to each peer its location in the two dimensional space.
The Join Mechanism
Each connection in the overlay is a duplex connection (i.e., if peer A is
connected to peer B than peer A sends and receives messages from peer B).
The number of duplex connections of a peer is called the peer’s rank and
two peers that share the same connection are called neighbors. 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.
There are two opposite tendencies:
(1) integrate a peer into the system as fast as possible; and
(2) maintaining a small rank by every peer.
Araneola’s philosophy says the following:
Integrate a new peer into the system (almost) as far as possible even in the
price of temporarily overloaded peers. However, in order not to overload too
many peers even temporarily, Araneola defines two kinds of requests with
different priorities.
 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 REQUEST in order to
integrate into the system and several other JOIN requests in order to
achieve a higher reliability. The first urgent join will most likely get
accepted, enabling the peer to integrate into the system as fast as
possible where the following requests may be rejected if their targets
are already overloaded peers. The peer will keep issuing join requests
(to different peers) until its rank equals to the LOW threshold.
More formally, Araneola defines four thresholds:
 URGENT LOW
 LOW
 HIGH
 URGENT HIGH
Any peer strives to achieve a rank equals to LOW. Upon bootstrapping, a
peer issues an URGENT LOW request (urgent request) and the following
requests (LOW minus URGENT LOW requests) are JOIN requests. Typical
values for URGENT LOW and LOW are 1 and 4-5 respectively, which
means that the first request is an urgent request while the following requests
are JOIN requests. Setting URGENT LOW to one enables a peer to quickly
integrate into the system though id doesn’t burden too much on the system.
Pay attention that the values of LOW are constant, independent to the
number of peers in the system.
What is the criterion to accept/reject an URGENT JOIN/JOIN?
The only criteria for accepting/rejecting an urgent request is the following
criteria:
 If the rank of the peer who received the urgent request is lower than
URGENT HIGH threshold, then the request is accepted.
The algorithm for accepting/rejecting a regular join request is more
complicated:
 First, the same criteria which is used for an urgent request is activated
though the threshold this time is HIGH and not URGENT HIGH.
Clearly, the value of HIGH is lower than the value of URGENT
HIGH.
 In addition, 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).
If accepting this request will indeed create a small circle in the graph, the
request will be rejected. Attached to each join request a vector of peers,
which are in radius of two links from the peer that issued the join request
(vector-2 as described above). Upon receiving a join request, the peer checks
it its vector-2 intersects with the vector attached to the request. If these two
vectors do intersect then clearly accepting the request will create a small
circle. Thus, such requests are rejected. Otherwise, the request is accepted.
Disconnecting Circles
The previous subsection described how connections are made. However,
reading the previous subsection raises the following question: How can a
peer’s rank be reduced?
This subsection will explain how a peer can disconnect several of its
connections without reducing the number of peers, which are reachable from
the peer.
1. Periodically, though in small frequency, every peer exchanges its
vector-2 with every other peer that is two links away from it.
2. 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.
3. 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. 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. If the rank of each
peer is also attached in any gossip message, clearly, it is better to
disconnect the connection to the peer with a higher rank. Upon
receiving a disconnect request, the peer checks if accepting this
request will not result in truncation of vector-4 (i.e., after accepting
this request the peer will not have a sure direct path between it to
several peers in vector-4). This check is done in order to avoid a
situation where simultaneously disconnect requests partition the
graph.
3. GloMoSim
Simulator
GloMoSim simulator
Introduction
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.
Most network systems are currently built using a layered approach that is
similar to the OSI seven layer network architecture. The plan is to build
GloMoSim using a similar layered approach. Standard APIs will be used
between the different simulation layers. This will allow the rapid integration
of models developed at different layers by different people. The goal is to
build a library of parallelized models that can be used for the evaluation of a
variety of wireless network protocols. 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:
Layers
Protocols
Mobility
Random waypoint, Random drunken, Trace based
Radio Propagation
Two ray and Free space
Radio Model
Noise Accumulating
Packet Reception
Models
SNR bounded, BER based with BPSK/QPSK modulation
Data Link (MAC)
CSMA, IEEE 802.11 and MACA
Network (Routing)
IP with AODV, Bellman-Ford, DSR, Fisheye, LAR scheme 1,
ODMRP, WRP
Transport
TCP and UDP
Application
CBR, FTP, HTTP and Telnet
To run GloMoSim, you will need the latest Parsec compiler (now included
with the GloMoSim distribution). If you want to develop your protocols in
GloMoSim, you should have some familiarity with Parsec, but you don't
need to be an expert. Most protocol developers will be writing purely C code
with some Parsec functions for time management. Hence, you will need to
use the Parsec compiler. Parsec code is used extensively in the GloMoSim
kernel. Most users do not need to know how the kernel works. If you are
interested in the GloMoSim kernel, you will need to have extensive
knowledge about Parsec.
Parsec Language
Parsec is a C-based simulation language, developed by the Parallel
Computing Laboratory at UCLA, for sequential and parallel
execution of discrete-event simulation models. It can also be used
as a parallel programming 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.
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. Thus, with few modifications, a PARSEC
program may be executed using the traditional sequential (Global Event
List) simulation protocol or one of many parallel optimistic or conservative
protocols.
In addition, PARSEC provides powerful message receiving constructs that
result in shorter and more natural simulation programs. Useful debugging
facilities are available.
The PARSEC language is derived from Maisie, but with several
improvements, both in the syntax of the language and in its execution
environment. Appendix "C" contains information about converting existing
Maisie programs into PARSEC.
Message Communication
Entities communicate with each other via buffered message passing. A
unique message buffer is associated with each entity. Asynchronous send
and receive primitives are provided to respectively deposit and remove
messages from the message buffer of an entity. The receive primitive may
also be used to advance the simulation clock.
PARSEC uses typed messages. A message-type consists of a name and a
parameter list. The following syntax is used to define a message-type:
Message-def
::=
message ident { declarations} [ident]...;
Declarations
::=
[type ident[,ident]...;]...
Type
::=
ename | clocktype | message ident | any C type
declaration
Message definition is syntactically similar to the declaration of a C struct.
Message parameters may be viewed as fields defined within a struct and are
referenced using the same operator as used to reference fields within a
struct. A message-type with an empty parameter-list is used to define signals
(e.g., acknowledgments). Message type declarations are treated as global
(even if declared within an entity body), so it is standard to declare all
message types at the head of the file, or in a separate header file.
As with entity parameters, message parameters can include arrays, but they
must be given explicit sizes, and they will be passed by value.
1. Sending Messages
The send statement performs an asynchronous send: the sending entity
copies the message parameters into a memory block, delivers the message to
the underlying communication network, and resumes execution. Every
message is implicitly timestamped with the current value of the simulation
clock. The programmer may specify a different timestamp by using the
optional ``after time-expr'' attribute--this causes the timestamp of the
message to be set to the current simulation time plus time-expr. (In a
simulation, the after clause is used to model transmission delay, i.e. the
message leaves here now, but arrives there after time-expr time units.) A
message is delivered to the destination buffer at the simulation time
specified by its timestamp.
Messages are received by an entity in their timestamp order. Messages with
the same timestamp from a common source are received in the order they are
sent; however no a priori ordering can be assumed for messages with the
same timestamp received from multiple sources.
2. Receiving a Message
The receive statement consists of one or more resume clauses, and possibly a
timeout clause. Each resume clause consists of a read-only message variable,
and an optional guard followed by a statement. If the message buffer
contains exactly one enabling message, the message is removed from the
buffer and delivered to the entity in variable mvar. The variable mvar is a
read-only variable, and its scope extends only to the statement which is part
of the resume clause. The timeout clause specifies a wait time (tc), and may
specify either timeout-first or timeout-last semantics, using the in and after
keywords, respectively. Timeout semantics will be discussed subsequently.
When a message is received, the internal clock of the entity will advance to
the greater of 1) the time specified on the timestamp of the message, or 2)
the current time of the entity. Thus the entity's clock moves monotonically
forward.
If two or more resume clauses in a receive statement are enabled, the
timestamps on the corresponding enabling messages are compared and the
message with the earliest timestamp is removed and delivered to the entity.
If the message timestamps are equal, and neither one of the messages is a
timeout, an enabling message is selected non-deterministically for delivery
to the entity. An entity is said to be suspended if none of its resume clauses
are enabled. A suspended entity resumes execution if it receives an enabling
message. If an entity executes a receive statement that includes only local
guards and all guards evaluate to false, the runtime system will print a
warning message, and skip the corresponding receive statement.
3. Clock Operations
In order to allow simulations to be executed over longer durations with fine
grained clock values, the PARSEC system clock is implemented as a large
integral type called clocktype. All clock operations make use of clocktype
variables. The following functions are provided to manipulate the simulation
clock:




simclock(void): This function returns the value of the current
simulation clock as a clocktype value.
setmaxclock(clocktype): This function sets the maximum
simulation time to the value specified in the numerical-string. The
simulation is terminated when the simulation clock exceeds this value.
atoc(char*, clocktype): Places the clocktype value
represented by the string in the clocktype parameter.
ctoa(clocktype, char*): Like sprintf, it prints the value of
the clocktype parameter into the string parameter.
Example:
clocktype time = (clocktype) 100000000;
/* set maximum simulation time to 100,000,000 */
setmaxclock(time);
The value CLOCKTYPE_MAX is predefined to contain the maximum value
of clocktype. The default C type for clocktype is unsigned long, a 32 bit
integer. The programmer may specify a larger type by using the compilerÆs
ûclock flag.
4. File Extensions:
 .pc – C source code
 .h - C header files
 .pi – Message file created and maintained internally by Parsec (don’t
edit)
4. Project
Structure
4.1 Main Modules
The program is divided to 4 main moduls :
 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.
 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:
1.
2.
3.
4.
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.
number of packets to be sent by each producing node.
1. Gossip Module
Includes the following most important functions:
void AppLayerGossip()
The main function in the node that models the behavior of Gossip
protocol. It receives the message encapsulated in msg struct and
behaves according to it.
Message types that can be received by the single node:
 MSG_APP_UrjentJoin – UrjentJoin 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.
 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.
void nextJob()
In this function the node decides what to do next according to the
different parameters of the node that are defined in the Gossip
protocol.
AppGossipInit()
The function is called then the node is borne. Initializes the node
and sends the first MSG_APP_WakeUp to itself.
disconnectCircles()
The function implements the algorithm to discover the circles of 3
or 4 nodes in the network as it was defined in the Gossip protocol.
AppGossipFinalize()
The function is called in the end of the simulation then the node is
being deleted.
2. 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;
FILE* prodFile;
int** packetSeqNum;
BOOL producePackets;
int packetsToProduce;
int mySeqNum;
double produceDelay;
} GossipTXData;
// pointer to log-file of received packets
// pointer to log-file of produced packets
// seqNums of received packets from other nodes
// do I produce my own packets
// number of packets I need to produce
// next seqNum of my packet
// delay between packets in seconds
Includes the following most important functions:
receiveDataPacket()
Is called then the new data packet is arrived. Updates the node’s
info, the log-file and calls the passDataPacket().
passDataPacket()
Passes the new data packet that arrived to all the neighbors of the
node using the sendDataPacket().
sendDataPacket()
Sends the packet to the target node and updates its fields.
produceDataPacket()
The function is used only in the nodes that produce new data
packets. It is called when its time produce a new packet. Allocates
the new packet, initializes its fields and sends it to all the neighbors
of the packet author using the passDataPacket().
3. 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.
The module includes the following most important functions:
utilityMsgReceive()
This function is similar to the function AppLayerGossip() in the
Gossip module. The function receives special utility messages
encapsulated in msg struct and behaves according to it.
For now, the only message that can be received by the utility node
is:
 MSG_APP_NewIteration – used to count round-iterations
in the system. According to this data the utility module
decides what to do next.
utilityNextJob()
In this function the utility node decides what to do next according
to the current iteration number.
5. User Guide
5.2 Needed programs
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
The information about installation of Parsec and GloMoSim can be
found on their web site:
http://pcl.cs.ucla.edu/slides/workshop99/Jaytut-pw99/sld006.htm
Set global environmental variables:
set PATH = %PATH%;...... \parsec\windowsnt-4.0vc6\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.
5.3 Compiling the project
Every network layer in the GloMoSim simulator is located in its
own directory. Gossip is an Application layer protocol and all its
files are located in the application folder.
To compile the program:
1. open the cmd session.
2. run the VCVARS32.BAT file from the Visual Studio.
3. go to directory main in the glomosim.
4. compile the project by running the file make.bat.
The main files of the Gossip protocol are:
gossip.pc
gossip_TX_Data.pc
gossip_utility.pc
gossip_LinkedList.pc
gossip.h
gossip_TX_Data.h
gossip_utility.h
gossip_LinkedList.h
5.4 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:
1. go to directory bin in the glomosim.
2. configure the config.in and app.conf to your needs.
3. in the cmd session run:
glomosim config.in
5.5 Configuring the program parameters
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.
5.6 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 packets 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
6. Results
6.1 Protocol performance with packet loss
Test purpose:
To show the loss packet probability affect on reliability of the
protocol.
Test parameters:
a. Thresholds:
i.
ii.
iii.
iv.
Urgent Low = 1
Urgent Low = 4
High = 10
Urgent High = 15
b. Number of sending nodes = 1
c. Number of send packets for each sending node = 50
d. Number of nodes = 100
Results:
In the following table we collected the results from the tests with
different packets loss probability.
The first row indicates the loss packet probability while the first
column indicates the number of rounds it took to protocol to
distribute the packets.
0
10
20
30
40
50
60
70
80
90
95
100
0
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
1
0.07
0.0916
0.0634
0.0662
0.0512
0.051
0.0298
0.0302
0.0212
0.0198
0.0122
2
0.38
0.4096
0.281
0.2364
0.1518
0.1312
0.0668
0.0564
0.0348
0.0254
0.013
3
0.89
0.8968
0.72
0.5982
0.3708
0.2892
0.1234
0.089
0.0448
0.0274
0.0132
4
1
0.9998
0.9734
0.8964
0.6526
0.5
0.2002
0.1234
0.0532
0.0282
1
0.9988
0.9818
0.8494
0.6988
0.2934
0.1642
0.0594
0.029
0.9994
0.9932
0.9308
0.8308
0.3912
0.2014
0.0644
0.9948
0.9536
0.8956
0.4762
0.2348
0.0682
8
0.9584
0.9238
0.548
0.265
0.0716
9
0.9592
0.9324
0.605
0.2872
0.0738
10
0.9594
0.9348
0.6462
0.3046
0.0744
11
0.9356
0.6726
0.3206
12
0.9364
0.6898
0.331
13
0.6984
0.3368
14
0.7048
0.3402
15
0.7082
0.3434
16
0.7094
0.3462
17
0.7102
0.3482
18
0.711
0.3496
19
0.7116
0.3502
20
0.712
0.3504
21
0.7122
0.3506
22
0.7124
0.3508
5
6
7
Table 1.
1.2
1
0
10
20
Relibility
0.8
30
40
50
0.6
60
70
80
0.4
90
95
100
0.2
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Number of Rounds
Graph 1.
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.
 Also the number of rounds it takes to distribute packets is
bigger for packets with high packet loss probability.
 We can also see that 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.
6.2 Probability dependence of packets loss
1.2
1
Relibility
0.8
0.6
0.4
0.2
0
0
10
20
30
40
50
60
70
80
90
Packet Loss Probability
Graph 2.
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%).
100
6.3 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:
e. Thresholds:
i.
ii.
iii.
iv.
Urgent Low = 1
Urgent Low = 4
High = 10
Urgent High = 15
f. Number of sending nodes = 1
g. Number of send packets for each sending node = 50
h. Number of nodes = 100
Results:
In the following table we collected the results from the tests with
different packets loss probability.
0
0.01
0.07
0.38
0.89
1
0
1
2
3
4
5
6
7
3
0.01
0.0886
0.405
0.9612
1
6
0.01
0.0658
0.3284
0.8426
0.9994
1
9
0.01
0.0796
0.4114
0.914
0.9982
1
10
0.01
0.0916
0.4096
0.8968
0.9998
1
12
0.01
0.0892
0.3854
0.8822
0.9972
0.9998
15
0.01
0.0762
0.3306
0.81
0.992
0.9996
18
0.01
0.0796
0.3346
0.768
0.9858
0.9994
20
0.01
0.0634
0.281
0.72
0.9734
0.9988
0.9994
21
0.01
0.0676
0.248
0.6274
0.9346
0.995
0.9986
24
0.01
0.0474
0.1924
0.5192
0.8766
0.9854
0.997
0.9974
27
0.01
0.0772
0.274
0.6634
0.9412
0.9922
0.9964
0.9966
30
0.01
0.0662
0.2364
0.5982
0.8964
0.9818
0.9932
0.9948
Table 2
1.2
1
0
3
6
9
10
12
15
18
20
21
24
27
30
Relibility
0.8
0.6
0.4
0.2
0
0
1
2
3
4
Number of Rounds
Graph 3
5
6
7
1.001
1
0.999
Relibility
0.998
0.997
0.996
0.995
0.994
0.993
0.992
0
3
6
9
10
12
15
18
20
21
24
Packet Loss Probability
Explanation:
 From this we can see that the results in the range of 0-30%
packets loss show pretty good reliability of the Gossip
protocol.
27
30
6.4 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:
a. Thresholds:
i. Urgent Low = 1
ii. Low = 2
iii. High = 5
iv. Urgent High = 8
b. Number of sending nodes = 1
c. Number of send packets for each sending node = 50
d. Number of nodes = 100
Results:
In the following table we collected the results from the tests with
different packets loss probability.
The first row indicates the loss packet probability while the first
column indicates the number of rounds it took to protocol to
distribute the packets.
0
10
20
30
40
50
60
70
80
90
100
0
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
0.01
1
0.06
0.065
0.0408
0.0476
0.0392
0.0336
0.0346
0.0184
0.0166
0.015
2
0.22
0.1658
0.1062
0.1174
0.0922
0.0618
0.0578
0.026
0.0212
0.016
3
0.53
0.366
0.2186
0.2066
0.1578
0.0924
0.0776
0.0296
0.0226
0.0166
4
0.84
0.6446
0.3722
0.3226
0.2296
0.131
0.0914
0.0316
0.0228
0.0168
5
0.99
0.8674
0.5562
0.4376
0.296
0.1674
0.1048
0.0344
0.023
6
1
0.963
0.7366
0.5418
0.358
0.1958
0.1154
0.036
7
0.986
0.8382
0.6262
0.4078
0.216
0.1232
0.0368
8
0.9914
0.898
0.6868
0.4504
0.2314
0.1314
0.0378
9
0.9918
0.9306
0.7286
0.4856
0.2438
0.1396
0.0386
10
0.992
0.9466
0.7546
0.5146
0.2522
0.148
11
0.9528
0.7726
0.5342
0.259
0.1544
12
0.9554
0.7842
0.548
0.2674
0.1586
13
0.9568
0.7924
0.5572
0.2718
0.1622
14
0.9572
0.7982
0.5658
0.2742
0.1642
15
0.8008
0.573
0.2754
0.1658
16
0.8018
0.5776
0.2764
0.1664
17
0.803
0.5806
0.2776
0.1668
18
0.804
0.5834
0.2786
0.1672
19
0.8044
0.5866
0.2788
0.1674
20
0.8046
0.5886
0.2792
21
0.5914
0.2794
22
0.5936
0.2796
23
0.5958
0.2798
24
0.598
25
0.6002
26
0.602
27
0.6026
28
0.6028
Table 2.
1.2
1
0
10
20
30
40
50
60
70
80
90
100
Relibility
0.8
0.6
0.4
0.2
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Number of Rounds
Graph 3.
Explanation:
Here we can see that reliability is somehow lower comparing to
results we received using previous configuration of thresholds.
And the number of rounds it takes to distribute the packets is
higher. It can be explained due to the fact that in this configuration
each node have less neighbors, thus the tree depth the protocol
builds is bigger, so the distribution time is larger.
Same works for reliability: if each node have less neighbors, the
probability that this node won’t success to promote the information
is higher, thus the overall reliability is lower.
Probability dependence of packets loss
1.2
1
Relibility
0.8
0.6
0.4
0.2
0
0
10
20
30
40
50
60
70
80
Packet Loss Probability
Graph 4.
This graph shows the reliability dependency of packet loss
probability. Here we can see that already from 30% packet loss
probability the reliability is fewer than 80%. These results are
much worse than the original.
90
100
6.5 Network size effect
Test purpose:
To show the affect of number of nodes in the gossip network
on the number of rounds it takes the protocol to distribute the
packet to all the recipients.
Test parameters:
a. Thresholds:
v. Urgent Low = 1
vi. Low = 2
vii. High = 5
viii. Urgent High = 8
b. Number of sending nodes = 1
c. Number of send packets for each sending node = 50
d. Packets loss probability = 30%
30
25
Number of Rounds
20
15
10
5
0
100
150
200
250
Num ber of Nodes
Graph 5.
Explanation:
 Here we can see that the number of rounds it takes the
protocol to distribute the packets depends on number of
nodes.
 Moreover the dependency is logarithmic (depends on the
depth tree that protocol builds.)
300