Cómo envía eventos el servidor al cliente

A medida que los eventos se generan en el clúster, el servidor de CRNP los envía a cada cliente que ha solicitado estos tipos de eventos. El envío consiste en dirigir un mensaje SC_EVENT a la dirección de rellamada del cliente. El envío de cada evento se produce en una conexión TCP nueva.

Inmediatamente después de que un cliente se registre para un tipo de evento, a través de un mensaje SC_CALLBACK_REG que contenga un mensaje ADD_CLIENT o ADD_EVENT, el servidor enviará el evento más reciente de ese tipo al cliente. El cliente puede determinar el estado actual del sistema desde el que provienen los eventos siguientes.

Cuando el servidor inicie una conexión TCP con el cliente, enviará exactamente un mensaje SC_EVENT por la conexión. El servidor emite un proceso de cierre de dúplex completo.

Por ejemplo, el cliente realiza las siguientes acciones:

1. Espera que el servidor inicie una conexión TCP

2. Acepta la conexión entrante del servidor

3. Espera la recepción de un mensaje SC_EVENT desde el servidor

4. Lee un mensaje SC_EVENT del servidor

5. Recibe un indicador de que el servidor ha cerrado la conexión (lee 0 bytes del socket)

6. Cierra la conexión

Cuando todos los clientes estén registrados, deberán recibir en todas sus direcciones de rellamada (dirección IP y número de puerto) en todo momento, por si hubiera una conexión entrante para el envío de un evento.

Si el servidor no logra contactar con el cliente para enviarle un evento, vuelve a intentar enviarlo un cierto número de veces, en el intervalo que se defina. Si los intentos fallan, el cliente es eliminado de la lista de clientes del servidor. El cliente debe también volver a registrarse mediante el envío de un mensaje SC_CALLBACK_REG que contenga a su vez un mensaje ADD_CLIENT antes de poder recibir más eventos.

Cómo se garantiza el envío de eventos

La generación de eventos se realiza de forma completamente ordenada en el clúster; este orden se mantiene a la hora de realizar el envío a cada cliente. En otras palabras, si el evento A se genera en el clúster antes que el evento B, el cliente recibe el evento A antes de recibir el evento B. Sin embargo, no se mantiene el orden completo de envío de eventos a todos los clientes. Es decir, el cliente Y podría recibir los eventos A y B antes de que el cliente X recibiera el evento A. Así, los clientes más lentos no retrasan el envío a los demás clientes.

Todos los eventos que envía el servidor (salvo el primero de una subclase y los eventos que siguen a los errores de servidor) se producen como respuesta a eventos reales generados por el clúster, salvo que el servidor sufra un error que haga que pierda eventos generados por el clúster. En ese caso, el servidor genera un evento para cada tipo de evento que representa el estado actual del sistema para ese tipo. Cada evento se envía a los clientes que registraron su interés en ese tipo de evento.

El envío de eventos sigue la semántica de “una vez como mínimo”. Es decir, el servidor puede enviar el mismo evento a un cliente en más de una ocasión. Esta concesión es necesaria en aquellos casos en los que el servidor permanece inactivo temporalmente y, al reanudar su actividad, no puede determinar si el cliente ha recibido o no la información más reciente.

Contenido de un mensaje SC_EVENT

El mensaje SC_EVENT contiene el mensaje real generado en el clúster y convertido para adaptarlo al formato de mensaje de XML SC_EVENT. La tabla siguiente describe los tipos de evento que envía CRNP, incluidos los pares nombre-valor, editor y fabricante.

Las posiciones de los elementos de la matriz de state_list están sincronizadas con las de node_list. Es decir, el estado del nodo que aparece en primer lugar en la matriz de node_list aparece también en la posición inicial en la matriz de state_list.

Otros nombres que empiezan por ev_ y sus valores asociados pueden estar también presentes, pero no son para el uso del cliente.