LESSONS FROM THE DEMISE OF THE UK’S NORTHERN ROCK AND THE U.S.’S COUNTRYWIDE AND INDYMAC
3. Similarities and Differences Among the Three Cases
3.2. Failure Resolution Process
A continuación se detallan algunos escenarios de calidad considerados, ordenados según su categoría y en formato fuenteestímulorespuesta.
4.6.1. Modificabilidad
Escenario de calidad 1: Se desea que los administradores tengan la capacidad de agregar y modificar, de manera sencilla, nuevas configuraciones de juego; y de elegir con qué configuración de las existentes se comienzan, por defecto, las partidas. Éstas configuraciones con conjuntos de valores para ciertas variables de juego, que se cargan al principio de cada partida y cuyos valores permiten graduar la dificultad del juego y los
elementos del mismo que serán instanciados durante la partida (cartas, actividades, escenarios, etcétera). ● Fuente: Administrador ● Estímulo: Agregar nuevas configuraciones ● Entorno: En tiempo de ejecución ● Artefacto: Plataforma desarrollada
● Respuesta: El sistema debe almacenar la configuración agregada o modificada y tenerla disponible para cuando se desee utilizarla.
● Medida rta: El agregado o modificación no debe interferir con el normal funcionamiento de la plataforma.
Para dar respuesta a este escenario se aprovechó la estructura que ya existía respecto a la persistencia: las configuraciones deben almacenarse en la base de datos. De esta forma, sólo hace falta definir una interfaz en la aplicación para que el administrador pueda editar las configuraciones existentes o agregar nuevas; al comenzar una partida, el sistema carga automáticamente desde la base de datos la configuración elegida como “por defecto” (este valor se almacena también en la base de datos).
Para almacenar las configuraciones, se creó una nueva colección en la base de datos, llamada configs, que guarda los documentos de este tipo.
Fig. 19. UCM: Agregar o editar configuraciones de juego. Para dar soporte a esta funcionalidad, también fue preciso definir una nueva vista de administrador en la plataforma. Para su facilidad de acceso se implementó el acceso como administrador como una variante del login común, pero con una cuenta y contraseña que sí deben estar almacenadas en la base de datos (a diferencia del login de jugadores, que se lleva a cabo a través de redes sociales exclusivamente). Se diseñaron, entonces, nuevas vistas de login especial para administrador y de panel de administración para editar las configuraciones.
Fig. 20. Captura: Vista de administrador, pestaña Configuraciones.
Escenario de calidad 2: Se desea que los administradores tengan la capacidad de agregar y modificar, de manera sencilla, nuevas recomendaciones. Estas son mensajes que se muestran a los jugadores en determinados contextos (al comenzar un escenario, al recibir cierta carta, ante cierta actividad) y en función a los resultados que han obtenido en la encuesta (para mostrar ciertas recomendaciones en función de la “actitud” calculada para cada jugador). Los administradores deben poder definir de forma sencilla una recomendación, el contexto en que se muestra y las condiciones de mostrado.
● Fuente: Administrador
● Estímulo: Agregar nuevas recomendaciones ● Entorno: En tiempo de ejecución
● Artefacto: Plataforma desarrollada
● Respuesta: El sistema debe almacenar la recomendación agregada o modificada y mostrarla a los jugadores cuando corresponda.
● Medida rta: El agregado o modificación no debe interferir con el normal funcionamiento de la plataforma.
La solución para este escenario fue llevada a cabo de forma idéntica al anterior, en cuanto al agregado y modificación: se creó una colección advices en la base de datos, en la cual cada documento almacena la recomendación, el objeto al cual está asociada y las condiciones para su mostrado. Las condiciones pueden ser agregadas y modificadas de la misma forma que las configuraciones, desde la vista de administrador. Sin embargo, fue preciso adicionar lógica en el servidor para que las recomendaciones sean mostradas a los usuarios que corresponde.
Desde el punto de vista del objeto al cual están asociadas, existen tres tipos de recomendaciones: asociadas a actividades (o eventos de escenario), asociadas a cartas y asociadas a escenarios. Desde el punto de vista de las condiciones que un usuario debe cumplir para que se le muestre una recomendación, éstas están asociadas a los resultados obtenidos en la encuesta Symlog: estos están dados por un puntaje obtenido en 3 dimensiones distintas. Por ello, para que los administradores puedan definir las condiciones
en las que una recomendación se muestra o no, se provee en la vista de administrador la posibilidad de especificar, para cada dimensión, que la recomendación se muestre si el valor de la encuesta del jugador activo, candidato para recibir la recomendación, es mayor, menor o igual a cierto valor. Éstos valores son los que se almacenan en la base de datos y se procesan en el servidor durante la partida. Fig. 21. Captura: Vista de administrador, pestaña Recomendaciones. El flujo seguido por el servidor para procesar las recomendaciones es el siguiente: 1. Al iniciar una partida, se cargan todas las recomendaciones almacenadas en la base
de datos.
2. Ante los eventos que pueden disparar una recomendación (una nueva actividad, un cambio de escenario o la recepción de una carta por parte de algún jugador), se busca una recomendación asociada a ese tipo de elemento de juego entre las recomendaciones cargadas.
3. Si tal cosa existe, en último término se evalúa la información que se posee sobre la encuesta de el jugador que es partícipe en dicho evento, para ver si debe o no debe dársele la recomendación.
4. Si los datos que se poseen con el jugador aprueban todas las condiciones, se muestra la recomendación al jugador. Fig. 22. UCM: Emitir una recomendación a un usuario.
Cabe destacar que la funcionalidad para editar y visualizar la información de usuarios se implementó de manera similar a la visualización de configuraciones y recomendaciones, en el sitio de administrador. Por dicha semejanza se entrará en un análisis detallado sobre ella.
4.6.2. Disponibilidad
Escenario de calidad 3: El sistema debe ser capaz de recuperarse ante una eventual falla del servidor causada por una acción de usuario o error interno; es decir, en caso de que un error haga cesar la actividad del servidor, éste debe ser capaz de volver a prestar los servicios.
● Fuente: Externa o interna
● Estímulo: Acción que genera un crash del servidor ● Entorno: En tiempo de ejecución
● Artefacto: Aplicación desarrollada
● Respuesta: El sistema debe volver a estar operacional y tratar de forma adecuada las acciones que se estaban llevando a cabo al momento de la caída.
● Medida rta: El sistema no debería tardar más de 5 segundos en recuperarse.
Respecto a la necesidad de recuperar el servidor rápidamente, se recurrió a Forever. Ésta es una herramienta de línea de comandos (CLI) que debe instalarse en el servidor; permite levantar un servidor Node que, ante una caída, se reinicia de forma automática. Su uso consiste simplemente en reemplazar el comando utilizado para levantar el servidor $ node [nombre del archivo servidor] Por otro: $ forever [nombre del archivo servidor]
Respecto a la resolución de las actividades en ejecución, la política tomada es la de detener todos las partidas en ejecución al momento de la caída y redireccionar a los usuarios hacia la página principal. Esta decisión fue tomada para mantener la coherencia existente respecto al manejo de la desconexión de los usuarios (ver apartado 3.3.1) : se ha decidido que, al desconectarse un jugador de una partida, el “personaje” de ese jugador sea eliminado de la partida; una caída del servidor, que implica la desconexión de todos los jugadores, sería interpretada como la eliminación de todos los jugadores de la partida, lo cual es una condición de derrota que finaliza la partida automáticamente.
4.6.3. Seguridad
Escenario de calidad 4: El sistema debe denegar cualquier tipo de acceso a visitantes no logueados.
● Fuente: Usuario no logueado
● Estímulo: Intento de acceder a cualquier funcionalidad de la plataforma ● Entorno: En tiempo de ejecución
● Artefacto: Aplicación desarrollada
● Respuesta: El sistema debe impedir el acceso.
● Medida rta: El sistema debe detectar la totalidad de intentos de acceso no identificado.
En vista de que la finalidad última del sistema es la recolección de datos para un análisis posterior, resulta sumamente importante que sólo los usuarios correctamente identificados puedan acceder a la plataforma; la existencia de usuarios no logueados puede llevar a la introducción en la base de datos de información vinculada a ellos (por ejemplo, a partidas en las que pueden intervenir), lo cual puede restarle mucho valor a la información capturada, pues de no ser posible vincularla con un usuario en particular, esta pierde toda utilidad.
Para implementar este aspecto, se recurrió a el agregado a la plataforma de Passport.js. Éste es un middleware de autenticación para Node que provee la funcionalidad para identificar y autenticar usuarios, pensado para trabajar con el stack de development (Node y MongoDB) que se ha empleado para el resto de la plataforma. La elección respondió, además de su simple integración con el proyecto, al soporte que posee para login con redes sociales (en particular Facebook, Twitter y Google).
A través de la integración con la plataforma y el agregado de algunas funciones en el servidor, Passport provee las herramientas para la autenticación automática con estas redes sociales.
Al loguearse un usuario por primera vez con cualquier red social soportada (Facebook, Google y Twitter), Passport gestiona el login con la red social en cuestión y desde las APIs de éstas se solicitan al usuario los permisos necesarios. Cuando el login es exitoso, Passport redirecciona a la página del juego y se crea en la base de datos un nuevo perfil de usuario, con los datos de la red social utilizada. Existe también, desde dentro del menú de perfil del usuario, la posibilidad de vincular las cuentas de otras redes sociales al perfil, de modo que si un usuario se loguea, por ejemplo, con Facebook, desde la vista de usuarios puede vincular cualquier otra de las redes sociales a su perfil para que poder loguearse con ellas la próxima vez que ingrese.
Passport también permite el agregado de condiciones ante el pedido por parte de un usuario de ser direccionado a una página, de manera tal que si un usuario no logueado intenta entrar por URL a alguna de las páginas a las que no puede tener acceso, éste se le niega.
Fig. 23. UCM: Acceso a la página por dos vías: A través del login con red social, e intento de acceso sin estar logueado.
4.6.4. Performance
Escenario de calidad 5: La performance, en tanto tiempo de respuesta a las acciones de juego realizadas por los jugadores, no debe verse comprometida por la existencia de múltiples partidas simultáneas en el servidor. ● Fuente: Usuarios ● Estímulo: Acciones de juego ● Entorno: En tiempo de ejecución ● Artefacto: Aplicación desarrollada ● Respuesta: El sistema debe brindar la respuesta correspondiente. ● Medida rta: El sistema debe brindar respuesta en menos de 2 segundos.
La respuesta rápida es vital en juegos, donde se espera que la velocidad de las respuestas sea tal que no entorpezca con su lentitud el flujo del juego.
Teniendo en cuenta que no se posee la capacidad de configurar a gusto la máquina donde correrá el servidor de juego (por falta de recursos para hacer esto), la performance que el servidor puede brindar estará, en último término, irremediablemente limitada por la capacidad de respuesta de la máquina empleada a este fin. Por ello, resulta aún más importante optimizar todo lo posible la aplicación en tanto software, buscando lograr mayor eficiencia en las respuestas.
Ésto se logra, por un lado, optimizando la forma en la que se procesan los mensajes de los usuarios en la existencia de partidas simultáneas. Es inevitable un aumento de la carga de trabajo por tener que procesar las acciones de juego de más partidas, pero existen algunos puntos claves que pueden optimizarse. Más allá de optimizaciones mínimas, pero deseables (como por ejemplo, el uso de un arreglo indexado por id para las partidas activas, que impide el acceso a cada una de ellas sin tener que iterar el contenedor), es preciso
brindar un soporte más detallado a componentes como el utilizado para la recepción y retransmisión de mensajes pertenecientes a distintas partidas.
Como ya se ha mencionado, un componente de socket.io que se aprovecha con este fin es la definición y utilización de rooms . Éstas son “habitaciones” que aíslan a grupos de usuarios de manera tal que los mensajes enviados por un miembro de una room sólo es recibido por los otros miembros de esa room. Ésto permite delegar en este componente la gestión de mensajes: el servidor no precisa chequear en qué partida está participando cada usuario, acceder a ella, obtener los jugadores que en ella participan y retransmitir los mensajes de respuesta a estos usuarios, ya que todas estas tareas se manejan reuniendo a los usuarios que participan de una misma partida en una misma room. Además, en el caso de los mensajes que son directamente retransmitidos a varios clientes, los clientes reciben sólo los mensajes que les competen, ahorrando procesamiento del lado de cliente. Teniendo en cuenta que todas las acciones de juego, mensajes y comunicación en general, tanto entre clientes como entre cliente y servidor, se llevan a cabo a través de mensajes socket.io, ésto representa una gran ventaja.
El funcionamiento de la implementación de las rooms es el siguiente: al conectarse los
clientes al “lobby”, se los agrupa en una room por defecto, donde se encuentran todos los usuarios que aún no están jugando una partida. De esta forma, pueden ver todos los cambios resultantes de los mensajes enviados por usuarios en la misma situación (creación de partidas, unión de un usuario a una partida, salida de un usuario de una partida, disolución de una partida, etc.). Los usuarios permanecen en esta room hasta que un juego al cual se han unido inicia.
Cuando la partida comienza, se crea una nueva room identificada con el mismo ID que el utilizado para identificar la partida (generado aleatoriamente) y los clientes que se habían unido son efectivamente agregados a la room. De esta forma dejan de recibir los mensajes de la room correspondiente al lobby y pierden comunicación con los usuarios de otras partidas. Ésta situación dura hasta la desconexión del usuario o hasta que finaliza la partida; al redireccionar a los usuarios al lobby, vuelven a agregarse a los usuarios a la room correspondiente a él y, la room correspondiente al juego desaparece.
Se puede visualizar este flujo a través de una reformulación de la Fig. 11 (“Asentimiento para Comenzar Partida”), con el agregado del comando por el cual el servidor coloca a los clientes en una nueva room (que se crea automáticamente).
Fig. 24. Diagrama de Secuencia de Asentimiento Para Comenzar Partidas, con el agregado del comando de servidor que une a cada cliente a una nueva room.
Con la integración en la plataforma de todos los componentes desarrollados en apartados anteriores, se da respuesta a la funcionalidad requerida por los requisitos funcionales y los escenarios de calidad para esta primera parte del trabajo.