Una vez procesado el registro, el servidor que ha recibido la solicitud de registro envía un mensaje SC_REPLY mediante la conexión TCP que el cliente ha abierto. El servidor 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:
Abre una conexión TCP al servidor
Espera que la conexión se pueda “escribir”
Envía un mensaje SC_CALLBACK_REG (que contiene un mensaje ADD_CLIENT)
Espera la recepción de un mensaje SC_REPLY desde el servidor
Recibe un mensaje SC_REPLY desde el servidor
Recibe un indicador de que el servidor ha cerrado la conexión (lee 0 bytes del socket)
Cierra la conexión
Más tarde, el cliente lleva a cabo las siguientes acciones:
Abre una conexión TCP al servidor
Espera que la conexión se pueda “escribir”
Envía un mensaje SC_CALLBACK_REG (que contiene un mensaje REMOVE_CLIENT)
Espera la recepción de un mensaje SC_REPLY desde el servidor
Recibe un mensaje SC_REPLY desde el servidor
Recibe un indicador de que el servidor ha cerrado la conexión (lee 0 bytes del socket)
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. DTD de XML de SC_REPLY contiene la definición de tipo de documento XML de un mensaje SC_REPLY y los posibles mensajes de error incluidos en el mismo.
Un mensaje SC_REPLY indica si una operación se ha realizado con éxito o si, por el contrario, ha presentado errores. Este mensaje contiene la versión del mensaje de CRNP, un código de estado y un mensaje de estado que describe de forma más detallada el código de estado. La tabla siguiente describe los valores posibles del código de estado.
Código de estado |
Descripción |
---|---|
OK |
El mensaje se ha procesado satisfactoriamente. |
RETRY |
El servidor ha rechazado el registro del cliente debido a un error transitorio. El cliente debería registrarse de nuevo con argumentos diferentes. |
LOW_RESOURCE |
Hay un nivel bajo de recursos del clúster, por lo que el cliente debe intentarlo de nuevo más adelante. El administrador del clúster puede aumentar también los recursos del mismo. |
SYSTEM_ERROR |
Se ha producido un error grave. Póngase en contacto con el administrador del clúster. |
FAIL |
La autorización ha fallado o se ha producido otro problema que ha provocado el fallo de registro. |
MALFORMED |
La solicitud XML tenía un formato erróneo y no se ha podido analizar. |
INVALID |
La solicitud XML no era válida, es decir, no cumplía con la especificación XML. |
VERSION_TOO_HIGH |
La versión del mensaje era demasiado elevada para procesar satisfactoriamente el mensaje. |
VERSION_TOO_LOW |
La versión del mensaje era demasiado baja para procesarlo satisfactoriamente. |
En condiciones normales, el cliente que envía un mensaje SC_CALLBACK_REG recibe una respuesta en la que se indica si el registro se ha realizado con éxito o no.
Sin embargo, el servidor puede experimentar una condición de red durante el registro de un cliente que le impida enviar un mensaje SC_REPLY a éste. 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.
Como el servidor debe funcionar como tipo de recurso de recuperación antes fallos o como servidor del clúster, con alta disponibilidad, esta condición de error no implica la finalización del servicio. De hecho, es posible que el servidor pueda empezar muy pronto a enviar eventos al cliente recién registrado.
Para solucionar estas condiciones, el cliente debe realizar las siguientes acciones:
Imponer un tiempo de espera, a nivel de la aplicación, para la conexión de registro que espera la recepción del mensaje SC_REPLY. Una vez transcurrido este tiempo, el cliente debe intentar de nuevo efectuar el proceso de 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.