Aún recuerdo uno de mis primeros desarrollos en RETABet: llevaba pocas semanas y algo que ahora haría en “un volao” en su momento me costó lo suyo finalizarlo, ya que mi conocimiento del negocio era bastante limitado. Aun así, tras dedicarle el tiempo necesario finalicé el desarrollo, realicé las pruebas pertinentes y di la tarea por terminada…¡O eso creía yo! Resulta que un buen compañero me preguntó si había caído en que, a pesar de que las aplicaciones vayan rápidas en nuestro entorno de desarrollo, es posible que en el mundo real no vayan tan rápidas.
¡Y entonces me habló del Clumsy!
Siempre que comenzamos el desarrollo de una nueva funcionalidad lo primero que hacemos es recoger las especificaciones y requisitos; después, pensamos en la usabilidad y en el diseño gráfico que queremos que tenga el nuevo desarrollo y finalmente, pasamos al ataque. Una vez que el código está terminado, probamos todo a conciencia para evitar sorpresas de última hora pero, en el caso que os comento, no me paré a pensar que la velocidad de transmisión de datos en el entorno de desarrollo (en el que la conexión a internet va como un tiro) dista mucho de la velocidad en el entorno real.
El software que desarrollamos va instalado en máquinas que colocamos en bares, salones de juego y tiendas de apuestas. Siempre nos preocupamos de colocar la mejor conexión de internet posible en esos lugares, porque consideramos que es un factor muy importante de cara a ofrecer la mejor experiencia posible para los usuarios. Aún así no siempre es posible conseguir una buena conexión, y por ello el software ha de ser capaz de gestionar conexiones lentas con retardos muy altos sin que se bloquee o comiencen a darse situaciones no controladas. Cuando detectamos conexiones lentas, mostramos ventanas o animaciones de carga, el típico icono que da vueltas indicando que algo se está haciendo, para informar al usuario que la operación se está realizando, pero ¿cómo saber si nuestro código es correcto cuando en los entornos de desarrollo las comunicaciones son muy rápidas y no fallan nunca?
Aquí es donde entran en juego aplicaciones como Clumsy, una herramienta gratuita y muuuy fácil de utilizar (a menos que nos guste la marcha y queramos complicarnos la vida, claro). Clumsy nos permite comprobar cómo se comporta nuestra aplicación cuando la red va como con los módems de 56k de antaño.
Como podéis comprobar, la interfaz de usuario es bastante simple. Primero tenemos que decidir qué queremos filtrar y para ello podemos optar por la opción fácil de los presets (filtros prestablecidos) e ir afinando si nos vemos con ánimo.
En la interfaz tenemos una selección de presets con los que deberíamos cubrir la mayoría de los escenarios en los que nos encontramos. Podemos decidir si quedarnos sólo con los paquetes generados en nuestro localhost, filtrar por protocolo TCP/UDP, identificar la IP o puerto de interés, etc. ¡Nos podemos poner todo lo tiquismiquis que queramos! Yo suelo quedarme con la opción de “All receiving packets”, que filtra todo el tráfico inbound (paquetes enviados a mi equipo).
A partir de ahí, tenemos que seleccionar qué funciones queremos aplicar al filtrado, que es donde viene lo bueno:
- El Lag identifica al retardo producido en la transmisión de paquetes y es el efecto de una latencia alta o muy alta, siendo para mi uno de los factores más importantes a aplicar en las pruebas. Aumentando el delay seremos capaces de simular situaciones de conexiones lentas y podremos probar qué ocurre cuando algo que de normal cargaría en menos de 1 segundo tarda, por ejemplo, más de 10.
- Drop se refiere a la pérdida aleatoria, basada en un porcentaje, de los paquetes.
- Modificando el throttle conseguimos que un porcentaje de paquetes se bloqueen por un periodo de tiempo (timeframe) definido, con lo que después se enviarían todos los paquetes de golpe. Esto puede ser útil para comprobar cómo se comporta nuestra aplicación cuando llega mucha información a modo de avalancha.
- Podemos optar por modificar el porcentaje de paquetes que queremos que se envíen duplicados, los cuales se clonan y se envían tras el paquete original.
- Si nos interesa, podemos hacer que los paquetes de información vayan desordenados.
- Por último, podemos variar la probabilidad de tampering, que se refiere a la alteración del contenido de la información mientras navega por la red.
Por si fuera poco, todas estas funcionalidades se pueden combinar entre sí y podemos arrancar/parar el filtrado siempre que queramos.
Como veis, usando el Clumsy podemos pasar en cuestión de segundos de un escenario en el que la aplicación funciona perfectamente a otro en el que se ralentice drásticamente por culpa de una conexión que va a pedales, ¡lo cual es vital que tengamos en cuenta cuando hacemos nuestras pruebas!