Método de interacción online eliminando el efecto de la latencia de red

Sector de la técnica

El campo técnico de la presente invención es el de la interacción en tiempo real en internet de distintos sistemas con un servidor en el que se ejecutan juegos y aplicaciones de ocio, apuestas, concursos, etc. La invención se aplica, en particular, a juegos de cronometraje en tiempo real, tales como Chronogame.

Estado de la técnica

Existen numerosas aplicaciones que permiten la interacción en tiempo real en internet, por ejemplo, de sistemas de compra mediante subasta. Sin embargo, estos sistemas resultan incompatibles para aplicaciones en donde la sincronización de la interacción debe ser instantánea o cuasi instantánea y los diversos sistemas participantes en la interacción participan a través de servidores con muy distinto tiempo de interacción con el servidor principal de la aplicación. Esto es lo que se denomina latencia de red, que es el retraso de comunicación existente entre los distintos participantes y el servidor en donde se ejecuta la aplicación. Cuando la latencia de red difiere entre los participantes, los comandos recibidos en el servidor de la aplicación no se reciben en el mismo orden en que han sido ejecutados, y es posible que se cree una distorsión o discrepancia entre la ejecución de los comandos en tiempo real y la recepción de los mismos en el servidor. En aplicaciones de entretenimiento, apuestas o subastas, este hecho produce que los ganadores no sean justos ganadores, sino que el resultado se vea condicionado por pequeñas diferencias de latencia entre los participantes y el servidor de la aplicación. Cuando estas diferencias alcanzan el orden de los milisegundos, el resultado final puede verse afectado por las diferentes latencias de los participantes. Diversos han sido los sistemas empleados hasta la fecha para compensar o corregir las diferencias de latencia. Por ejemplo, la patente US2021226877A1 describe un sistema de juego en la nube que implementa un método consistente en realizar un moni- toreo para determinar la latencia de la red y, en función de cuál sea la latencia detectada, incrementar la frecuencia de imagen para compensar aquellas redes con mucha latencia, o bien reducir dicha frecuencia de imagen para aprovechar las redes con mejor rendimiento.

Otra solución frecuentemente utilizada consiste en penalizar a los usuarios cuyas redes ofrecen un mejor rendimiento, induciendo la latencia en las mismas hasta aproximarla a la del jugador que sufre mayor latencia. Así, la patente WO 2020/072183A1 que describe un dispositivo que incluye un procesador capaz de determinar la latencia correspondiente al flujo de datos enviado a cada jugador e inducir una mayor latencia en aquellos jugadores cuyo flujo de datos de entrada presentaban menor latencia para reducir la diferencia de latencia entre jugadores. De un modo similar, la patente US010722788B2 propone equilibrar las condiciones de los jugadores en determinados juegos multijugador online mediante un servidor específico de gestión de latencias que, entre otras funcionalidades, añade latencia a determinadas comunicaciones para equilibrar los tiempos de respuesta entre todos los usuarios.

Las soluciones descritas, sin embargo, no solucionan el problema que plantean los juegos de cronometraje en tiempo real, como Chronogame, en los que lo que se necesita no es reducir o minimizar la latencia sino neutralizar totalmente su efecto para garantizar que la igualdad de condiciones entre los jugadores sea real y efectiva. Ello además de que la latencia viene en ocasiones provocada por otros factores ajenos a la implementación o ejecución del propio juego y por tanto difíciles de controlar, tales como la propia infraestructura de red del usuario, o la distancia (tanto física como lógica) entre el servidor desde donde se ejecuta el juego y el dispositivo del usuario. Esto hace que la solución en juegos de cronometraje en tiempo real no pueda basarse en la gestión de la latencia. Para superar los inconvenientes descritos, el objeto de la presente invención propone un método de interacción de sistemas o participantes en internet, especialmente aplicable a juegos de cronometraje en tiempo real, que resuelve el problema técnico planteado, esto es: garantizar que los jugadores con distintas características de red jueguen en igualdad de condiciones a pesar de la diferente latencia de red de cada jugador, de la forma que se describe a continuación.

Descripción resumida de la invención

Método de interacción de sistemas o participantes en internet con una aplicación de cronometraje en tiempo real ejecutada en un servidor, caracterizado porque la aplicación crea y envía a cada participante, una vez realizada su autenticación, un canal independiente para la transmisión de los mensajes o paquetes cifrados de datos.

El citado canal se crea para cada participante a través de una conexión HTTPS estándar, entre el participante y el servidor. El cifrado de los mensajes, por su parte, se realiza end-to-end entre el servidor y el participante con el certificado de este último.

Con un método como el anterior, cada participante tiene su propia línea de tiempo, independientemente de que su latencia cambie en cada instante e independiente de la línea de tiempo de los restantes participantes.

Opcionalmente, se notifica a cada participante cuando su latencia es superior a 500 ms. Con esto se evita que haya esperas de tiempo elevadas para finalizar cada turno o ronda de interacción y se consigue mantener cierta velocidad en las interacciones.

