Documentation

API

Clients

Lower level API specification is written according to OpenAPI 3.0. The API description file can be found in file RMBTControlServer/openapi.yaml. For ease of reading, consider generating interactive HTML out of the file. For example, you can use web app Swagger Editor.

Higher level documentation describing how everything interacts can be found here..

Server

The control server uses OpenAPI specification for code generation. More specifically, models for parsing JSON using GSON are generated. These models are not supposed to be touched directly. Changes won't be persistent. To make any changes to them, change the underlying OpenAPI spec file. To run the code generator manually, call gradle generateSwaggerCode.

Relevant links

• project of Austrian RTR - NetMetr is based on their code - rtr-nettest/open-rmbt
  • their speed test server (our version resides in this repository) - rtr-nettest/rmbt-server
  • documentation for speed test protocol
• rmbt-client used on Turris routers
  • This tool can communicate with speed server, but it can't talk with control server to establish the test parameters.
• turris-netmetr-client wrapper for rmbt-client written in Python managing communication with control server
• websocket client used in netmetr.cz website

Build and run

Dev

To build everything for development environment, you can use build_servers.sh script in the root of the repository. Results of this compilation can then be used to build Docker containers.

To manage Docker containers docker-compose is used. To run all the servers in a clean repository, run this:

bash build_servers.sh
docker-compose build
docker-compose up

Containers require DNS records for control.netmetr, speed.netmetr and qos.netmetr. Those can be automatically created and managed by running dns-proxy-server.

More detailed description of the containers is in file docker/README.md.

Production

Production environment consists of 3 different servers. Control server, QoS test server and speed test server. Control server is where everything starts and ends. It hosts 3 Java applications, the most important one controlling and managing everything else. It points the clients to the other servers, gives them permission to perform tests and in the end, it collects all results.

Here is how each of the servers look like:

• control server
• QoS server
• speed server

WARNING: Because code is in no way dependent on this documentation, it's quite likely that the documentation is outdated. Make sure to check time of last edit and compare these notes with Dockerfiles of development setup. They are more likely up to date.