93 lines
3.1 KiB
Markdown
93 lines
3.1 KiB
Markdown
<!-- file: docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md -->
|
||
<!-- version: 2 -->
|
||
|
||
# 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.
|
||
|
||
Backends retenus :
|
||
|
||
```text
|
||
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
|
||
|
||
```text
|
||
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.
|
||
|
||
```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.
|
||
## 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.
|
||
|