Preferiblemente, la aplicación comprende una variable agregada que define la velocidad o ritmo en milisegundos en el que se envían los mensajes cifrados, que puede asignarse aleatoriamente o manualmente. Por ejemplo, en una aplicación de cronometraje en tiempo real, si el Random Number Generator o RNG ¹ nos genera el número 1292 como objetivo y el valor 2 como velocidad, cada 2 milisegundos enviaremos un mensaje con el decremento. El número 1292 significa que cada participante tiene que cronometrar 12 segundos (o unidades aleatorias) y 92 centésimas de segundo (o unidades aleatorias) con la mayor precisión posible.

Esta velocidad cambiará en cada modo de juego y cada llamada al RNG.

Breve descripción de las figuras

Para complementar la descripción que se está realizando y con objeto de ayudar a una mejor comprensión de las características de la invención, se acompaña a la presente memoria descriptiva, como parte integrante de la misma, unos dibujos en los que con carácter ilustrativo y no limitativo se ha representado lo siguiente:

La Figura 1 muestra una representación esquemática de las diferencias de latencias entre los participantes, el tiempo real transcurrido en milisegundos, y la estructura de casillas o frames (F1-F9) en que se divide el ring buffer creado en el canal (C) de cada participante.

Descripción detallada de la invención

A continuación, se describen los pasos del método de interacción utilizado en una aplicación de cronometraje en tiempo real como ChronoGame:

• Se generan 2 números aleatorios para la partida o Utilizados para determinar el número objetivo y el ritmo o velocidad a

¹ https://www.kernel.org/doc/html/v4.14/crvpto/api-rnq.html la que se contabilizará cada ciclo de incremento de tiempo (desde 0 hasta el número objetivo) o bien cada ciclo de decremento de tiempo (desde el número objetivo hasta 0) determinados por el servidor del juego (GameServer) para la partida

• Se establece un canal (C) de tipo websocket o socket (dependiendo de la arquitectura del cliente) con cada jugador conectado sobre SSL/TLS, a través del cual se enviarán los mensajes cifrados.

• Se inicia el modo del juego en el servidor (GameServer) que recibe como parámetros estos 2 números.

• Basándose en dichos 2 números, el GameServer, que es del tipo servidor de aplicación backend, crea para cada jugador un ring buffer dividido en casillas o frames (F1-F9). En cada frame se escribe el mensaje cifrado que contiene el número correspondiente al ciclo de incremento o decremento, de forma sucesiva hasta llenar el ring buffer. o Un ring buffer es un estándar de desarrollo utilizado para definir una cola circular de datos, tal como ¡lustra la siguiente imagen:

Modelo Ring Buffer o El tamaño del ring buffer es el mismo que el número objetivo y el número de casillas o frames (F1-F9) del ring buffer es igual al número de ciclos de incremento o decremento de tiempo determinados por el servidor (GameServer). o Por ejemplo, si el número objetivo es 1000 (10 segundos y 00 centésimas), la velocidad asignada es 10 y el ciclo de incremento es de 1 centésima, se crea un ring buffer de 1000 casillas o frames (F1-F9) y el ciclo de incremento que corresponde escribir en cada una de dichas casillas o frames es enviado cada 10 milisegundos, comenzando la partida en 0 y terminando en 1000, a menos que los participantes pulsen antes el botón de parada. o El ring buffer se compone de un timer, que es el programa encargado de escribir en la siguiente casilla o frame libre del buffer el mensaje cifrado correspondiente, y el websocket, que es el canal (C) creado entre el servidor y cada participante y su función es leer el primer mensaje cifrado disponible y enviárselo al participante.

• El juego se inicia y cada mensaje cifrado que contiene el ciclo de decremento/incremento se envía a cada participante a través del canal seguro (C) creado para cada uno y se escribe en la correspondiente casilla o frame (F1-F9) del buffer circular asignado a cada participante.

• En el momento de escribir el mensaje cifrado que contiene el ciclo de incremento o decremento en la casilla o frame del buffer se firma para ese participante/ socket/ronda/firma anterior y tiempo del GameServer para garantizar la integridad del mensaje.

• El participante recibe, independientemente de su latencia, el mensaje cifrado que contiene el ciclo de incremento o decremento en la correspondiente casilla o frame del buffer y con esto está en igualdad de condiciones que el resto. • Una vez recibido el mensaje cifrado que contiene el ciclo de incremento o decremento en la correspondiente casilla o frame del buffer se produce un aviso de confirmación y se marca en el servidor como procesado.

• Cuando el participante presiona el botón de “parada” se detiene el consumo de casillas o frames y se notifica la casilla o frame en el que se presionó el botón de “parada”, que coincidirá con el último procesado.

• El servidor (GameServer) verifica la firma, el tiempo real versus el enviado para que la latencia no supere los 500 ms y que la casilla o frame notificado corresponda con el último mensaje recibido en el buffer.

Por su parte, el mensaje que contiene el ciclo de incremento o decremento de tiempo que corresponde en la partida es enviado al participante de manera cifrada, acompañado de un hash y sello de tiempo, para garantizar su integridad, ocupando la casilla o frame correspondiente dentro del ring buffer.

Podemos apreciar que con este mecanismo se respeta la igualdad de condiciones pese a que las latencias de los participantes sean diferentes.

Gracias a la presente invención, se consigue neutralizar el efecto nocivo que la diferente latencia de red de los participantes provoca en un juego de cronometraje en tiempo real, tal como Chronogame, garantizando la igualdad de condiciones en el juego, y sin que sea necesario actuar directamente sobre la latencia.