Caracas, 6 de Enero de 2014 Universidad Católica Andrés Bello Escuela de Ingeniería Informática Sistemas Distribuidos Prof. Wílmer Pereira Proyecto 2 (20%) Tolerancia a Fallas y Replicación en Anillo y Servidor Central Partiendo de la misma aplicación de envío de paquetes con un transporte en anillo, se desea fortalecer la infraestructura de simulación para que sea tolerantes a fallas. Además se debe incluir el manejo de ciertos errores que no fueron considerados en la primera entrega: Debe existir al menos dos réplicas del servidor central de estadísticas. En caso de caída del servidor activo se elige el reemplazante mediante el algoritmo de elección del grandulón. En caso de reactivarse el(los) caído(s) debe comenzar el período de elección del servidor de estadísticas. Puede haber caídas de sucursales en cuyo caso debe restituirse el anillo. Deben definir los medios de los que se valen las sucursales para reconstruir la conectividad. Un caso especial a considerar es cuando la sucursal caída contenía el transporte. Deben tener algún algoritmo de su elección para activar de nuevo el transporte. Los mensajes pueden catalogarse de perdidos (llamada de método fallida) básicamente por tres razones: caída del receptor, rompimiento del enlace o gran retraso en la conexión. Las políticas clásicas para paliar estos errores son: número de secuencia en los mensajes, tiempos de espera de las respuestas y máximo número de intentos de reenvíos. Debe implementar, lo que sea necesario, que se acerque a estas políticas, sobre todo en las comunicaciones contra el servidor de estadísticas. Así que en algunos casos será muy importante el uso de los try/catch y definir sus propias excepciones. Con respecto a los errores posibles, las listas de envío y recepción de paquetes pueden eventualmente llenarse. Tener la de envío llena implica pérdida de paquetes generados por la sucursal. Tener la de recepción llena tiene otras consecuencias. Deben generar los mensajes adecuados al servidor de estadísticas y contabilizarlos para al final de la corrida dar un reporte de errores por sucursal ligados a las dos listas. También el transporte lleno genera algunos errores que se deben contabilizar y pueden ser consultados desde el servidor de estadísticas. Agregue los casos de errores necesarios que deben ser sumarizados en el servidor de estadísticas. Las condiciones de corrida deben ser definidas por Uds. sin embargo algunos lineamientos son: La replicación no debe hacerse sobre máquinas virtuales La cónsola de cada sucursal debe ahora ofrecer la posibilidad de consultar los errores que implican las listas llenas y mensajes perdidos o llamadas de métodos fallidas. En el servidor de estadísticas debe incluir consultas por caídas de sucursales, desaparición del transporte, mensajes perdidos al servidor de estadísticas, … seguramente hay otros errores que Ud. puede agregar y debe descubrir mientras realiza su aplicación. El informe debe contener decisiones que tomó en el diseño, en particular, que excepciones definieron, algoritmo de recuperación del trasporte, como restituyeron la conectividad del anillo, manejo de errores (cuales incluyeron y que se contabiliza en el servidor de estadísticas) y los diagramas de secuencia ahora considerando el manejo de errores y tolerancia a fallas. Por supuesto cualquier otra consideración de diseño o error que incluyan adicional no duden en mencionarla en su informe. Errores adicionales que tomen en cuenta serán dadas como puntos adicionales en la corrección del proyecto. Pueden usar el código de otro grupo y deben notificar por correo cual seleccionarán. La corrección es presencial y se interrogará a ambos miembros del grupo. La entrega será la última semana del semestre.