DST-shadow
Go to file
ufarooqstatus 5370859a5a updated Readme 2024-03-11 14:08:55 +05:00
nimbledeps Add shadow node 2023-09-01 10:12:05 +02:00
shadow More realistic network model. We have peers with variable bandwidth/latencies and packet loss ratio 2024-03-11 13:54:18 +05:00
tools Add shadow node 2023-09-01 10:12:05 +02:00
.gitignore Add shadow node 2023-09-01 10:12:05 +02:00
LICENSE Initial commit 2023-08-10 11:42:46 +02:00
README.md updated Readme 2024-03-11 14:08:55 +05:00
test_node.nimble Add shadow node 2023-09-01 10:12:05 +02:00

README.md

dst-gossipsub-test-node

  • DST gossipsub test node
  • incl shadow simulation setup
  • incl awk scripts for detailed analysis

Three simulation cases are supportes

Scenario1 - Basic Simulation Scenario

Shadow example

nimble install -dy
cd shadow
# the default shadow.yml will start 5k nodes, you might want to change that by removing
# lines and setting PEERS to the number of instances
./run.sh
# the output is a "latencies" file, or you can find each host output in the
# data.shadow folder

# you can use the plotter tool to extract useful metrics & generate a graph
cd ../tools
nim -d:release c plotter
./plotter ../shadow/latencies "Clever graph name"
# will output averages, and generate a "test.svg" graph

The dependencies will be installed in the nimbledeps folder, which enables easy tweaking

Scenario2 - (P2P-Research Branch) -

Homogeneous nodes/links (100 Mbps bandwidth and 100ms latency) supports variable network/message size, variable number of publishers and message fragments automatically updates shadow.yaml file to accomodate different network sizes awk scripts for detailed analysis

cd shadow
#the run.sh script is automated to meet different experiment needs, use ./run.sh <num_runs num_peers msg_size num_fragments>
#The below example runs the simulation twice for a 1000 node network. each publisher publishes a 15000 bytes messages, and every message is partitioned into 4 fragments. Total 10 publishers use  

./run.sh 2 1000 15000 4 10
# The number of nodes is maintained in the shadow.yaml file, and automatically updated by run.sh.
# The output files latencies(x), stats(x) and shadowlog(x) carries the outputs for each simulation run.
# The summary_dontwant.awk, summary_latency.awk, summary_latency_large.awk, and summary_shadowlog.awk parse the output files.
# The run.sh script automatically calls these files to display the output
# a temperary data.shadow folder is created for each simulation and removed by the run.sh after the simulation is over

Scenario3 - (Realistic-Scenarios Branch) -

Heterogeneous nodes/links (bandwidth/latency/packet_loss_ratio controllable through run.sh) run.sh uses topogen.py to create a realistic gml file to emulate a real-world network scenario supports variable network/message size, variable number of publishers and message fragments automatically generates network_topology.gml and shadow.yaml files to accomodate different network sizes awk scripts called from run.sh for detailed analysis

cd shadow
#The following sample command runs simulation 1 time, for a 1000 node network. Each published message size
#is 15KB (no-fragmentation), peer bandwidth varies between 50-130 Mbps, Latency between 60-160ms, and
#bandwidth,latency is roughly distributed in five different groups. 

./run.sh 1 1000 15000 1 10 50 130 60 160 5 0.0
# The number of nodes is maintained in the shadow.yaml file, and automatically generated by run.sh.
# The output files latencies(x), stats(x) and shadowlog(x) carries the outputs for each simulation run.
# The summary_dontwant.awk, summary_latency.awk, summary_latency_large.awk, and summary_shadowlog.awk parse the output files.
# The run.sh script automatically calls these files to display the output
# a temperary data.shadow folder is created for each simulation and removed by the run.sh after the simulation is over