This project is part of the Broadcast Group Project which includes the following subprojects:
- Broker Implementation: Extension of moquette that supports broadcast groups
- Broadcast Group Simulation: A simulation of the broadcast group formation process
Today, communication between IoT devices heavily relies on fog-based publish/subscribe (pub/sub) systems. Communicating via the cloud, however, results in a latency that is too high for many IoT applications. This project is about a fog-based pub/sub system that integrates edge resources to improve communication latency between end devices in proximity. To this end, geo-distributed broker instances organize themselves in dynamically sized broadcast groups that are connected via a scale-able fog broker.
If you use this software in a publication, please cite it as:
Jonathan Hasenburg, Florian Stanek, Florian Tschorsch, David Bermbach. Managing Latency and Excess Data Dissemination in Fog-Based Publish/Subscribe Systems. In: Proceedings of the Second IEEE International Conference on Fog Computing 2020 (ICFC 2020). IEEE 2020.
@inproceedings{paper_hasenburg_broadcast_groups,
title = {Managing Latency and Excess Data Dissemination in Fog-Based Publish/Subscribe Systems},
booktitle = {Proceedings of the Second {IEEE} {International} {Conference} on {Fog} {Computing} (ICFC 2020)},
author = {Hasenburg, Jonathan and Stanek, Florian and Tschorsch, Florian and Bermbach, David},
year = {2020},
publisher = {IEEE}
}
A full list of our publications and prototypes is available on our group website.
Experiments related to the publication are based on commit. The jar was started with java -jar -Xmx16G BroadcastGroupSimulation.jar -i worldcities.csv -l 10,20,30,40,50,60,70,80,90,100,150,200,250,300,350,400 -p sim -a 1200,2400,3600,4800,6000,7200,8400,9600,10800,12000.
This repository contains code for the simulation of the broadcast group formation process. The goal of this simulation is to better understand how the latency threshold affects the number of broadcast groups, as well as involved overheads.
Required input:
- Broker names, locations, and lcms (leadership capability measures)
- fixed, global latency threshold
- an educated guess for latency per km (see data package section below)
Calculated output:
- a valid set of broadcast groups
The output is written to the simulation-result directory. The visualization directory contains various iPython notebooks that can be used to visualize the simulation results.
Run the main method in the Main.kt (code directory) file to start the simulation with randomly generated input values.
As an alternative, you might also build a jar with maven package and run it without supplying any parameters (jar will be stored in the out directory).
If you want to see more details of the simulation process, update the log level in the log4j2.xml file.
If the simulation stops during "Broker Initialization", give java more memory, e.g., with -Xmx16G.
To use pre-defined data as input, supply required information as program data arguments, e.g.: -p sim -i worldcities.csv -l 10,20 -a 1200,2400.
Input data is expected to be in the same format as the worldcities dataset of simplemaps.
You may also start the jar with the -h option to learn more about available program arguments.
A single simulation comprises multiple ticks. During a "tick", every individual broker sequentially executes 7 tasks. Before the next task is started, every broker waits until all other brokers have finished the current task, and the next tick is only started when all brokers finished the tasks of the current tick.
The tasks are as follows; more information on individual tasks can be found by inspecting the respective functions in BrokerKt:
- Prepare for next tick
- Broadcast group leaders send merge requests to other leaders
- Leaders process received merge requests and negotiate who becomes the leader of the new broadcast group
- Sending leaders are notified about final negotiating result (who joins whom)
- Leaders that join another broadcast group notify their members
- Brokers that have to join another broadcast group prepare
- Brokers that have to join another broadcast group notify their new leader
The simulation process ends, once the following two conditions are true:
- all members have a latency to their leader that is below the defined latency threshold
- all leaders have a latency to all other leaders that is above the defined latency threshold
The data package contains code to calculate an appropriate ms/km value for the simulation based on iPlane measurements.
To calculate a latency per km value based on the iPlane data, run the main methods of the included files in the following order:
- IPlaneLoader.kt
- IPlaneIpToLocation.kt (requires a secret from ipinfo.io)
- IPlaneLocationEnricher.kt
You may also customize the calculation by updating the conf objects in each file's main method.
Find below helpful commands to run the simulation on AWS (expects to be executed in a fish shell).
- Build Jar with
mvn package - Set var with
set URL xxxxx - Copy to AWS
scp -i "sim.pem" out/BroadcastGroupSimulation.jar ec2-user@$URL:/home/ec2-user/
scp -i "sim.pem" data/simulation_input/worldcities.csv ec2-user@$URL:/home/ec2-user/- Run
sudo yum install java-11-amazon-corretto
screen -S experiment
java -jar -Xmx16G BroadcastGroupSimulation.jar -i worldcities.csv -l 10,20,30,40,50,60,70,80,90,100,150,200,250,300,350,400 -p sim -a 1200,2400,3600,4800,6000,7200,8400,9600,10800,12000- Collect results
scp -i "sim.pem" -r ec2-user@$URL:/home/ec2-user/simulation-result/ .
scp -i "sim.pem" -r ec2-user@$URL:/home/ec2-user/logfile.log/ simulation-result/sim-logfile.log