256 lines
4.4 KiB
Markdown
256 lines
4.4 KiB
Markdown
<!-- file: docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# Uroburas — stack serveur de référence
|
|
|
|
## Statut
|
|
|
|
Étude de référence pour `0.2.0-0-pre.6`.
|
|
|
|
## Runtime async
|
|
|
|
Référence :
|
|
|
|
```text
|
|
Tokio
|
|
```
|
|
|
|
## HTTP / Web
|
|
|
|
Référence :
|
|
|
|
```text
|
|
Actix Web
|
|
```
|
|
|
|
Responsabilités initiales :
|
|
|
|
- auth ;
|
|
- compte ;
|
|
- maps/assets metadata ;
|
|
- Hall of Fame ;
|
|
- rewarded grants ;
|
|
- admin initiale ;
|
|
- pages Web.
|
|
|
|
## HTML server-side
|
|
|
|
Référence :
|
|
|
|
```text
|
|
Maud
|
|
```
|
|
|
|
Objectif :
|
|
|
|
- rendu HTML côté Rust ;
|
|
- pages compte ;
|
|
- Hall of Fame ;
|
|
- administration ;
|
|
- pages jeu/portail.
|
|
|
|
Le JavaScript reste réservé aux interactions qui le nécessitent.
|
|
|
|
## Asset delivery auto-hébergé
|
|
|
|
La distribution des maps, skins, sons, sprites, bundles Fluent et autres assets reste auto-hébergée par défaut.
|
|
|
|
Direction :
|
|
|
|
```text
|
|
assets.games.sasedev.com
|
|
HTTP/2
|
|
HTTP/3/QUIC lorsque disponible
|
|
```
|
|
|
|
Le même hostname doit de préférence accepter H2 et H3 avec fallback transparent.
|
|
|
|
La topologie initiale peut rester sur une seule machine, avec séparation logique des hostnames/services. La séparation physique vient ensuite :
|
|
|
|
```text
|
|
Web/API
|
|
Asset delivery
|
|
Realtime
|
|
Database
|
|
Media/replay
|
|
```
|
|
|
|
puis plusieurs nœuds/cache d'assets si la charge le justifie.
|
|
|
|
Aucun CDN tiers n'est une dépendance architecturale obligatoire.
|
|
|
|
## Realtime public
|
|
|
|
Baseline :
|
|
|
|
```text
|
|
Tokio + tokio-tungstenite
|
|
```
|
|
|
|
Candidat à benchmarker :
|
|
|
|
```text
|
|
WebTransport / QUIC
|
|
```
|
|
|
|
Utilisé pour les futurs Modes 3 puis 2.
|
|
|
|
La capability client doit exposer les propriétés du transport plutôt que simuler une équivalence artificielle :
|
|
|
|
```text
|
|
reliable ordered
|
|
streams
|
|
datagrams
|
|
connection migration
|
|
```
|
|
|
|
WebSocket reste le fallback universel lorsque WebTransport n'est pas disponible ou échoue.
|
|
|
|
La logique de gameplay ne dépend pas directement des types Tungstenite, WebTransport ou QUIC.
|
|
|
|
Le transport reste encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.
|
|
|
|
## gRPC
|
|
|
|
Référence conditionnelle :
|
|
|
|
```text
|
|
tonic
|
|
```
|
|
|
|
Utilisation envisagée :
|
|
|
|
- server-to-server ;
|
|
- worker média/replay ;
|
|
- orchestration interne ;
|
|
- appels typés entre services lorsque la séparation physique le justifie.
|
|
|
|
gRPC n'est pas obligatoire pour le transport public client/gameplay.
|
|
|
|
Le client public utilise en priorité :
|
|
|
|
```text
|
|
HTTPS
|
|
+
|
|
WebSocket baseline
|
|
+
|
|
WebTransport lorsque disponible et validé
|
|
```
|
|
|
|
gRPC n'est pas utilisé comme remplacement obligatoire du transport gameplay public.
|
|
|
|
## Localization
|
|
|
|
Référence :
|
|
|
|
```text
|
|
Fluent / fluent-bundle
|
|
```
|
|
|
|
Côté client :
|
|
|
|
- menus ;
|
|
- HUD ;
|
|
- erreurs ;
|
|
- contenu localisé ;
|
|
- maps/assets téléchargeables.
|
|
|
|
Côté serveur :
|
|
|
|
- HTML ;
|
|
- emails ;
|
|
- messages utilisateur ;
|
|
- administration.
|
|
|
|
Les protocoles transportent des codes/identifiants métier, pas des chaînes déjà traduites.
|
|
|
|
## Email
|
|
|
|
Référence :
|
|
|
|
```text
|
|
Lettre
|
|
```
|
|
|
|
Cas initiaux possibles :
|
|
|
|
- vérification de compte ;
|
|
- reset password ;
|
|
- notifications sécurité ;
|
|
- magic link si retenu.
|
|
|
|
Les contenus email utilisent Fluent.
|
|
|
|
## Séparation des modèles
|
|
|
|
Ne pas partager directement comme modèles métier :
|
|
|
|
- types Actix ;
|
|
- types Tungstenite ;
|
|
- messages protobuf ;
|
|
- types Maud.
|
|
|
|
Séparation attendue :
|
|
|
|
```text
|
|
domain model
|
|
HTTP DTO
|
|
WebSocket protocol
|
|
gRPC contracts
|
|
HTML view model
|
|
```
|
|
|
|
## Performance
|
|
|
|
La stack realtime doit être validée par benchmarks de charge avant gel long terme.
|
|
|
|
Mesures candidates :
|
|
|
|
- connexions concurrentes ;
|
|
- mémoire/connexion ;
|
|
- messages/s ;
|
|
- bytes/s ;
|
|
- p50/p95/p99 ;
|
|
- backpressure ;
|
|
- coût broadcast ;
|
|
- coût interest management ;
|
|
- reconnect/resync ;
|
|
- CPU par tick.
|
|
|
|
Le choix `tokio-tungstenite` est la référence initiale, pas une affirmation non mesurée de supériorité universelle.
|
|
|
|
## Frontière transport / protocole
|
|
|
|
La stack doit distinguer :
|
|
|
|
```text
|
|
transport
|
|
↓
|
|
wire codec
|
|
↓
|
|
session protocol
|
|
↓
|
|
synchronization
|
|
↓
|
|
authoritative simulation
|
|
```
|
|
|
|
Cette séparation permet de comparer WebSocket et WebTransport sur le même protocole métier.
|
|
|
|
## POC réseau futur
|
|
|
|
Avant gel long terme du transport realtime, la série POC doit comparer au minimum :
|
|
|
|
- WebSocket / tokio-tungstenite ;
|
|
- WebTransport / QUIC ;
|
|
- fallback automatique ;
|
|
- pics de connexions ;
|
|
- mémoire/connexion ;
|
|
- CPU ;
|
|
- p50/p95/p99 ;
|
|
- pertes réseau ;
|
|
- backpressure ;
|
|
- mobilité réseau ;
|
|
- snapshots/deltas ;
|
|
- broadcast/interest management.
|