DTN2 Documentation
Introduction
The goal of this implementation is to clearly represent the components of the DTN architecture, while also providing a robust and flexible software framework for experimentation, extension, and real-world deployment.
The code is extensively instrumented with logging both for debugging and operational purposes.
DTN2 is specifically a reference implementation. Little attempt has been made to enhance performance at the cost of clarity, generality and robustness. This is entirely deliberate, although there are areas where a little bit of performance optimisation would help. There has also been an accretion of functionality over the years, some of which may be redundant by now!
Implementation
The core implementation is written in C++ using a framework called Oasys that is designed to provide a uniform interface to the DTN2 code hiding operating system and other support package quirks. Some of the implementation of the functionality supplied by Oasys is complex to understand because of its attempts to hide system specific details.
The Bundle Protocol Agent and all its support code is implemented as a user space daemon caled dtnd. The daemon has a configuration and control interface which can be run remotely over a TCP connection when the daemon is running 'daemonized' (i.e., without a control terminal).
DTN applications interface to dtnd through the application API, which is a simple Sun RPC mechanism. In addition to the basic C language binding for the API, there are also Perl, Python and TCL bindings
Capabilities
As of the beginning of 2012, this implementation has a fairly comprehensive set of DTN functionality, including the application api, support for custody, initial support for some of the DTN Security protocol, return receipts, a number of convergence layers including TCP, Bluetooth and LTP (Licklider Transport Protocol) and an extensive collection of routing protocols, including
- Static routing,
- Flood or epidemic routing,
- PRoPHET routing,
- DTLSR, and
- TCS (Tetherless Computing Architecture) routing
DTN2 uses persistent storage to maintain state when the daemon is stopped so that bundles and other information can be reloaded on restart. Various storage mechanisms can be configured, including
- File system only
- Berkeley DB - basic (key, value) pair mechanism
- In memory (fast but not really persistent!)
- ODBC interface for SQL databases supporting
- SQLite version 3
- MySQL version 5.x
It also includes some example applications - including ping and dtncp/dtncpd, a file transfer dtn client and server.
For the more adventurous, there is an interface to the main event loop in DTN2 that allows various external components to be run in separate processes communication with the main dtnd process using an XML based protocol. There is scope for both external convergence layers and external routing components.
External router components have been implemented by the RAPID and HBSD projects:
Information about DTN2
Dtn2Compilation - out of date
Dtn2KnownBugs - well out of date