Transcript Network Load Generator

Gossip protocol
Michael Gustus
Dmitriy Mosheyev
Supervisor : Roie Melamed
Introduction
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 .
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.
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.
Project Definition
Goal

The goal of this project is to
implement the Gossip protocol in the
GloMoSim network simulator.
Gossip Structure

Araneola dynamically constructs an
overlay network, and spreads information
by gossiping over this overlay.
Network
Gossip Structure
Neighbors: The immediate
neighbors of the peer (the
peer it is connected to).
Network
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).
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:
1. avoid graph partition.
2. calculate the number of
disjoint paths between
any two peers.
Network
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.
Network
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
Join?
OK
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
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.
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).
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
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
GloMoSim simulator
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.
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:
Protocols
Layers
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
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 discreteevent 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.
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)
Project Structure
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.
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.
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.
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.
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;
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.
User Guide
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
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.
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.
Installing Glomosim

Uncompress the Glomosim library.

Change the directory to main.

make (or “makent” on NT), to build
Glomosim.
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.
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”
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.
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
Results
Protocol performance with
packet loss
Test purpose:

•
To show the loss packet probability affect on reliability
of the protocol.
Test parameters:

•
Thresholds:




•
•
•
Urgent
Urgent
High =
Urgent
Low = 1
Low = 4
10
High = 15
Number of sending nodes = 1
Number of sent packets for each sending node = 50
Number of nodes = 100
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:
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
0
0.01
0.07
0.38
0.89
1
10
0.01
0.0916
0.4096
0.8968
0.9998
1
20
0.01
0.0634
0.281
0.72
0.9734
0.9988
0.9994
30
0.01
0.0662
0.2364
0.5982
0.8964
0.9818
0.9932
0.9948
40
0.01
0.0512
0.1518
0.3708
0.6526
0.8494
0.9308
0.9536
0.9584
0.9592
0.9594
50
0.01
0.051
0.1312
0.2892
0.5
0.6988
0.8308
0.8956
0.9238
0.9324
0.9348
0.9356
0.9364
60
0.01
0.0298
0.0668
0.1234
0.2002
0.2934
0.3912
0.4762
0.548
0.605
0.6462
0.6726
0.6898
0.6984
0.7048
0.7082
0.7094
0.7102
0.711
0.7116
0.712
0.7122
0.7124
70
0.01
0.0302
0.0564
0.089
0.1234
0.1642
0.2014
0.2348
0.265
0.2872
0.3046
0.3206
0.331
0.3368
0.3402
0.3434
0.3462
0.3482
0.3496
0.3502
0.3504
0.3506
0.3508
80
0.01
0.0212
0.0348
0.0448
0.0532
0.0594
0.0644
0.0682
0.0716
0.0738
0.0744
90
95
0.01
0.01
0.0198 0.0122
0.0254 0.013
0.0274 0.0132
0.0282
0.029
100
0.01
• In the following table we collected the results from the tests with
different packets loss probability.
Protocol performance with
packet loss
1.2
0
1
10
20
Relibility
0.8
30
40
50
0.6
60
70
0.4
80
90
95
0.2
100
0
0
1
2
3
4
5
6
7
8
9
10
11 12
13
Number of Rounds
14 15
16
17 18
19
20 21
22
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.
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
100
Packet Loss Probability
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%).
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
Urgent
High =
Urgent
Low = 1
Low = 4
10
High = 15
Number of sending nodes = 1
Number of sent packets for each sending node = 50
Number of nodes = 100
Protocol performance with
packet loss
0
1
2
3
4
5
6
7

0
0.01
0.07
0.38
0.89
1
Results:
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
• In the following table we collected the results from the tests with
different packets loss probability.
30
0.01
0.0662
0.2364
0.5982
0.8964
0.9818
0.9932
0.9948
Protocol performance with
packet loss
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
5
6
7
Protocol performance with
packet loss
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
27
30
Packet Loss Probability
 The results in the range of 0-30% packets loss show pretty
good reliability of the Gossip protocol.
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
Urgent
High =
Urgent
Low = 1
Low = 2
5
High = 8
• Number of sending nodes = 1
• Number of sent packets for each sending node = 50
• Number of nodes = 100
Thresholds effect
In the following table we collected the results from the tests with
different packets loss probability.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
0
0.01
0.06
0.22
0.53
0.84
0.99
1
10
0.01
0.065
0.1658
0.366
0.6446
0.8674
0.963
0.986
0.9914
0.9918
0.992
20
0.01
0.0408
0.1062
0.2186
0.3722
0.5562
0.7366
0.8382
0.898
0.9306
0.9466
0.9528
0.9554
0.9568
0.9572
30
0.01
0.0476
0.1174
0.2066
0.3226
0.4376
0.5418
0.6262
0.6868
0.7286
0.7546
0.7726
0.7842
0.7924
0.7982
0.8008
0.8018
0.803
0.804
0.8044
0.8046
40
0.01
0.0392
0.0922
0.1578
0.2296
0.296
0.358
0.4078
0.4504
0.4856
0.5146
0.5342
0.548
0.5572
0.5658
0.573
0.5776
0.5806
0.5834
0.5866
0.5886
0.5914
0.5936
0.5958
0.598
0.6002
0.602
0.6026
0.6028
50
0.01
0.0336
0.0618
0.0924
0.131
0.1674
0.1958
0.216
0.2314
0.2438
0.2522
0.259
0.2674
0.2718
0.2742
0.2754
0.2764
0.2776
0.2786
0.2788
0.2792
0.2794
0.2796
0.2798
60
0.01
0.0346
0.0578
0.0776
0.0914
0.1048
0.1154
0.1232
0.1314
0.1396
0.148
0.1544
0.1586
0.1622
0.1642
0.1658
0.1664
0.1668
0.1672
0.1674
70
0.01
0.0184
0.026
0.0296
0.0316
0.0344
0.036
0.0368
0.0378
0.0386
80
0.01
0.0166
0.0212
0.0226
0.0228
0.023
90
0.01
0.015
0.016
0.0166
0.0168
100
0.01
Thresholds effect
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
Number of Rounds
14
15
16
17
18
19
20
21
22
Thresholds effect
Explanation:


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.
Thresholds effect
1.2
1
Relibility
0.8
0.6
0.4
0.2
0
0
10
20
30
40
50
60
70
80
90
100
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.
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:
• Thresholds:




Urgent
Urgent
High =
Urgent
Low = 1
Low = 2
5
High = 8
• Number of sending nodes = 1
• Number of sent packets for each sending node = 50
• Packets loss probability = 30%
Network size effect
30
25
Number of Rounds
20
15
10
5
0
100
150
200
250
300
Num ber of Nodes
• 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.)