Le protocole de bonk.io

Cette page résume ce que fait la bibliothèque en coulisses. La documentation complète, avec tous les ID de paquets et les formats, se trouve dans le fichier BONK_PROTOCOL.md du dépôt.

Couches réseau

Déroulement d'une session

1. Login sur login_legacy.php, qui renvoie un token.
2. Découverte du serveur (getrooms.php pour créer, autojoin.php pour rejoindre par URL).
3. Connexion Socket.IO au serveur indiqué, avec un timesync périodique.
4. Créer (CREATE_ROOM) ou rejoindre (JOIN_ROOM) le salon.
5. L'hôte répond à chaque joueur qui arrive avec les données initiales (voir plus bas).
6. Partie : l'hôte envoie TRIGGER_START et le serveur renvoie GAME_START à tous.

Deux connexions : Socket.IO et WebRTC

Socket.IO couvre le salon (joueurs, équipes, chat, début et fin de partie). Mais le mouvement des joueurs pendant la partie ne passe pas par lui : il est synchronisé par WebRTC entre les pairs, signalé par un broker PeerJS standard. Pour recevoir ces frames (la base de l'anti-AFK), la bibliothèque complète le handshake WebRTC comme un joueur ordinaire.

Les frames d'input sont de petits paquets binaires. Il y a une frame par touche pressée ou relâchée et aucune tant que le joueur est immobile.

Données initiales de celui qui arrive

Quand un joueur arrive, l'hôte envoie un paquet avec l'état du salon. Le client n'accepte que le premier :

Envoyer les deux fait ignorer le second. La bibliothèque choisit automatiquement le bon.

Pièges que la bibliothèque gère déjà

• players[] est un tableau creux. L'indice est l'id du joueur ; les emplacements libres sont null.
• Le créateur du salon ne reçoit pas JOIN_ROOM. C'est le joueur 0 et l'hôte.
• room_full est ambigu. Il n'est terminal que si le bot n'est pas encore entré dans le salon.
• La carte dans INFORM_IN_LOBBY est un objet JSON, pas une chaîne LZ.
• L'IS blob dépend du nombre de joueurs et de la carte.
• bal explicite. Avec bal: [], des ids non contigus peuvent produire des apparitions inversées.
• gs.tl doit refléter le vrai verrou du salon : avec le verrou activé et gs.tl: false, les joueurs restaient figés.
• Les ids de paquets ont des espaces de noms séparés selon la direction (le 20 reçu est le chat ; le 20 envoyé est autre chose).

Numérotation des équipes

0 spec · 1 FFA · 2 rouge · 3 bleu · 4 vert · 5 jaune.

Limites de débit

Le serveur limite la fréquence de plusieurs commandes et répond par un status-message (rate_limit_tl pour le verrouillage des équipes, rate_limit_cot pour les changements d'équipe, etc.). Les codes terminaux, comme banned, mettent fin au salon.