Serveur multijoueur

Le relais multijoueur d’En Parlant~ est un serveur WebSocket léger écrit en Rust utilisant Axum et socketioxide. Il connecte deux joueurs pour des parties d’échecs en temps réel via Socket.IO, sans stockage persistant et avec des besoins en ressources minimaux.

Le code source du serveur relais se trouve dans le dépôt en-parlant-relay.

Pourquoi auto-héberger

Le serveur relais par défaut fonctionne immédiatement, mais il existe de bonnes raisons de faire tourner le vôtre :

Confidentialité — tout le trafic de jeu reste sur votre infrastructure
Latence réduite — déployez plus près de vos joueurs pour une transmission des coups plus rapide
Indépendance — aucune dépendance vis-à-vis de la disponibilité du relais par défaut

Options de déploiement

Fly.io (Recommandé)

Le dépôt du relais inclut un fichier de configuration fly.toml, ce qui fait de Fly.io la méthode de déploiement la plus simple. Le niveau gratuit de Fly.io convient à un usage personnel.

Installez le CLI Fly :
Fenêtre de terminal
```
curl -L https://fly.io/install.sh | sh
```
Inscrivez-vous ou connectez-vous :
Fenêtre de terminal
```
fly auth signup
# or
fly auth login
```

Clonez le relais et déployez :

git clone https://github.com/DarrellThomas/en-parlant-relay.git
cd en-parlant-relay
fly launch
fly deploy

Fly.io compilera le binaire Rust, le déploiera et vous fournira une URL publique du type your-app-name.fly.dev.

Auto-hébergé

Compilez le relais depuis les sources et exécutez-le sur n’importe quelle machine disposant d’une chaîne d’outils Rust.

Clonez et compilez :

git clone https://github.com/DarrellThomas/en-parlant-relay.git
cd en-parlant-relay
cargo build --release

Lancez le serveur :
Fenêtre de terminal
```
./target/release/en-parlant-relay
```
Le serveur écoute sur le port 3210 par défaut.
Pour une utilisation en production, placez-le derrière un proxy inverse (nginx, Caddy ou similaire) pour gérer la terminaison TLS. Le relais lui-même communique en WebSocket non chiffré — votre proxy ajoute la couche de chiffrement wss://.

Le serveur est très léger. Il maintient les salles de jeu en mémoire, transmet les coups entre deux joueurs, et ne fait rien d’autre. Un petit VPS ou même un Raspberry Pi peut le gérer sans difficulté.

Configurer En Parlant~

Une fois votre relais en fonctionnement, faites pointer En Parlant~ vers celui-ci :

Ouvrez les Paramètres dans En Parlant~
Trouvez le paramètre d’URL du serveur relais multijoueur
Saisissez le point de terminaison WebSocket de votre serveur :
- Pour Fly.io : wss://your-app-name.fly.dev
- Pour un auto-hébergement avec proxy TLS : wss://relay.yourdomain.com
- Pour le développement local : ws://localhost:3210

C’est tout. L’application utilisera votre relais pour toutes les parties multijoueurs.

Détails du serveur

Voici quelques points à connaître sur le fonctionnement du relais :

Codes de salle — Le serveur génère des codes de jeu de 6 caractères en utilisant un jeu de caractères non ambigu. Les caractères qui se ressemblent sont exclus (pas de 0/O, pas de 1/I/L) afin d’éviter toute confusion lors du partage verbal des codes.
Nettoyage des salles — Les salles sont automatiquement supprimées après 30 minutes d’inactivité. Une tâche de nettoyage s’exécute toutes les 60 secondes pour purger les salles inactives.
Aucun stockage persistant — Tout l’état réside en mémoire. Si le serveur redémarre, les salles actives sont perdues. C’est un choix de conception — le relais est sans état et trivialement remplaçable.
Ressources minimales — Le serveur utilise très peu de CPU et de mémoire. Il ne fait que recevoir les événements Socket.IO d’un joueur et les transmettre à l’autre. Il n’y a aucune logique de jeu, aucune validation des coups, aucune base de données.