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.

Baseline :

Tokio
tokio-tungstenite
WebSocket

Candidat à évaluer :

WebTransport
QUIC

La simulation authoritative ne dépend directement d'aucun de ces transports.

Frontière de transport

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.

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.

1.9 KiB Raw Blame History