Architecture réseau et serveur

Web/API

La stack serveur Web de référence est :

Tokio
Actix Web
Maud
Fluent / fluent-bundle
Lettre

Actix Web porte le Web/API, l'authentification, les comptes, Hall of Fame, metadata de contenu, reward authority et administration initiale.

Realtime

Le realtime est séparé du Web/API classique.

Backends retenus :

WebSocket
    Tokio + tokio-tungstenite
    baseline/fallback de référence

WebTransport
    QUIC + HTTP/3
    second backend retenu

La simulation authoritative ne dépend directement d'aucun de ces transports. WebTransport est retenu à l'issue du POC 0.3.5 pour son chemin fiable natif/navigateur et sa capacité datagram optionnelle, sans remplacer WebSocket ni élargir artificiellement le contrat commun.

Frontière de transport

transport
    ↓
wire codec
    ↓
session protocol
    ↓
synchronization
    ↓
authoritative simulation

Le client utilise une realtime transport API fiable/ordonnée commune. WebSocket reste le fallback de référence. WebTransport peut satisfaire cette même frontière via son stream bidirectionnel primaire ; ses datagrams restent backend-spécifiques car leur sémantique non fiable/non ordonnée n’appartient pas à RealtimeConnection. Le choix WebTransport-first/fallback WebSocket appartient à la composition ou à un adapter de plateforme, jamais au gameplay.

gRPC

tonic/gRPC est réservé aux frontières server-to-server qui le justifient. Il n'est pas un transport obligatoire entre le client public et le serveur realtime.

Asset delivery

Les assets sont auto-hébergés par défaut.

assets.games.sasedev.com
    HTTP/2
    HTTP/3/QUIC si disponible

H2 et H3 peuvent coexister sur le même hostname avec fallback.

Content metadata/authorization et transfert lourd d'assets sont deux responsabilités distinctes.

Déploiement progressif

Une seule machine peut initialement héberger plusieurs services logiques.

L'architecture permet ensuite de séparer Web/API, Assets, Realtime, Database et Media/replay, puis de multiplier les nœuds selon la charge.

Portabilité d'exploitation

Debian Stable est la cible opérationnelle préférée.

Le choix futur d'un edge/reverse proxy HTTP/3, stockage ou composant d'infrastructure reste reporté aux POC correspondants et doit tenir compte de la disponibilité/maturité sur Debian Stable.

Portabilité démontrée par le POC WebTransport 0.3.5

La preuve 0.3.5 couvre :

Linux natif client/server WebTransport en loopback ;
client navigateur/WASM réel contre le serveur Rust natif ;
cross-compilation du backend pour Android ARM64 aarch64-linux-android, API 21, avec NDK 28.2.13676358.

La preuve Android est une preuve de compilation et ne vaut pas smoke runtime réseau sur appareil. Les plateformes Apple ne sont pas déclarées validées par cette version. Les résultats de caractérisation loopback sont documentés séparément et ne sont pas extrapolés à Internet/mobile.

3.1 KiB Raw Blame History Unescape Escape