aDTN is the first implementation of Active-DTN. It is implemented and maintained by our research group SeNDA taking the BP Application Server as reference. It comes with two libs for C and Java developers to build DTN applications with specific routing requirements.
The code and installation instructions are available at the project repository.
The main component of aDTN is the Bundle Agent that has a modular structure, see Figure bellow.
Bundles arrive at the Bundle Agent through the Receiver that is a module listening for bundles either coming from the network or from applications running on the platform. The Receiver checks bundle destination in order to delegate bundles whenever is possible. Otherwise, the bundle is enqueued. To keep the bundle agent delay and disruption tolerant, the communication between platform applications and the Bundle Agent’s Receiver is asynchronous. See Algorithm 1 for a detailed description of bundle reception supporting several destination.
The module in charge of forwarding bundles is the Processor. This module dequeues bundles in order to execute a routing algorithm for them. Depending on the output of the execution, the bundle is forwarded or enqueued again. See Algorithm 2 for more details.
The routing algorithm to execute for a given bundle is the one included in it. Therefore, when available, the software code of the bundle’s MMEB for routing must be used. Nevertheless, when this extension is not present or there is no software code in it that is compatible with the platform, then a default routing algorithm must be executed. For security reasons, the execution of software codes provided by the bundles must be supervised. For instance, access to system functionality must be denied by default. Only access to particular structures like the RIT is available. Moreover, the execution time is limited. When the execution time limit is reached, the execution must be cancelled and a default software codes must be executed instead. Similarly, a default software code must be executed whenever the bundle’s software code execution fails.
The module in charge of the software code execution is denoted by the Executor. It is aware of the formats that are supported by the platform, it supervises the software code execution and knows what are the default software codes to use in case they fail. The Executor is available for running any type of algorithms, not only routing algorithms. In fact, it runs lifetime and priority algorithms too and can be extended to run algorithms from other MMEB code types. Current aDTN implementation supports ISOC99-compliant code only. TinyCC  is used to compile the C software code because it can quickly compile to native x86, x86-64 and ARM code in devices with slow processors and few disk space. Support to other software code language formats can be provided by extending the Executor. See Algorithm 3 to see how the Executor works for a given code type.
aDTN platform nodes advertise their presence sending simple beacon messages. A node is considered a neighbour if a beacon message has recently been received from it. Beacon messages contain the node end-point identification. In addition, they can include also a small amount of announceable information from the RIT. Notice that by this way routing information can be spread over the Active-DTN network. The Information Exchange module is in charge of periodically sending beacon messages and keeping neighbour information up to date. To that end, this module makes use of a RIT Manager internal service that provides announceable information. An example of content access restriction in the RIT is the writing access to the neighbour list that must be only possible from the Information Exchange module.
aDTN has been code in C and provides a communication library for applications to interact with the platform. As in TCP/IP, an aDTN socket is provided that needs to be bound before being used. Lines bellow we provides a library usage example for sending bundles with MMEB extensions. In this example, a bundle is sent with a trivial message as payload and a routing software code as MMEB extension.
In order to document dependencies and facilitate the implementation of routing algorithms, a template code is provided so that the before mentioned routing code can be implemented as follows. Notice that this routing algorithm corresponds to Algorithm 4 included in the Active-DTN page of this site.