Processus de réponse du client au serveur

La connexion effectuée, le serveur envoie le message SC_REPLY sur la connexion TCP ouverte que le client a utilisée pour lui transmettre sa requête de connexion. Le client ferme ensuite la connexion. Le client doit conserver la connexion TCP ouverte jusqu'à ce que le serveur lui transmette le message SC_REPLY.

Par exemple, le client :

1. Ouvre une connexion TCP sur le serveur.

2. Attend que la connexion devienne «modifiable».

3. Envoie un message SC_CALLBACK_REG (contenant un message ADD_CLIENT).

4. Attend de recevoir un message SC_REPLY.

5. Reçoit un message SC_REPLY.

6. Reçoit un message stipulant que le serveur a fermé la connexion (lecture de 0 octet du socket).

7. Ferme la connexion.

1. Ouvre une connexion TCP sur le serveur.

2. Attend que la connexion devienne «inscriptible ».

3. Envoie un message SC_CALLBACK_REG (contenant un message REMOVE_CLIENT).

4. Attend de recevoir un message SC_REPLY.

5. Reçoit un message SC_REPLY.

6. Reçoit un message stipulant que le serveur a fermé la connexion (lecture de 0 octet du socket).

7. Ferme la connexion.

Chaque fois que le serveur reçoit un message SC_CALLBACK_REG d'un client, le serveur transmet un message SC_REPLY sur la même connexion ouverte indiquant si l'opération a réussi ou échoué. DTD XML SC_REPLY contient la DTD XML d'un message SC_REPLY, ainsi que les messages d'erreur éventuels que ce message peut contenir.

Contenu d'un message SC_REPLY

Un message SC_REPLY indique si une opération a réussi ou échoué. Il contient la version du message de protocole CRNP, un code d'état et un message d'état décrivant le code d'état de façon détaillée. Le tableau suivant présente les valeurs possibles du code d'état :

Processus de gestion des conditions d'erreur par un client

Dans des conditions normales, un client envoyant un message SC_CALLBACK_REG reçoit une réponse précisant si la connexion a réussi ou échoué.

Pourtant, le serveur peut être confronté à une condition d'erreur l'empêchant de retransmettre le message SC_REPLY au client. Le cas échéant, la connexion a pu réussir avant que la condition d'erreur ne se produise, échouer ou tout simplement ne pas avoir encore été traitée.

Comme le serveur doit être exécuté sur le cluster en tant que serveur de basculement ou hautement disponible, cette condition d'erreur ne signifie pas que le service est interrompu. De fait, le serveur est rapidement en mesure d'envoyer des événements au client nouvellement connecté.

Pour pallier ces conditions, le client doit :

• Imposer un délai d'attente au niveau de l'application pour une connexion d'enregistrement en attente de la réception d'un message SC_REPLY, délai après lequel il doit retenter de se connecter.

• Commencer à écouter son adresse IP de rappel et son numéro de port en vue de recevoir des notifications d'événement avant d'être connecté pour la notification de rappel d'événement. Le client doit attendre de recevoir un message de confirmation de connexion et de notification d'événement en parallèle. S'il commence à recevoir des notifications d'événement avant de recevoir un message de confirmation, il doit fermer la connexion d'enregistrement.