jbarreneche / 75.74-aeropuerto Goto Github PK

Dado que un proceso inbound emite un BrokenLink que se desplaza por el anillo, este puede ser usado para eliminar (si existe) al proceso leader

Revisar robot_despacho.cpp si es correcto el orden con que se llama a
leer_elemento()
sacar_elemento()
avanzar_cinta()

Dado que en un mismo host ahora pueden coexistir varios nodos, la eleccion de lider debe ser cambiada pues esta està basada en solamente el hostname (ip) cuando deberia incluir algun otro atributo discriminatorio.

Valido para los OPEN como para los FIND como para cualquier otro mensaje.

Tambien se debe evitar que el leader rompa el anillo por un FIND que él mismo envió.

• Se debe crear un generador de puertos tcp validos
• El metodo tail debera escuchar en ese puerto aleatorio y debera incluirlo en el mensaje OPEN.
• El metodo head debera establecer la comunicacion con ese puerto (servicio).

Salvo por el primer item, ninguno de los cambios debe asumir que el puerto es un valor numerico.

Este es un extracto del logueo:

robot_carga [Info] RobotCarga(1) Intentando tomar un nuevo equipaje de cinta((null))
robot_carga [Info] RobotCarga(1) se tomo el equipaje Equipaje (3000) con escala destino '' peso=0
robot_carga [Info] Equipaje (3000) agregado al contenedor.tengo 9 equipajes, peso total 0/3000
robot_carga [Info] RobotCarga(1) pongo equipaje Equipaje (3000) en contenedor de escala ''.ya carge 9/-1074759792 equipajes
robot_carga [Info] RobotCarga(1) Intentando tomar un nuevo equipaje de cinta((null))

Como se puede ver " 9/-1074759792" no tiene sentido.

Cambiar el sistema de timeouts y mecanismo (y paquete) ISALIVE? por el sistema propio de TCP 'TCP_KEEPALIVE'.

Esto deberia ser mas robusto y menos 'intrusivo' en el codigo.

Para completar esto, tras enviar un mensaje entre nodos, se debe enviar un ACK para confirmar la transferencia

El proceso outbound NO debe sacar mensajes de su cola hasta no estar confirmado que le llego al nodo siguiente.
Idealmente deberia esperar a que el nodo destino le envie un mensaje de tipo ACK, confirmandole que pudo poner ese mensaje en la cola destino.

Para soportar esto se requiere de:

• ACK en la comunicacion entre los nodos (facil)
• Un mecanismo de logs de transacciones (al estilo base de datos) para soportar la restauracion de las colas (dificil)
• Hay que implementar un metodo poll() q retorne el primer elemento de la cola (el elemento a sacar) con la advertencia de que ese metodo NO es thread-safe (o mejor dicho, puede caer en una race conditions) (medio)

El RobotCarga saca un equipaje con rfid=0.Lo revise y nunca se pone un equipaje con ese rfid en la cinta creo que se esta creando con el constructor por default en:

CintaCarga.h

