0.2.0-0-pre.7
This commit is contained in:
85
docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md
Normal file
85
docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md
Normal file
@@ -0,0 +1,85 @@
|
||||
<!-- file: docs/architecture/013-NETWORK_AND_SERVER_ARCHITECTURE.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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.
|
||||
Reference in New Issue
Block a user