Starting dtnd and sending a ping

In this tutorial, you'll learn how to configure and start an instance of dtnd, then make it answer a ping.

Configuration

In this section, we'll prepare an appropriate dtn.conf file for our instance of dtnd.

Directories

First, you need to choose a directory that will hold the files dtnd needs. For the purposes of this tutorial, we'll assume your username is fred and that you want dtnd to write into /home/fred/dtn.

Make the /home/fred/dtn directory, then copy the example dtn.conf file from DTN2/daemon/dtn.conf to /home/fred/dtn/dtn.conf. Edit the dtn.conf file. For this tutorial, we'll use the simplest database to configure, BerkeleyDB. Leave the storage set type berkeleydb line alone. In other tutorials, you'll see how to use a SQL database. Set the payloaddir to /home/fred/dtn/bundles and set the dbdir to /home/fred/dtn/db.

The dbdir directory is where persistent objects that DTN2 uses to manage its internal state live. This database will remain fairly small. It needs to be preserved between invocations of the DTN2 daemon, because the data in it lets DTN2 know the status of registrations with clients, and bundles which are in flight in the network. One of the "disruptions" that a DTN is tolerant of is the failure of a node. Using the data in the database, a new DTN2 daemon can carry on the work the previous one was doing. But note that if the contents of the database are lost, it is as if this node never existed, and there will be repercussions in the DTN (like retransmissions of bundles) as a result.

The payload directory is where bundles which are in-flight live. In general, the bundles in this directory are ones which this DTN2 instance has custody of. That means that if they disappear out of this directory, they will be lost forever, since there are no other authoratative copies of the bundle in the network. DTN2 and the DTN protocols are designed to maintain the files in this directory without leaving old ones lying around. If you see an old file there, it's likely due to a bug. Please help us get to the bottom of what's causing it. Unlike packets, which are typically quite small (from 50 to 64,000 bytes), a single bundle can be very large (over 2 gigabytes). On a server dedicated to running DTN2, your payload directory should have access to the largest partition on your server. As an analogy, on a mail server the mail spool is usually on /var, and has access to the majority of the extra disk space on a machine. The same should be true for the payload directory.

Using TCL in the Config File

You don't need to make any changes in the local_eid, but scroll down and take a look at it anyway. In the defualt configuration, it looks like this: route local_eid "dtn://[info hostname].dtn". Note the square brackets. To understand what's happening here, you need to know that this configuration file is not simply a file of settings for dtnd, but an actual TCL script. It is interpreted by the TCL interpreter that is built in to dtnd. In TCL, square brackets mean "interpret this first, and replace the brackets with the result". So before dtnd sees a route local_eid ... command, TCL processes the info hostname command. As you might be able to guess by now, the entire line results in the local_eid being set to a custom string based on your hostname.

This is the only place in this particular configuration file where we will use TCL features like the square brackets. However, you should remember that all the power of TCL is available to you as you write your own configuration files, should you desire it. For an example of this, see the example showing how to rotate logs from within dtnd.

So the local EID is set, but what is it? From the Architecture section, you should recall that nodes in the DTN are identified by EIDs. The local EID is simply the way our DTN node will refer to itself. Without this setting, it would not recognize bundles intended for it, and might just pass them on ad infinitum! People who have configured Internet email systems like Postfix or Sendmail might recognize this setting, as mail routers need to know their own name for the same reason.

And EID is a string that is used throughout the DTN to identify an endpoint. That leaves you considerable latitude on how to set it. We recommend for now that you set it according to the machine name where the DTN node is running, as the example does.

At this time, one dtnd can have only one local EID. This limitation might disappear in future versions if it proves to be a problem.

Interfaces

Take a look at the interface add commands a few lines down. The command interface add tcp0 tcp adds a TCP convergence layer named tcp0 to the server. This means that the daemon will start listening on port 5000 for incoming connections from other servers in the DTN.

Usually DTN nodes that are communicating via TCP listen on port 5000, but that is not an IETF port assignment and nothing about the protocol requires operation on that port. If you have another application on the same server listening on port 5000, you'll need to choose a different port for your dtnd to use.

The interface add command can take convergence layer specific arguments to customize the behavior of the interface. For the purposes of this tutorial, we will be using the defaults. For more information on these arguments see the reference pages on the various convergence layers.

In some security contexts, and with some virtual interface configurations, it is desirable to have dtnd listen only on a certain interface, for instance "listen to internal connections only". You can do this by adding local_addr=desired-ip to the end of the interface add command. The default local_addr is 0.0.0.0, meaning "listen on all interfaces". For this tutorial, we will allow dtnd to listen on all interfaces, so leave the interface add command as it is.

Note that we are adding an interface of type TCP. There are other ways that DTN nodes can communicate, including via UDP, raw ethernet frames, and across a filesystem (where some external activity, like a messenger with a USB keychain drive, is responsible for moving the files). A server that is using multiple convergence layers has other interface add lines in the configuration file.

In fact, below the interface add line for the TCP convergence layer is one for the UDP covergence layer. Because we are setting up a standalone server in this tutorial, neither udp0 nor tcp0 will end up getting used to move bundles at this point.

Links and Routes

