# Architecture réseau et serveur ## Web/API La stack serveur Web de référence est : ```text 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. Baseline : ```text Tokio tokio-tungstenite WebSocket ``` Candidat à évaluer : ```text WebTransport QUIC ``` La simulation authoritative ne dépend directement d'aucun de ces transports. ## Frontière de transport ```text transport ↓ wire codec ↓ session protocol ↓ synchronization ↓ authoritative simulation ``` Le client utilise une realtime transport API. WebSocket reste le fallback de référence. WebTransport est évalué lorsqu'il apporte un bénéfice mesuré. ## 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. ```text 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.