# 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.