24 horas de problemas en Daytona

24 horas de problemas en Daytona

El pasado fin de semana se disputaron las 24 horas de Daytona de iRacing en las que participaron cientos de equipos y pilotos. Durante su desarrollo hubo al menos dos momentos en los que muchos de los pilotos desaparecieron de carrera y fueron desconectados del servidor. También hubo otros momentos en los que el simulador parecía volverse loco y los coches aparecían y desaparecían sin ningún tipo de control.

Eso ha provocado varias críticas hacia iRacing. Muchas de ellas que apuntan bastante mal a las causas pero todas ellas comprensibles. Ya que trabajo en el sector he decidido darle un par de vueltas al asunto para intentar explicar de una forma sencilla varias cosas relativas a esos problemas.

Una pequeña introducción técnica

El funcionamiento de un simulador de conducción es realmente complejo porque implica transmitir información entre pilotos y servidor (o servidores) para que cada piloto pueda tener en todo momento una representación fiable del estado de la carrera y pueda actuar/conducir según ello. Esa información incluye la posición de cada coche, su orientación, ángulo de giro, si está acelerando o frenando… además de muchas otras cosas relativas a tiempos o el chat de voz o texto.

Lo más complicado del asunto es que debe ser en tiempo real y tan preciso como sea posible. Por eso toda esa información se envía con mucha frecuencia, varias veces por segundo. Los problemas ocurren cuando esa información no llega, o no lo hace a tiempo (lag). Esto puede ocurrir por diversos motivos, algunos de ellos podrían ser los siguientes:

  • Mala calidad de la conexión de un usuario: no es lo mismo conectarse por fibra que por cobre o por wifi. Son tres medios distintos que transmiten información a velocidades distintas, de la misma forma que el sonido no viaja a la misma velocidad por el agua que por el aire.
  • Distancia entre usuario y servidor: una comunicación entre España y Australia debe recorrer más distancia física que otra entre España y Holanda. Además normalmente hay más puntos intermedios cuanto mayor es la distancia, lo que provoca pequeños retrasos.
  • Problemas de redes: la “capacidad” de las redes no es infinita y cualquier incidencia en ellas provoca que la información tenga que viajar por otras redes o que no pueda viajar en absoluto.

Todas estas cosas complican la tarea del simulador de intercambiar toda la información de carrera entre los pilotos en tiempo real. Algunas veces eso obliga al simulador a predecir algunos datos (por ejemplo la posición de un coche) a partir de información anterior. Otras veces ni siquiera puede hacer nada.

Por todo esto es común ver a algunos coches moverse de forma irregular (lo que muchos conocen como “lag”), a otros desaparecer y aparecer un tiempo después ( “blink”), e incluso contactos entre coches que visualmente no se tocan (el famoso “netcode”). Algún día quizá hable del “netcode”, hoy no toca.

Descartando culpables

Cuando los problemas afectan gravemente al funcionamiento normal, enseguida se le echa la culpa a la incapacidad de los servidores. En muchas ocasiones es así pero en otras tantas no lo es. La conectividad no depende solo de servidores, hay infinidad de elementos implicados. Una incidencia en cualquiera de ellos puede provocar un problema como el que ocurrió en las 24 horas de Daytona.

A pesar de no tener acceso a toda la información que pueden tener en iRacing, la experiencia permite valorar posibilidades y descartar a algunos sospechosos habituales:

  • No fue el ordenador o la conexión a internet de los pilotos. Las caídas fueron masivas y en el mismo momento.
  • No fueron los servidores de iRacing. No todo el mundo cayó y tanto los que quedaron conectados como los que se cayeron (y volvieron) pudieron continuar la carrera. Un servidor puede mantener comunicación simultánea con miles de clientes, tanto antes como después del problema hubo los mismos, o más, usuarios conectados.
  • No parece haber sido un ataque DDoS directo contra iRacing. Desde luego no fue contra los servidores de juego, que no cayeron. Tampoco fue un ataque que buscase colapsar el ancho de banda o la conectividad ya que eso es fácilmente identificable (por experiencia propia). Si iRacing lo ha descartado es porque no han visto nada irregular.

