Add New Page: You are not allowed to add pages Select section/namespace. New page title.

Commotion Architecture


Commotion is a software toolkit with many different components. This page provides a technical overview of those components, both those already implemented and those that are merely planned.


Status: released but not feature-complete

Libcommotion is the underlying system library that provides a small, high-performance set of reusable components that are used to build other parts of Commotion, most notably commotiond. Libcommotion is written in C, and presents a clean core API in C (potentially with bindings from other languages) for including it in other projects.


Status: released but not feature-complete

Commotiond is the core system executable for Commotion. Commotiond is a cross-platform C daemon which configures all Commotion nodes and presents all runtime Commotion APIs. Commotiond has compile-time loadable OS driver abstraction layers for facilitating its use across different operating systems, and is capable of loading 'subsystems' as either modular plugins or as separate daemons, all of which communicate via a built-in IPC message bus that also serves as a network messaging abstraction.



Status: released but not feature-complete

The addressing subsystem facilitates configuration of network addresses for the nodes in the Commotion network. This can encompass, based on configuration, anything from a preconfigured static address to auto-selection of a random address from a configured subnet to configuration protocols like DHCP and AHCP. Both IPv4 and IPv6 are supported.


Status: planned

This subsystem deals with the Commotion network's distributed nameservice. Planned support is for two namespaces; one allows for any node to assert ownership over a name, and the other is an authoritative namespace controlled by a quorum of network administrators.


Status: planned

Being able to have a relatively synchronized idea of time within a distributed system is important for a number of reasons, including the prevention of replay attacks. This service will provide an implementation of 'mesh time,' which may or may not have an option for synchronizing with NTP when internet access is available.


Status: planned

The authentication subsystem will implement a distributed RADIUS server for fast hand-off and authentication for clients of different nodes.


Status: released but not feature-complete

The routing subsystem uses loadable plugins to support different routing backends. Those backends may be supported directly in the plugin, or may be separate daemons that are configured and managed by commotiond. Currently only OLSRd is supported, and then only on OpenWRT through separate automation scripts.


Status: released but not feature-complete

The crypto subsystem has backends for key distribution and discovery, as well as the establishment of end-to-end encrypted communication channels between different nodes. Currently that backend is Serval, which establishes an encrypted overlay mesh using a custom network protocol called Mesh Datagram Protocol (MDP).


Status: released but not feature-complete

The services subsystem provides a directory of servers and web applications that are connected to the Commotion network. This subsystem is implemented as a separate standalone daemon called the Commotion Service Manager (CSM), which validates and stores the directory announcements coming from nodes within the network.

Client Software

If commotiond is the backend, then commotion-client, commotion-android, and the web-based GUI interface on the router firmware is the frontend. These interfaces are currently either in progress or have their own backends, but eventually they will all be built on top of comotiond's client API. This has the advantage of decreasing code duplication and increasing consistency across all the supported platforms, as well as providing a standardized way for developers to create 3rd-party applications or frontends.

Architecture Documentation