0.2.0-0-pre.6-fix.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/019-UROBURAS_FUNCTIONAL_OWNERSHIP_CLASSIFICATION.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Uroburas — classification fonctionnelle par ownership
|
||||
|
||||
@@ -101,8 +101,12 @@ Le kernel ne connaît pas :
|
||||
|
||||
### Networking client
|
||||
|
||||
- HTTPS ;
|
||||
- WebSocket ;
|
||||
- HTTP(S) client ;
|
||||
- realtime transport API ;
|
||||
- WebSocket baseline ;
|
||||
- WebTransport/QUIC candidate ;
|
||||
- transport capability negotiation ;
|
||||
- fallback transport ;
|
||||
- reconnect ;
|
||||
- timeout/backoff ;
|
||||
- protocole versionné ;
|
||||
@@ -110,6 +114,8 @@ Le kernel ne connaît pas :
|
||||
- validation des messages ;
|
||||
- séparation transport/protocole.
|
||||
|
||||
La logique de jeu ne dépend pas directement de `tokio-tungstenite`, Quinn, WebTransport ou d'un type de transport concret.
|
||||
|
||||
### Logging/telemetry
|
||||
|
||||
- tracing ;
|
||||
@@ -261,6 +267,16 @@ Ces concepts restent Uroburas-specific tant qu'un second jeu ne justifie pas leu
|
||||
- URLs/download authorization ;
|
||||
- publication/modération future.
|
||||
|
||||
### Asset delivery
|
||||
|
||||
- service auto-hébergé ;
|
||||
- HTTP/2 baseline ;
|
||||
- HTTP/3/QUIC lorsque disponible ;
|
||||
- même hostname H2/H3 de préférence ;
|
||||
- cache et distribution multi-nœuds futurs ;
|
||||
- séparation logique du Content service ;
|
||||
- séparation physique uniquement lorsque la charge le justifie.
|
||||
|
||||
### Hall of Fame
|
||||
|
||||
- score submission ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/020-UROBURAS_CRATE_DECOMPOSITION_STUDY.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Uroburas — étude de décomposition en crates
|
||||
|
||||
@@ -31,6 +31,9 @@ crates/capabilities/
|
||||
game-input-lib
|
||||
game-localization-lib
|
||||
game-network-client-lib
|
||||
game-network-realtime-api
|
||||
game-network-websocket-lib
|
||||
game-network-webtransport-lib
|
||||
game-persistence-lib
|
||||
game-audio-lib
|
||||
```
|
||||
@@ -143,7 +146,9 @@ Ne contient pas Actix/Tungstenite/Tonic.
|
||||
Contrats DTO/protocole :
|
||||
|
||||
- HTTP DTOs ;
|
||||
- WebSocket messages ;
|
||||
- realtime messages indépendants du transport ;
|
||||
- WebSocket mapping ;
|
||||
- WebTransport mapping futur ;
|
||||
- versioning ;
|
||||
- validation structurale.
|
||||
|
||||
@@ -165,7 +170,9 @@ Les wire types restent distincts des modèles métier internes.
|
||||
Future Mode 3/2 :
|
||||
|
||||
- Tokio ;
|
||||
- tokio-tungstenite ;
|
||||
- tokio-tungstenite comme baseline WebSocket ;
|
||||
- WebTransport/QUIC comme transport candidat ;
|
||||
- adaptation transport séparée de la simulation ;
|
||||
- rooms/worlds ;
|
||||
- authoritative simulation ;
|
||||
- snapshots/deltas ;
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Uroburas — stack serveur de référence
|
||||
|
||||
@@ -51,19 +51,64 @@ Objectif :
|
||||
|
||||
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
|
||||
|
||||
Référence :
|
||||
Baseline :
|
||||
|
||||
```text
|
||||
Tokio + tokio-tungstenite
|
||||
```
|
||||
|
||||
Candidat à benchmarker :
|
||||
|
||||
```text
|
||||
WebTransport / QUIC
|
||||
```
|
||||
|
||||
Utilisé pour les futurs Modes 3 puis 2.
|
||||
|
||||
La logique de gameplay ne dépend pas directement des types Tungstenite.
|
||||
La capability client doit exposer les propriétés du transport plutôt que simuler une équivalence artificielle :
|
||||
|
||||
Le transport doit rester encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.
|
||||
```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
|
||||
|
||||
@@ -85,9 +130,15 @@ gRPC n'est pas obligatoire pour le transport public client/gameplay.
|
||||
Le client public utilise en priorité :
|
||||
|
||||
```text
|
||||
HTTPS + WebSocket
|
||||
HTTPS
|
||||
+
|
||||
WebSocket baseline
|
||||
+
|
||||
WebTransport lorsque disponible et validé
|
||||
```
|
||||
|
||||
gRPC n'est pas utilisé comme remplacement obligatoire du transport gameplay public.
|
||||
|
||||
## Localization
|
||||
|
||||
Référence :
|
||||
@@ -167,3 +218,38 @@ Mesures candidates :
|
||||
- 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.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/022-UROBURAS_IMPLEMENTATION_DEPENDENCY_ORDER.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Uroburas — ordre d'implémentation par dépendances
|
||||
|
||||
@@ -56,6 +56,8 @@ Construire d'abord les mécanismes nécessaires au Mode 1, en conservant les fro
|
||||
- Fluent serveur ;
|
||||
- Lettre ;
|
||||
- maps/assets metadata ;
|
||||
- asset delivery auto-hébergé ;
|
||||
- HTTP/2 baseline et HTTP/3 si disponible côté asset delivery ;
|
||||
- Hall of Fame ;
|
||||
- rewarded ad authority ;
|
||||
- protocole HTTP sécurisé/versionné.
|
||||
@@ -75,7 +77,10 @@ Construire d'abord les mécanismes nécessaires au Mode 1, en conservant les fro
|
||||
Une fois les moteurs Mode 1 stables :
|
||||
|
||||
- server realtime ;
|
||||
- tokio-tungstenite ;
|
||||
- realtime transport API ;
|
||||
- tokio-tungstenite baseline ;
|
||||
- WebTransport/QUIC candidat après POC ;
|
||||
- fallback transport ;
|
||||
- authoritative simulation ;
|
||||
- world persistence lifecycle ;
|
||||
- bots ;
|
||||
@@ -105,3 +110,9 @@ L'éditeur de maps peut commencer lorsqu'un format de map suffisamment stable ex
|
||||
L'éditeur de skins vient après stabilisation du contrat de skin.
|
||||
|
||||
Ni l'un ni l'autre ne doit bloquer le premier gameplay Challenge minimal.
|
||||
|
||||
## POC transport avant Mode 3
|
||||
|
||||
Avant de figer le transport realtime du Mode 3, un POC dédié doit comparer WebSocket et WebTransport avec la même couche protocolaire.
|
||||
|
||||
Le POC mesure la charge et la robustesse ; il ne doit pas forcer la simulation Uroburas à dépendre d'une implémentation réseau particulière.
|
||||
|
||||
Reference in New Issue
Block a user