-
Notifications
You must be signed in to change notification settings - Fork 2
Formato de los mensajes en el anillo
Los mensajes intercambiados entre nodos difieren si el anillo esta o no construido.
Se llamará en este documento capa de mensajeria el sistema que se encarga de la comunicacion entre los nodos que forman el anillo, comunicandose con las capas de mensajerias en los otros nodos.
Se llamará capa de apliacion o capa de usuario a la aplicacion que interactua con la capa de mensajeria enviando y recibiendo mensajes con ella, abstrayendo a la capa de aplicacion de los detalles de comunicacion.
En este documente se hablara sobre los mensajes entre las capas de mensajerias (entre nodos).
Se representaran graficamente cada mensaje, o parte de él, con una linea por cada byte, numerando los bits de cada byte desde 7 hasta 0, siendo el bit numero 7, del primer byte, el primer bit enviado o recibido. A la derecha se titula cada campo que forma el mensaje. Los limites horizontales representan los limites entre campos para poder representar campos que ocupan mas de un byte. Si algun campo ocupa menos de un byte (flags), cada bit ocupado es separado por barras verticales |. Si algun campo ocupa una cantidad indefinida de bytes (tipicamente un payload) o una cantidad definida pero excesiva para ser representada graficamente, el campo sera representado por 2 o 3 bytes, separados por una linea punteada. Las lineas horizontales dobles marcan el principio y el fin del mensaje.
Como ejemplo:
7 6 5 4 3 2 1 0
+===============+
0 | | Primer byte, primer campo
+---------------+
1 | |
+- -+ Dos bytes mas, segundo campo
2 | |
+---------------+
3 | | | | Byte con 3 campos (flags) en los bits 7, 6-3 y 2-0
+---------------+
4 | | Cuatro bytes, (bytes 4-7)
. . . . . . . que forman un unico campo
7 | |
+===============+
Se asume que la interpretacion de byte es un stream continuo de 8 bits, y que todo mensaje tiene un numero completo de bytes, esto es, una cantidad multiplo de 8 bits. Salvo que se indique lo contrario, los campos numericos deben interpretarse sin signo y un big endian order. A su vez, aquellos campos que representen longitudes de payloads, se deben interpretar que representan la longitud en cantidad de bytes del payload en cuestion.
En esta seccion se detallan los mensajes entre dos nodos consecutivos, conectados entre si, en una anillo construido. Cada nodo, por pertenecer a un anillo, se comunica hacia un nodo y desde otro nodo. Solo nos enfocaremos en una de esas conecciones, en donde interactuan solo dos nodos.
Ellos juegan roles distintos a los efectos de esta descripcion. Uno de ellos es quien tipicamente envia los mensajes, el nodo emisor. El otro nodo es quien tipicamente recibe los mensajes, el nodo receptor. Se habla de enviar o recibir tipicamente por que en ciertos casos, que se detallan en secciones posteriores, es el nodo emisor quien recibe un mensaje y es el nodo receptor quien lo envia.
Todos los mensajes que van desde el emisor al receptor tiene una estructura comun, es el payload que varia de acuerdo al tipo particular.
7 6 5 4 3 2 1 0
+===============+
0 | | Tipo
. . . . . . .
3 | |
+---------------+
4 | |
+- -+ Longitud del payload
5 | |
+---------------+
6 | | Payload
. . . . . . .
n | |
+===============+
La longitud del payload es un entero sin signo de 2 bytes, en big-endian order. El tipo de mensaje es un codigo para discriminar la clase de mensajes.
El unicos tipos implementados son
- LOOP para mensajes de coordinacion entre nodos sin pasar el mensaje a la capa de aplicacion.
- USER para mensajes que seran entregados a la capa de aplicacion.
Los mensajes USER no tienen ninguna estructura adicional a la presentada en el diagrama anterior (no hay mas campos que los mostrados). El mensaje de la capa superior esta contenido enteramente en el payload. Sin embargo, el valor del campo longitud esta restringido a valores no-negativos menores a 2^14 por cuestiones internas de implementacion con la comunicacion entre la capa de mensajeria y la capa de aplicacion del usuario.
Los mensajes LOOP son mensajes recibidos, procesados internamente por la capa de mensajeria, y si es requerido, enviado al siguiente nodo. En ningun caso el mensaje es pasado o recibido desde la capa de aplicacion.
En el caso de los mensajes LOOP, los primeros dos bytes del payload mencionado anteriormente juegan un papel especial para evitar que los mensajes de LOOP recorran el anillo indefinidamente, implementando para ello un time to live.
El siguiente byte corresponden a un discriminante del subtipo de mensaje LOOP. Este es el payload mostrado anteriormente, con la interpretacion que se le da a un mensaje LOOP.
5 | |
+---------------+
6 | | Time To Live
+- -+
7 | |
+---------------+
8 | | Discriminante (Subtipo de LOOP)
+---------------+
9 | | Payload del mensaje LOOP
. . . . . . .
n | |
+===============+
Actualmente se definieron 3 mensajes para la comunicacion y coordinacion entre nodos sin que la capas superiores deban conocer los detalles de la capa de mensajeria
Este mensaje es enviado por cada nodo para proponerse como lider del anillo tanto durante la construccion del anillo como de forma periodica para negociar reelecciones.
7 | |
+---------------+
8 | 0 | Discriminante con valor igual a 0
+---------------+
9 | | Longitud del nombre del nodo propuesto como lider
+---------------+
10 | | Nombre del nodo propuesto como lider
. . . . . . .
n | |
+===============+
Este mensaje es enviado por un nodo cuando detecta que el canal de comunicacion con el siguiente nodo ha sido cerrada o bien tiene un comportamiento erratico como perdida de mensajes o tiempos de respuesta excesivamente grandes lo que evidencia que el nodo en cuestion pudo haber sido desconectado, el link de la capas inferiores esta caido o incluso la red fue partida.
7 | |
+---------------+
8 | 1 | Discriminante con valor igual a 1
+---------------+
9 | | Longitud del nombre del nodo que detecto el problema.
+---------------+
10 | | Nombre del nodo ue detecto el problema.
. . . . . . .
n | |
+===============+
Este mensaje es enviado por un nodo para forzar un cierre en la conecciones y reiniciar el proceso de construccion del anillo, posibilitando el ingreso de nuevos nodos a este.
7 | |
+---------------+
8 | 2 | Discriminante con valor igual a 2
+===============+
Cuando un nodo le envia un mensaje a otro, el receptor le responde con un mensaje ACK
7 6 5 4 3 2 1 0
+===============+
0 | A | ACK
+===============+
El campo ACK es un caracter ASCII con la letra 'A'.
Los mensajes de un anillo en construccion estan destinados no a un nodo particular sino a cualquier nodo que este en la misma LAN (broadcast)
Debe entenderse que un anillo nunca esta del todo construido. Aun cuando todos sus nodos tengan sus conecciones establecidas y el anillo está operacional, el nodo leader buscará nuevos miembros, nodos que desean unirse al anillo por lo que el concepto de anillo construido es solo un concepto temporal pues no hay manera de saber cuantos nodos desean formar parte a priori.
Es emitido por cada nodo en busqueda de otros nodos queriendo formar el anillo. El mismo mensaje es usado por un nodo al querer formar parte de un anillo ya creado, pues desde el punto de vista de ese nodo, no hay diferencia entre enlazarse con otros nodos esten, o no formando un anillo previo.
7 6 5 4 3 2 1 0
+===============+
0 | | Tipo de operacion (create_queue, destroy_queue, push, pull)
+---------------+
3 | |
. . . . . . . sender_name (255 bytes)
4 | |
+---------------+
5 | |
. . . . . . . queue_id (255 bytes)
6 | |
+---------------+
7 | |
. . . . . . . message_size (4 bytes)
8 | |
+---------------+
9 | |
. . . . . . .
n | |
+---------------+
n+1 | | Identificacion del nodo emisor
. . . . . . .
n+m | |
+---------------+
n+m+1 | | Identificacion del servicio del nodo emisor
. . . . . . .
n+m+l | |
+===============+
Donde el campo Tipo es la constante OPEN. El ID del grupo es un numero que representa el nombre del anillo de nodos que se quiere armar, o al cual un nodo se quiere unir. El protocolo de comunicacion permite en una misma LAN varios grupos de nodos, cada uno formando un anillo distinto y completamente separado.
Actualmente se soportan dos tipos de identificaciones:
- IP, identificaciones de nodos por direccion IP.
- FQDN, identificaciones de nodos por fully qualified domain name (solo si la infraestructura en la que se soporta los procesos de anillo puede resolver los hostnames a IP, tal como lo hace una infraestructura de DNS).
Los ultimos tres campos, son respectivamente las identificaciones del nodo lider (del anillo), del emisor (quien envia este mensaje) y del nombre del servicio (puerto TCP) en el que el emisor espera la coneccion.
Es emitido por el nodo leader de cada anillo en busqueda de otros anillos formados pero que por alguna razon no formaron un unico anillo. Esto puede deberse a que un nodo no estaba activo durante la construccion del primer anillo. U originalmente un unico anillo se partio en dos debido a una particion en la red.
7 6 5 4 3 2 1 0
+===============+
0 | | Tipo
. . . . . . .
3 | |
+---------------+
4 | |
+- -+ Id del grupo
5 | |
+---------------+
6 | | Longitud (n) de la identificacion del nodo lider
+---------------+
7 | | Identificacion del nodo lider
. . . . . . .
n | |
+===============+
Donde el campo Tipo es la constante FIND. El resto de los campos tienen el mismo significado que el descripto en el mensaje OPEN