Cómo responde el servidor a un cliente

Después de procesar el registro, el servidor envía el mensaje SC_REPLY sólo en la conexión TCP abierta desde el cliente en el que el servidor ha recibido la solicitud de registro; a continuación cierra la conexión. El cliente debe mantener abierta la conexión TCP hasta que reciba el mensaje SC_REPLY del servidor.

Por ejemplo, el cliente realiza las siguientes acciones:

1. Abre una conexión TCP al servidor

2. Espera que la conexión se pueda “escribir”

3. Envía un mensaje SC_CALLBACK_REG (que contiene un mensaje ADD_CLIENT)

4. Espera un mensaje SC_REPLY

5. Recibe un mensaje SC_REPLY

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

7. Cierra la conexión

1. Abre una conexión TCP al servidor

2. Espera que la conexión se pueda “escribir”

3. Envía un mensaje SC_CALLBACK_REG (que contiene un mensaje REMOVE_CLIENT)

4. Espera un mensaje SC_REPLY

5. Recibe un mensaje SC_REPLY

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

7. Cierra la conexión

Cada vez que el servidor recibe un mensaje SC_CALLBACK_REG de un cliente, le envía un mensaje SC_REPLY en la misma conexión abierta. Este mensaje especifica si la operación se ha realizado de modo satisfactorio o no. En DTD de XML de SC_REPLY se explica la definición de tipo de documento XML de un mensaje SC_REPLY y los posibles mensajes de error que pueda contener.

Contenido de un mensaje SC_REPLY

Un mensaje SC_REPLY especifica si la operación se ha realizado de modo satisfactorio o no. Este mensaje contiene la versión del mensaje del protocolo CRNP, un código y un mensaje de estado que describe con más detalle el código de estado. La tabla siguiente describe los valores posibles del código de estado.

Cómo debe resolver el cliente las condiciones de error

En condiciones normales, un cliente que envía un mensaje SC_CALLBACK_REG recibe una respuesta que indica que el registro ha sido satisfactorio o no.

Sin embargo, el servidor puede experimentar una condición de error, durante el registro de un cliente, que le impida enviarle un mensaje SC_REPLY de vuelta. En este caso, el registro se podría haber realizado satisfactoriamente antes de que se produjera la condición de error, podría haber fallado o podría no haber sido procesado.

Dado que el servidor debe funcionar como un servidor de tipo a prueba de fallos o de alta disponibilidad en el clúster, esta condición de error no supondrá el fin del servicio. De hecho, es posible que el servidor pueda empezar muy pronto a enviar eventos al cliente recién registrado.

Para remediar estas condiciones, el cliente debería:

• Imponer un tiempo de espera de nivel de aplicación en una conexión de registro que esté esperando un mensaje SC_REPLY, pasado el cual el cliente deberá volver a intentar el registro.

• Empezar a recibir en su número de puerto y dirección IP de rellamada por si hubiera recepción de eventos antes de registrar las rellamadas de eventos. El cliente debería esperar a recibir un mensaje de confirmación de registro y los envíos de eventos paralelamente. Si el cliente empieza a recibir eventos antes de recibir un mensaje de confirmación, debería cerrar discretamente la conexión de registro.