IBRDTN is an opportunistic networking middleware system that implements the Bundle protocol, as defined in RFC 5050.
LEPTON can emulate IBRDTN nodes, allowing such nodes to run concurrently on a single host platform (or on a cluster of hosts), while simulating the mobility of these nodes, and while conducting communications between them according to their respective positions in the simulation area.
Besides LEPTON you need to install IBRDTN on your host platform, as well as a specific adapter. This adapter will allow LEPTON to control IBRDTN nodes, and to process traffic received from these nodes.
In the following we assume you have already installed LEPTON on your system, but IBRDTN and its adapter are still missing.
Note: the official version of IBRDTN (available on GitHub) is not directly compatible with LEPTON. Therefore you need to install a sligthly modified version of IBRDTN on your system.
Download the archive that contains this modified version of IBRDTN, as well as the adapter archive that will allow LEPTON to control IBRDTN nodes:
wget http://casa-irisa.univ-ubs.fr/download/ibrdtn-for-lepton.zip
wget http://casa-irisa.univ-ubs.fr/download/ibrdtn-adapter.zip
Unzip both archives:
unzip ibrdtn-for-lepton.zip
unzip ibrdtn-adapter.zip
In order to build IBRDTN on a Linux plaform, you may have to install several packages first:
sudo apt-get install build-essential libssl-dev libz-dev libsqlite3-dev \
libcurl4-gnutls-dev libdaemon-dev automake autoconf pkg-config libtool libcppunit-dev \
libnl-3-dev libnl-cli-3-dev libnl-genl-3-dev libnl-nf-3-dev libnl-route-3-dev libarchive-dev
Once your Linux platform is ready, you can start building IBRDTN (this may take a while!):
pushd ibrdtn-for-lepton/ibrdtn
./autogen.sh
Note: while running autogen.sh the script may complain that the folder is not a git repository. Don't worry about that and continue with the following commands:
./configure --prefix=$(realpath $(pwd)/../target)
make
make install
popd
Set environment variables so they point to the folders you've just created:
cat << EOF >> ~/.$(basename $SHELL)rc
#
# IBRDTN environment variables
export IBRDTN_HOME="${PWD}/ibrdtn-for-lepton/target"
export IBRDTN_ADAPTER_HOME="${PWD}/ibrdtn-adapter"
export PATH="\${PATH}:\${IBRDTN_HOME}/bin:\${IBRDTN_HOME}/sbin"
export LD_LIBRARY_PATH="\${LD_LIBRARY_PATH}:\${IBRDTN_HOME}/lib"
#
EOF
source ~/.$(basename $SHELL)rc
LEPTON supports several modes of operation. In the following we assume LEPTON and several IBRDTN nodes must run concurrently on the same host. Another option would be to distribute the IBRDTN nodes on a cluster of workstations.
When starting LEPTON a reference to IBRDTN's adapter must be provided,
so LEPTON knows how to process the traffic it will receive from IBRDTN
nodes. This is obtained by defining argument oppnet_adapter when
starting LEPTON:
lepton.sh start oppnet_adapter=${IBRDTN_ADAPTER_HOME}/bin/adapter.sh
In this example, LEPTON is started with its default configuration,
except that argument oppnet_adapter indicates where to find the adapter
required for interacting with IBRDTN nodes.
Using LEPTON's default configuration means that a number of nodes are created automatically when LEPTON starts. After running the command above you should thus see a number of nodes moving in the display window.
So what's the difference between starting LEPTON with or without
argument oppnet_adapter? The difference is that when
oppnet_adapter is used, the nodes you see on the display screen are
not just blips moving around. For each node you observe on the display
screen there is an instance of IBRDTN (we'll call it an "IBRDTN node")
running in the background on your system.
At any time you can use the following command to check whether LEPTON is running or not, and how many IBRDTN nodes are running as well:
lepton.sh status
If you're really curious you can also use the following command to verify that many instances of IBRDTN are indeed running in the background on your system:
ps ux | grep dtnd | grep -v grep
Now what are these IBRDTN nodes doing? Well, they are trying to discover one another using the IPND (IP Neighbor Discovery) protocol. But they are doing so via a software hub that is part of LEPTON, so LEPTON actually orchestrates communications between all these nodes. You can observe the activity of LEPTON's hub by scanning its log file:
tail -f /dev/shm/${USER}/lepton/lepton.out
(Use Ctrl-C to terminate)
You should see that there is a lot of traffic passing through LEPTON's hub, which means that IBRDTN nodes are indeed exchanging messages (actually IPND beacons) whenever LEPTON estimates that they are close enough to do so.
When the node start exchanging data rather than just beacons (see below), there will be even more traffic passing through the hub.
IBRDTN_Adapter comes with a bash script ibrdtn.sh that makes it easy
to control an IBRDTN node at runtime. This script, which simply calls
IBRDTN commands (dtnsend, dtnrecv, etc.), is meant to control a
single instance of IBRDTN.
Since many IBRDTN nodes can run concurrently on the same host when
running with LEPTON, the script lepton.sh makes it possible to
control each node individually, using the same set of commands as that
offered by ibrdtn.sh:
lepton.sh exec [node_id] start
| stop
| status
| send <dest> <fname>
| recv
Note that when calling lepton.sh with option exec the second
argument must always be node_id, so LEPTON knows which IBRDTN node
the command must be addressed to.
Options start and stop allow you to create and terminate IBRDTN
nodes manually. This is not required with LEPTON's default
configuration, since in that case several nodes are created
automatically when LEPTON is started.
Now let us assume you would like node N00 to send a small file to node N12:
echo "This is my file" > /tmp/file
lepton.sh exec N00 send N12 /tmp/file
Basically, the second command above is equivalent to calling command
dtnsend on node N00, asking this node to send a bundle containing
file /tmp/file to node N12.
If you wish node N12 to be able to receive that bundle (and display
its content on the screen):
lepton.sh exec N12 recv
This is equivalent to calling command dtnrecv on node N12.
By default the nodes created with IBRDTN_Adapter use IBRTDN's epidemic
routing module, so all nodes participate in the dissemination of
bundles. Thus it shouldn't take too long for N12 to receive the file
sent by N00.
You may have observed that the vertices that appear between nodes change color every now and then. A blue vertex between two nodes means that LEPTON considers that these nodes are "in radio range", that is, close enough to communicate. This does not mean that they are actually communicating, though: they are just close enough to do so. A vertex turns red when a connection is actually established between both nodes, which means that they have discovered one another, and have reacted accordingly.
With the default configuration defined by IBRDTN_Adapter, the IBRDTN nodes use UDP transmissions for neighbor discovery, and a TCP session is established between two neighbor nodes whenever they have bundles to exchange. This TCP session is maintained as long as possible, that is until the link between the nodes is disrupted because they are not in transmission range anymore.
When running with LEPTON, all IBRDTN nodes redirect their traffic to the hub, which serves as some kind of a proxy. A red vertex between two IBRDTN nodes on the screen therefore means that these nodes are connected by TCP... but through the hub.
lepton.sh stop
This command stops LEPTON, but also all the IBRDTN nodes that may be running as well.