GLGuillaume LemonnierSoftware engineering
Accueil/Projets/Mission control

02 · Serveur concurrent

Mission Control Protocol Server

Un serveur de commande/contrôle Linux en C++20 : clients TCP concurrents, séquence de connexion et d’authentification, machine d’état mission, télémétrie périodique et supervision HTTP.

C++20TCPstd::jthreadRAIIHTTP/JSONCTest
Voir le code source →
MCPS/1.0 / CONTROL SESSION
> CONNECT GROUND-01
< 200 CONNECTED
> AUTH mission-secret
< 200 AUTHENTICATED
> SET_MODE ACTIVE
< 200 MODE ACTIVE
> START_STREAM
! TELEMETRY mode=ACTIVE uptime=42s

Le problème

Servir plusieurs opérateurs sans mélanger leur session

Chaque client possède son propre état de connexion, d’authentification et de streaming, tandis que le mode mission et les compteurs de supervision sont partagés. Le serveur doit donc séparer clairement l’état local d’une session et l’état global, puis arrêter proprement tous les threads.

Le protocole reste volontairement lisible dans un terminal, mais le parser et le processeur sont indépendants du réseau : les règles métier peuvent être testées sans ouvrir de socket.

Architecture

Réseau à l’extérieur, règles de commande au centre

CLI clients
TCP
Accept loop +
session jthread
Parser +
CommandProcessor
ServerState +
HTTP monitor

Les descripteurs sont encapsulés dans `UniqueFd`. Les threads utilisent `std::jthread` et des stop tokens pour éviter les cycles de vie implicites. `ServerState` concentre les compteurs atomiques et protège les données composites par mutex.

Décisions d’ingénierie

Un petit serveur pensé pour être repris

01 / TESTABILITY

Parser sans dépendance réseau

Une ligne devient une commande typée ; le processeur retourne une réponse sérialisable et modifie un contexte explicite.

02 / OWNERSHIP

RAII pour les sockets

Le descripteur est fermé automatiquement et ne peut pas être copié par erreur.

03 / CONCURRENCY

État partagé minimal

Les compteurs simples sont atomiques ; le mode et les agrégats nécessitant cohérence sont synchronisés.

04 / OBSERVABILITY

Deux niveaux de supervision

Logs structurés pour le diagnostic et `/status` JSON pour une intégration avec un outil externe.

Démonstration réelle

Validation du protocole et de la machine d’état

La capture montre la suite de tests compilée et exécutée : commandes valides/invalides, sérialisation, règles `CONNECT`/`AUTH`, changement de mode, streaming et état serveur.

Tests du cœur MCPS6 scénarios exécutés avec succès
./mcps_server --port 5555 --token mission-secret --monitor-port 8080
./mcps_client --command "SET_MODE ACTIVE"

Preuves techniques

Ce que le dépôt permet de vérifier

  • Commandes `CONNECT`, `AUTH`, `GET_STATUS`, `START_STREAM`, `SET_MODE`, `PING`, `HELP` et `QUIT` documentées.
  • Tests négatifs sur les commandes invalides et l’accès privilégié avant authentification.
  • Arrêt propre sur `SIGINT`/`SIGTERM` et ownership explicite des sockets.
  • Modèle de sécurité borné et documenté : le token de simulation n’est pas présenté comme suffisant sur un réseau non fiable.
Projet suivantLinux Hardware Bus Driver
→