Proyecto 2 (20%)

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.