template
T CintaCarga::sacar_equipaje(int id_consumidor) {
T elemento;
bool extrajo = false;

while (!extrajo) {...

Log:

robot_carga: RobotCarga(1) Intentando tomar un nuevo equipaje de cinta((null))
robot_carga: [Info] RobotCarga(1) se tomo el equipaje Equipaje (0) con escala destino '' peso=0
robot_carga: [Info] Equipaje (0) agregado al contenedor.tengo 4 equipajes, peso total 0/3000

El proceso inbound puede desbloquears por timeout y enviar un mensaje LOOP de subtipo CheckOutputLink al proceso outbound.
Este podra desbloquearse y desencolar el mensjae, para luego enviarlo y si asi lo logra, verificar que su link sigue activo.

Se debera incluir ademas un ACK de parte del inbound del otro nodo para garantizar que sigue activo realmente

• Un nuevo proceso llamado 'beacon_service' debe escuchar en un puerto (service) udp bien definido (constante) e interceptar los mensajes OPEN.
• Los mensajes interceptados deben ser puestos en una cola (reenviados a los sockets en los que los otros procesos estan escuchando)
• El metodo head, en vez de escuchar y recibir de un puerto udp, debera recibir el mensaje de este socket cuyo puerto es elegido dinamicamente.
• El mensaje extraido del socket debe contener exactamente el mismo contenido del paquete interceptado por el proceso beacon, ademas de la direccion del peer quien envio el mensaje (para debugging)

Nota: Los id de los grupos deben ser numero mayores o iguales a 0.

• Por ello, chequeo en los procesos inbound, outbound y leader deben ser agregados.

Basado en la implementacion de #15 , el proceso beacon service debe ser extendido, recibiendo los beacon FIND

• Actualmente, leader escucha en un puerto distinto al puerto usado por los OPEN, pero con la administracion de mensajes por beacon_service, esto puede cambiarse, haciendo que leader envie los FIND al mismo puerto que son enviados los OPEN
• Al igual que en el metodo head del ticket #15 , leader debe extraer mensajes de un socket dinamico.

fuera de scope

• Ahora el leader puede escuchar no solo los mensajes FIND sino tambien los OPEN permitiendole romper el anillo para aceptar al nuevo nodo (quien hace el OPEN) mucho antes de que este nodo forme su propio anillo y su propio leader.
• Ahora el metodo head puede escuchar no solo mensajes OPEN sino mensajes FIND, haciendo que entonces nunca se cierre el anillo consigo mismo (deberia esperar a que el anillo que emitio el FIND se rompa)

Nota: los ultimos 2 items hacen referencia a cambios en el joineo de nodos. Deben ser vistos con mas detenimiento.

Si dos nodos se conectan formando un anillo y eligiendo un lider, para luego hacer un SIGINT sobre el nodo lider, se espera que el otro nodo logre recuperarse y volver a reconstruir el anillo (con él como unico integrante)

Lo que sucede es que el proceso outbound se queda esperando algun mensaje en su cola. La solucion seria que el proceso inbound, quien detecta la desconeccion, envie un mensaje LOOP de tipo 'brokenlink' forzando a todos los nodos a chequear sus conecciones.

Esto esta implementado pero no parece funcionar.

Actualmente los recursos obtenidos por las clases en IPC son liberados pero las excepciones generadass por estas terminan impactando en el core de C de Python haciendo que el proceso mismo crashee.

Se debera atrapar las excepciones de C++ y wrappearlass a excepciones de Python para que el sistema sea estable.

Excepcion:

robot_carga: [Crit] The semaphore number 1 in the set (with the key 705e02b generated from '/tmp/carpeta_keys_ftok/cinta_contenedor.lck' and with the permissions 0) cannot be decremented (wait) [code 27]: File too large#012???#12???#12???#12
ApiCarga::sacar_equipaje#012CintaCarga::sacar_equipaje(in#012SemaphoreSet::wait_on(in#012SemaphoreSet::op(int, boo#012OSError::OSError(char const*, .

Posiblemente tenga que ver con los id's y path's de la nueva cinta.

En el commit a15378c, la compilacion falla:

En el modulo 'api':
Compiling api_control_equipajes.cpp
api_control_equipajes.cpp: En el constructor ‘ApiControlEquipajes::ApiControlEquipajes(const char_, int, int, bool)’:
api_control_equipajes.cpp:7:1: error: _se define el parámetro ‘create’ pero no se usa [-Werror=unused-but-set-parameter]*
cc1plus: all warnings being treated as errors

En el modulo 'processes':
Compiling puesto_checkin.cpp
puesto_checkin.cpp: En la función ‘int main(int, char**)’:
puesto_checkin.cpp:37:131: error: conversión obsoleta de una constante de cadena a ‘char’ [-Werror=write-strings]*
cc1plus: all warnings being treated as errors

Compiling robot_intercargo.cpp
robot_intercargo.cpp: En la función ‘int main(int, char**)’:
robot_intercargo.cpp:51:6: error: se define la variable ‘zona_asignada’ pero no se usa [-Werror=unused-but-set-variable]
cc1plus: all warnings being treated as errors

Cuando el anillo se completa, y el lider es elegido, un nuevo procesos "leader.py" debe ser spawneado encargandose de

• la fusion con otros grupos
• detectar y tomar acciones al descubrir que su propio anillo fue roto.

Tanto el nombre como el id del proceso es mostrado en la cabecera del cada mensaje en el log de forma automatica(*) por lo que no es necesario que cada mensaje a loguear incluya como parte de este el nombre y/o id de proceso.
Para evitar inconsistencias y posibles errores, se debe remover esos nombres y ids.

(*) es automatico siempre que quien spawnee un procesos le pase como primer argumento (argv[0]) el nombre seguido del numero de proceso, como lo hace main.cpp.