cpp-mission-control-protocol-server

Banner generated by ChatGPT.

A C++20 Linux mission-control protocol server exposing a small command/control protocol over TCP, with multi-client handling, token authentication, structured logs, parser tests, a CLI client and a lightweight HTTP monitoring endpoint.

Why this project exists

This project is a compact systems/software-engineering exercise inspired by industrial mission-control and command/monitoring software. It combines Linux networking, modern C++ resource management, concurrency, protocol parsing, observability and automated tests while keeping the codebase small enough to study end to end.

Features

• TCP server accepting multiple clients concurrently.
• Line-oriented Mission Control Protocol (MCPS/1.0).
• Commands: CONNECT, AUTH <token>, GET_STATUS, START_STREAM, STOP_STREAM, SET_MODE SAFE|ACTIVE|MAINTENANCE, PING, HELP, QUIT.
• Token authentication before privileged commands.
• Authentication tokens redacted from server logs.
• Per-client telemetry stream mode.
• Thread-safe server state using std::atomic, std::mutex and RAII wrappers.
• std::jthread based accept, client and monitoring loops with cooperative shutdown.
• Bounded command-line input and socket send timeouts to avoid unbounded buffering/blocking.
• Command parser and processor separated from networking for deterministic unit tests.
• CLI client for scripted or interactive sessions.
• HTTP monitor exposing /status as JSON and / as a minimal HTML dashboard.
• CMake + CTest based tests with no third-party C++ dependency.

Requirements

The project targets Linux/POSIX networking and requires:

• a C++20 compiler (GCC or Clang);
• CMake 3.16 or newer;
• POSIX threads;
• Bash for scripts/demo.sh;
• curl only for the optional HTTP check in the demo.

On Debian/Ubuntu, a typical development environment is:

sudo apt update
sudo apt install build-essential cmake curl

Build and test

Run these commands from the repository root:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DMCPS_BUILD_TESTS=ON
cmake --build build --parallel
ctest --test-dir build --output-on-failure

For strict compilation with warnings treated as errors:

cmake -S . -B build-werror -DCMAKE_BUILD_TYPE=Release -DMCPS_BUILD_TESTS=ON -DMCPS_WARNINGS_AS_ERRORS=ON
cmake --build build-werror --parallel
ctest --test-dir build-werror --output-on-failure

Run the server

./build/mcps_server \
  --host 0.0.0.0 \
  --port 5555 \
  --token mission-secret \
  --monitor-port 8080 \
  --log-file mcps.log

The server stops on SIGINT (Ctrl+C) or SIGTERM. Use --no-monitor if the HTTP endpoint is not required.

Use the CLI client

The client sends CONNECT and AUTH automatically unless --no-auto-auth is supplied.

Send one command:

./build/mcps_client --host 127.0.0.1 --port 5555 --token mission-secret --command GET_STATUS

Set the mission mode:

./build/mcps_client --host 127.0.0.1 --port 5555 --token mission-secret --command "SET_MODE ACTIVE"

Receive telemetry events for three seconds:

./build/mcps_client --host 127.0.0.1 --port 5555 --token mission-secret --stream-seconds 3

Start an interactive session:

./build/mcps_client --host 127.0.0.1 --port 5555 --token mission-secret

End-to-end demo

The demo configures and builds the project, starts a local server, exercises status/mode/stream commands and queries the HTTP monitor when curl is available:

bash scripts/demo.sh

By default the script starts searching from ports 5555 and 8080 and automatically chooses the next free local ports if either one is already occupied. Ports and token can also be forced explicitly:

MCPS_PORT=15555 MCPS_MONITOR_PORT=18080 MCPS_TOKEN=demo-secret bash scripts/demo.sh

HTTP monitoring

With the server running on monitor port 8080:

curl --fail --silent --show-error http://127.0.0.1:8080/
curl --fail --silent --show-error http://127.0.0.1:8080/status

Example /status response:

{
  "mode": "SAFE",
  "any_stream_active": false,
  "connected_clients": 1,
  "authenticated_clients": 1,
  "active_streams": 0,
  "commands": 3,
  "protocol_errors": 0,
  "auth_failures": 0,
  "telemetry_events": 0,
  "uptime_ms": 1024
}

The actual counters naturally depend on the clients connected when the request is made.

Command-line help

The executables expose their complete supported options:

./build/mcps_server --help
./build/mcps_client --help

Important server options include --no-monitor, --stream-period-ms <positive-ms> and --debug.

Repository layout

include/mcps/          Public C++ headers
src/                   Core implementation and server implementation
apps/                  mcps_server and mcps_client executables
tests/                 Unit tests driven by CTest
docs/                  Protocol, security, architecture and test documentation
scripts/demo.sh        End-to-end build/run smoke test
examples/              Example MCPS command session

Security model

This is a simulator/portfolio project, not a production command-and-control service. It deliberately uses a static bearer token and an unauthenticated HTTP monitoring endpoint. The token is redacted from logs and protocol input is bounded, but the project does not provide TLS, user identities, role-based authorization, token rotation or rate limiting.

Do not expose it directly to an untrusted network. See docs/SECURITY.md for the exact security assumptions and limitations.