Trystero - créer instantanément des webapps multijoueur sans serveur

• Une bibliothèque qui permet de créer des webapps multijoueur interconnectées sans serveur avec seulement quelques lignes de code
• Basée sur WebRTC dans le navigateur, elle utilise des réseaux publics comme canaux d’échange de signaux (signaling) pour automatiser l’appairage P2P et la communication
  • Permet la découverte de pairs sans serveur en choisissant l’un de BitTorrent, Nostr, MQTT, IPFS, Supabase, Firebase
  • Après le signaling, les données de l’application sont transmises directement en P2P avec chiffrement E2E, sans passer par un intermédiaire
• Propose des abstractions de haut niveau comme les rooms / la diffusion, la sérialisation automatique, le chunking / throttling des gros volumes de données, les événements de progression, le chiffrement des données de session et les métadonnées de flux
• Fonctionne non seulement dans le navigateur mais aussi sur Node/Deno/Bun, avec des fonctionnalités adaptées à la production comme la configuration de serveurs TURN, les hooks React et l’exécution côté serveur
• Son approche qui exploite une infrastructure publique sans configuration le rend particulièrement adapté à divers essais et prototypes

• Site de démo - https://oxism.com/trystero : ouvrez-le en même temps dans deux onglets, puis essayez de déplacer la souris / cliquer pour voir immédiatement comment cela fonctionne
• Voir ce que les gens créent avec Trystero - Awesome Trystero

[kimjoin2]

Le serveur TURN, c’est fourni par les ancêtres ?

[helio]

'stun:stun.cloudflare.com:3478' est codé en dur dans le code source.

[kimjoin2]

Ce n’est pas STUN, mais TURN.
STUN se limite à indiquer, en gros, « qui vous êtes » sur la base de STUN, donc il existe quelques serveurs publics,
mais TURN doit relayer le trafic, donc soit on paie pour l’utiliser (parce que ça coûte cher), soit on le déploie soi-même.
Ex. : https://github.com/coturn/coturn
Ce genre de chose.

Il y a certes beaucoup de cas où la communication fonctionne avec STUN seul, mais dire simplement que « ça marche », c’est un peu…
Ça marche… en quelque sorte… mais bon… c’est l’impression que ça donne.

[skageektp]

S’il s’agit d’un appairage P2P, il n’y a pas besoin de TURN, non ?

[kimjoin2]

Je pense que cela dépend de ce que vous entendez par « mise en correspondance P2P » dans WebRTC.

1. état où les deux parties peuvent échanger des paquets en UDP
2. état où les deux parties connaissent seulement l’adresse indiquée par STUN

Dans le cas 1, comme vous l’avez dit, TURN n’est pas nécessaire.
Même dans le cas 2, si les conditions sont favorables et que la communication UDP entre les deux parties a réussi, TURN n’est pas nécessaire.

Dans le cas 2, si l’échange de paquets en UDP entre les deux parties échoue, TURN est nécessaire.

Les causes possibles d’échec sont :

• le pair est derrière un NAT symétrique, ou autre situation où l’adresse (ou le port) découverte par STUN ne peut pas être utilisée ;
• quelque part sur le réseau, seul le trafic web est autorisé (80, 443) ;
• quelque part sur le réseau, l’UDP est bloqué ;
• un côté n’utilise que l’IPv4 et l’autre uniquement l’IPv6 ;
• etc.

Dans ces cas-là, il faut utiliser TURN.

(J’ai appris pour la première fois en revérifiant mes souvenirs qu’une connexion ipv4 only <-> ipv6 only ne fonctionne pas.)

[skageektp]

Oui, donc c’est bien la 2. Vous avez parlé de « connexion mutuelle sans serveur » et de « bibliothèque », mais n’en attendez-vous pas un peu trop…

[kimjoin2]

De quelle partie voulez-vous parler exactement ?

1. Comme l’interconnexion est possible uniquement avec l’adresse (+ port) fournie par STUN, un serveur TURN n’est pas nécessaire. Donc l’expression « interconnexion mutuelle sans serveur » est littéralement correcte.
   -> Si c’est ça, alors ce que je sais doit être ancien. Si la situation a changé depuis ce que je connaissais (et ai partagé), je vous serais reconnaissant de m’indiquer ce qui a évolué~ !
2. Un serveur TURN est nécessaire, mais comme c’est une bibliothèque, on peut être indulgent à ce niveau.
   -> Ce qu’a dit skageektp est correct. Comme c’est une bibliothèque, on peut effectivement être indulgent sur ce point. C’est moi qui ai été trop sensible.

Pour ma part,
3. pour l’utiliser correctement, STUN seul ne suffit pas et TURN est nécessaire, donc c’est très exagéré~
est ce que je voulais exprimer.

[kimjoin2]

Je corrige les explications des points 1 et 2.

1. État où les pairs peuvent échanger des paquets via UDP -> État où les pairs peuvent échanger des paquets via UDP entre eux
2. État où l’on ne connaît que l’adresse indiquée par STUN -> État où les pairs ne connaissent que l’adresse indiquée par STUN

Je vais donc corriger ainsi. Dans le texte original, cela pouvait prêter à confusion.