Referencia

El protocolo de bonk.io

Un resumen del protocolo que habla la biblioteca, con las trampas más importantes.

Esta página resume lo que hace la biblioteca por debajo. La documentación completa, con todos los ID de paquetes y formatos, está en el archivo BONK_PROTOCOL.md del repositorio.

Capas de red

CapaTecnología
TransporteWebSocket (TLS)
Engine.IOversión 3 (EIO=3)
Socket.IOversión 2
Framing42[eventId, payload]
SerializaciónJSON

Flujo de una sesión

  1. Login en login_legacy.php, que devuelve un token.
  2. Descubrimiento del servidor (getrooms.php para crear, autojoin.php para entrar por URL).
  3. Conexión Socket.IO al servidor indicado, con timesync periódico.
  4. Crear (CREATE_ROOM) o entrar (JOIN_ROOM) en la sala.
  5. El host responde a cada jugador que entra con los datos iniciales (ver abajo).
  6. Partida: el host envía TRIGGER_START y el servidor reenvía GAME_START a todos.

Dos conexiones: Socket.IO y WebRTC

Socket.IO cubre la sala (jugadores, equipos, chat, inicio y fin de partida). Pero el movimiento de los jugadores dentro de la partida no pasa por él: se sincroniza por WebRTC entre los peers, señalizado por un broker PeerJS estándar. Para recibir esos frames (la base del anti-AFK), la biblioteca completa el handshake WebRTC como un jugador normal.

Los frames de input son pequeños paquetes binarios. Hay un frame por tecla pulsada o soltada y ninguno mientras el jugador está quieto.

Datos iniciales para quien entra

Cuando entra un jugador, el host envía un paquete con el estado de la sala. El cliente solo acepta el primero:

SituaciónPaquete
LobbyINFORM_IN_LOBBY (out 11)
Partida en cursoINFORM_IN_GAME (out 40), con state, stateID, fc, inputs, admin, gs, random

Enviar ambos hace que se ignore el segundo. La biblioteca elige el correcto automáticamente.

Trampas que la biblioteca ya resuelve

  • players[] es un array disperso. El índice es el id del jugador; los huecos libres son null.
  • El creador de la sala no recibe JOIN_ROOM. Es el jugador 0 y host.
  • room_full es ambiguo. Solo es terminal cuando el bot aún no ha entrado en la sala.
  • El mapa en INFORM_IN_LOBBY es un objeto JSON, no una cadena LZ.
  • El IS blob depende del número de jugadores y del mapa.
  • bal explícito. Con bal: [], los ids no contiguos pueden generar apariciones intercambiadas.
  • gs.tl debe reflejar el bloqueo real de la sala: con el bloqueo activado y gs.tl: false, los jugadores quedaban congelados.
  • Los ids de paquete tienen espacios de nombres separados por dirección (el 20 recibido es chat; el 20 enviado es otra cosa).

Numeración de equipos

0 spec · 1 FFA · 2 rojo · 3 azul · 4 verde · 5 amarillo.

Límites de tasa

El servidor limita la frecuencia de varios comandos y responde con un status-message (rate_limit_tl para el bloqueo de equipos, rate_limit_cot para los cambios de equipo, etc.). Los códigos terminales, como banned, cierran la sala.