4.4 KiB
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 :
Tokio
HTTP / Web
Référence :
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 :
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 :
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 :
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 :
Tokio + tokio-tungstenite
Candidat à benchmarker :
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 :
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 :
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é :
HTTPS
+
WebSocket baseline
+
WebTransport lorsque disponible et validé
gRPC n'est pas utilisé comme remplacement obligatoire du transport gameplay public.
Localization
Référence :
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.
Référence :
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 :
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 :
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.