Because in this tutorial, we are setting up a standalone dtnd, we will not need any link or route statements. You'll end up with a Disruption Tolerant Network made up of only one daemon. Not much to brag about, but out of simple beginnings come great things!

Initializing the Database

Before dtnd can use the database to keep track of runtime state, it needs to initialize it. This is a simple matter of starting the daemon once with the --init-db argument. You'll also want to give it the location of the configuration file, so that dtnd can find the correct database directory. Put that together and you have:

$ daemon/dtnd.conf -c /home/fred/dtn/dtn.conf --init-db 
[1108493233.189564 /dtnd info] Bundle Daemon Initializing...
[1108493233.209564 /dtnd info] random seed is 209564
[1108493233.224564 /dtnd info] parsing configuration file /home/fred/dtn/dtn.conf ...
[1108493233.231564 /dtnd info] dtnd parsing configuration...
[1108493233.234564 /interface info] adding interface tcp host://0.0.0.0:5000/
[1108493233.276564 /dtnd info] dtnd configuration parsing complete
[1108493233.609564 /storage/berkeleydb info] database file '/home/fred/dtn/db/DTN.db' validated
[1108493233.615564 /storage/berkeleydb info] initializing globals database table ...
[1108493233.662564 /storage/berkeleydb info] initializing bundles database table ...
[1108493233.733564 /storage/berkeleydb info] initializing registration database table...
[1108493233.948564 /storage/berkeleydb info] closing database file...
[1108493234.037564 /dtnd info] database initialization complete.

Running the Daemon

For now, you start dtnd from the commandline, like any other Unix command. By default, the TCL interpreter takes input from standard in, so you will need to leave it running in the foreground. While you are learning the ins and outs of dtnd, it is best to run it this way, so that you can interact with it. Use the -c argument to tell it where to find the configuration file. For information on other arguments you can give dtnd, see the dtnd man page.

Once you start dtnd with a command like DTN2/daemon/dtnd -c /home/fred/dtn/dtn.conf, it will put out some messages, then give you the dtn% prompt. This means the server is up and running, awaiting commands from you. Things you type at the prompt are interpreted by the same TCL interpreter that just parsed the configuration file. In a way, you can consider the configuration file a list of commands that will be issued for you each time you start the server.

Here's an example of starting up the server:

[1108500270.498718 /dtnd info] Bundle Daemon Initializing...
[1108500270.498718 /dtnd info] random seed is 498718
[1108500270.546718 /dtnd info] parsing configuration file /home/fred/dtn/dtn.conf...
[1108500270.553718 /dtnd info] dtnd parsing configuration...
[1108500270.557718 /interface info] adding interface tcp host://0.0.0.0:5000/
[1108500270.577718 /dtnd info] dtnd configuration parsing complete
[1108500270.985718 /storage/berkeleydb info] database file '/home/fred/dtn/db/DTN.db' validated
[1108500271.136718 /tcl info] can't load tclreadline: can't find package tclreadline
[1108500271.142718 /tcl info] fall back to simple command loop

Note that this installation of TCL is missing the optional tclreadline package. As a result we get a warning from dtnd at startup, but it will still work correctly. The user interface is just slightly more difficult to use because you cannot go back through your command history and edit previous commands.

Use the online help system to learn what you can do from here. Type help. For help on a specific command, type help command. For now, though, you don't need to use any commands. Just let dtnd run in its own window. When we start talking to dtnd with an application you'll see log messages in the window where dtnd is running.

Pinging the daemon

A Disruption Tolerant Network is made up of a number of servers whose job is to move bundles through the system. But where do the bundles come from? They come from applications. In the future, you can expect to see applications to move scientific data, web pages, e-mail, and other data that needs to traverse a network region prone to disruption. For now though, the best way to see your new DTN (consisting of just your one server) operate is to send a ping bundle into to it, and see what comes back out!

To ping your server, run the dtnping command. It lives in the DTN2/apps/dtnping directory. You'll need to give it one argument, which is the EID address of the endpoint that you want to ping. Since there is only one server in your DTN, the choice should be simple. You need to use the local EID that you set in the configuration file. If you'd like to check what dtnd thinks it's local EID name is, use the registration list command in the window where dtnd is running. The first registration is always the server registering it's own EID with itself, so that it can handle administrative bundles, like the ping bundle we are about to send.

Alternatively, dtnping contains a convenience shortcut whereby the string 'localhost' is interpreted as the local EID of the daemon.

Here's an example of how to ping a server who's local EID is dtn://dtn-a.dtn:

$ ./dtnping localhost
source_eid [dtn://dtn-a.dtn/ping.2384]
replyto_eid [dtn://dtn-a.dtn/ping.2384]
dtn_register succeeded, regid 0x11
checking for bundles already queued...
PING [dtn://dtn-a.dtn/]...
68 bytes from [dtn://dtn-a.dtn]: time=161.00 ms
68 bytes from [dtn://dtn-a.dtn]: time=228.00 ms
Ctrl-C

What next?

You've set up a standalone dtnd and pinged it. From here, you can explore two directions. In the DTN2 applications tutorial, you can learn how to use the other applications that come with DTN2 to interact with your new little DTN. In the building a bigger DTN tutorial, you can see how to use links to make several nodes work together as part of a bigger DTN.