Hipótesis

Lo que sí ha dicho iRacing es que vieron una caída repentina de tráfico y cortes entre datacenters. Su principal sospechoso es la red. Creen que algún punto de la red (servidores, firewalls, cables, switches, routeres…) podría haber recibido tanto tráfico por parte de iRacing que podría no ser capaz de aguantarlo.

Es raro que algo así ocurra sin que alguien de sistemas (de iRacing o de quien gestione la red) coja el teléfono para avisar del problema y ofrecer soluciones. Si alguien usa un ancho de banda superior al contratado o está sobrecargando la red enseguida saltan las alarmas. Si en iRacing “suponen” eso significa que nadie les ha llamado. Eso me hace pensar que algún punto de la red ha rechazado tráfico en masa pero no por colapso.

Llegados a este punto recordé unas declaraciones de Chris Page (uno de los responsables técnicos de iRacing) de hace un año. Ni siquiera sé por qué recordé esto en concreto pero lo transcribo aquí y hago una traducción libre:

"What is interesting is that our normal traffic has the signature of a DDoS Attack. Our service is different than most, and our traffic patterns are not what the services are optimized to deal with."
"Lo interesante es que nuestro tráfico habitual tiene la misma pinta que un ataque DDoS. Nuestro servicio es diferente a la mayoría y muchos servicios no están preparados/optimizados para tratar con los patrones de nuestro tráfico (y distinguir que no es un ataque DDoS)."

Es decir, por cómo es iRacing generan un tráfico que puede ser fácilmente confundible con un ataque DDoS (entiendo que paquetes con estructura similar, UDP, broadcasting contínuo…). Si un montón de tráfico es rechazado y no se debe a un colapso de la red, podría deberse a que hay alguna solución anti-DDoS o un cortafuegos actuando y rechazando las conexiones automáticamente.

Sería gracioso porque en ese caso se estaría rechazando tráfico legítimo, que es algo con lo que bromeaba el propio Chris Page. No puedo asegurar al 100% que ese sea el problema pero es factible y a mí me cuadra totalmente. Intentaré ponerme en contacto con alguien de iRacing para soltar la idea por si nadie ha pensado en eso.

Conclusión

Siempre hay muchos sospechosos a los que la gente señala enfadada (como es lógico) pero sin mucha puntería. El papel de iRacing es complicado porque es el primer eslabón de la cadena para sus usuarios y eso significa que algunas veces se les da con razón y otras sin ella.

En este caso, sin saber con seguridad la causa, me parece aventurado responsabilizar a alguien. Especialmente cuando detrás de un problema puede haber muchas personas implicadas a distintos niveles y en distintas empresas. Eso sí, el enfado es comprensible.

24 de Enero de 2017
Fórmula Renault 2.0 2017 S1 W5

Fórmula Renault 2.0 2017 S1 W5

La quinta semana del campeonato de Fórmula Renault 2.0, primera para mí, tenía como escenario el clásico Autódromo José Carlos Pace (Interlagos). Me llamaba bastante la atención probar cómo se comportaba el coche aquí así que le dediqué bastante tiempo.

En un primer momento estuve a punto de tirar la toalla al resultarme imposible tener un setup rápido que fuese lo suficientemente estable en las eses de Senna y en la última curva, donde se iba mucho de atrás, pero conseguí arreglarlo y me acostumbré.

17 de Enero de 2017
Formula Renault 2.0 (2017 S1)

Formula Renault 2.0 (2017 S1)

En los últimos meses el Fórmula Renault 2.0 ha sido el coche al que más tiempo he dedicado. No es extremadamente rápido pero tiene una mezcla entre agilidad y rebeldía que permiten disfrutarlo siempre que uno no fuerce demasiado.

Esta temporada seguirá siendo mi coche de referencia y me tocará estrenar los colores y el nombre de FastRepair Motorsport tras los cambios que hemos hecho en el equipo.

13 de Enero de 2017