Cómo envía eventos el servidor al cliente
Dado que los eventos se generan dentro del clúster, el servidor CRNP los envía a todos los clientes que solicitaron eventos de este tipo. 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. Éste podrá así descubrir el estado actual del sistema desde el que se le enviarán los siguientes eventos.
Cuando el servidor inicie una conexión TCP con el cliente, enviará exactamente un mensaje SC_EVENT por la conexión. El servidor después enviará un cierre full-duplex.
Por ejemplo, el cliente realiza las siguientes acciones:
-
Espera que el servidor inicie una conexión TCP
-
Acepta la conexión entrante del servidor
-
Espera un mensaje SC_EVENT
-
Lee un mensaje SC_EVENT
-
Recibe un indicador de que el servidor ha cerrado la conexión (lee 0 bytes del zócalo)
-
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 también debe volver a registrarse mediante el envío de otro mensaje SC_CALLBACK_REG que contenga un mensaje ADD_CLIENT antes de que el cliente pueda recibir más eventos.
Cómo se garantiza el envío de eventos
Hay un orden total de generación de eventos dentro del clúster, que se mantiene en el orden de 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 X recibe el evento A antes que el B. Sin embargo, el orden total de envío de eventos a todos los clientes no se mantiene. 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 más de una vez. Este margen es necesario en los casos en los que el servidor se desconecta temporalmente y, cuando se vuelve a conectar, no puede determinar si el cliente ha recibido la última información.
Contenido de un mensaje SC_EVENT
El mensaje SC_EVENT contiene el mensaje real generado en el clúster, traducido para encajar en el formato de mensaje XML SC_EVENT. La tabla siguiente describe los tipos de evento que envía CRNP, incluidos los pares nombre-valor, editor y fabricante.
|
Clase y subclase |
Editor y fabricante |
Pares nombre-valor |
Notas |
|---|---|---|---|
|
EC_Cluster ESC_cluster_membership |
Editor: rgm Fabricante: SUNW |
Nombre: node_list Tipo de valor: matriz de cadenas Nombre: state_list Tipo de valor: matriz de cadenas |
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 listado en primer lugar en la matriz node_list es el primero en la matriz state_list. state_list contiene sólo números representados en ASCII, cada uno de los cuales representa el número que encarna actualmente ese nodo en el clúster. Si el número es el mismo que el recibido en un mensaje anterior, el nodo no ha modificado su relación con el clúster (se ha ido, se ha unido o se ha vuelto a unir). Si el número de representación es –1, el nodo no es miembro del clúster. Si el número de representación es un número positivo, el nodo es miembro del clúster. Otros nombres que empiezan por ev_ y sus valores asociados pueden estar también presentes, pero no son para el uso del cliente. |
|
EC_Cluster ESC_cluster_rg_state |
Editor: rgm Fabricante: SUNW |
Nombre: rg_name Tipo de valor: cadena Nombre: node_list Tipo de valor: matriz de cadenas Nombre: state_list Tipo de valor: matriz de cadenas |
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 listado en primer lugar en la matriz node_list es el primero en la matriz state_list. state_list contiene representaciones de cadena del estado del grupo de recursos. Los valores válidos son los que se pueden recuperar con las órdenes scha_cmds(1HA). Otros nombres que empiezan por ev_ y sus valores asociados pueden estar también presentes, pero no son para el uso del cliente. |
|
EC_Cluster ESC_cluster_r_state |
Editor: rgm Fabricante: SUNW |
Tres necesarios, como sigue: Nombre: r_name Tipo de valor: cadena Nombre: node_list Tipo de valor: matriz de cadenas Nombre: state_list Tipo de valor: matriz de cadenas |
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 se lista en primer lugar en la matriz node_list es el primero en la matriz state_list. state_list contiene representaciones de cadenas del estado del recurso. Los valores válidos son los que se pueden recuperar con las órdenes scha_cmds(1HA). Otros nombres que empiezan por ev_ y sus valores asociados pueden estar también presentes, pero no son para el uso del cliente. |
- © 2010, Oracle Corporation and/or its affiliates