Processus de notification d'événement au client par le serveur

Comme les événements sont générés dans le cluster, le serveur CRNP les notifie à tous les clients qui se sont connectés pour recevoir les notifications de ce type. La notification se concrétise par l'envoi d'un message SC_EVENT à l'adresse de rappel des clients. Chaque notification d'événement utilise une nouvelle connexion TCP.

Juste après qu'un client se soit connecté pour être notifié d'un type d'événements à l'aide d'un message SC_CALLBACK_REG contenant un message ADD_CLIENT ou ADD_EVENT, le serveur lui transmet le dernier événement de ce type. Le client est ainsi informé de l'état actuel du système dont seront issus les événements ultérieurs.

Lorsque le serveur ouvre une connexion TCP sur le client, il envoie exactement un message SC_EVENT sur la connexion. Il procède ensuite à une fermeture bidirectionnelle.

Par exemple, le client :

1. Attend que le serveur initie une connexion TCP.

2. Accepte la connexion entrante du serveur.

3. Attend de recevoir un message SC_EVENT.

4. Lit un message SC_EVENT.

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

6. Ferme la connexion.

Une fois tous les clients connectés, ils doivent écouter leur adresse de rappel (adresse IP et numéro de port) en permanence en vue d'une connexion entrante de notification d'événement.

Si le serveur ne parvient pas à contacter le client pour lui notifier un événement, il réessaie suivant l'intervalle et le nombre de fois que vous avez spécifié. Si toutes les tentatives échouent, le client est supprimé de la liste des clients du serveur. Il doit alors se reconnecter en envoyant un autre message SC_CALLBACK_REG contenant un message ADD_CLIENT avant de pouvoir recevoir d'autres notifications d'événement.

Mécanisme garantissant la notification des événements

Au sein du cluster, un ordre de génération des événements est préservé afin de notifier chaque client. En d'autres termes, si l'événement A est généré sur le cluster avant l'événement B, le client X reçoit l'événement A avant l'événement B. Par contre, l'ordre de notification des événements à tous les clients n'est pas préservé. Cela signifie que le client Y peut recevoir les événements A et B avant que le client X ne soit notifié de l'événement A. De cette façon, les clients dont la connexion est lente ne retardent pas la notification à tous les clients.

Tous les événements notifiés par le serveur (à l'exception du premier événement d'une sous-classe et des événements qui suivent des erreurs serveur) se produisent en réponse aux événements réels que génère le cluster, hormis lorsque le serveur est confronté à une erreur lui faisant ignorer les événements générés par le cluster. Le cas échéant, il génère un événement pour chaque type d'événements représentant l'état actuel du système. Chaque événement est transmis aux clients qui ont notifié leur souhait de recevoir ce type d'événements.

Chaque événement respecte la sémantique « au moins une fois », ce qui signifie que le serveur peut envoyer le même événement au client plus d'une fois. Cette faculté est indispensable lorsque le serveur redevient opérationnel après une interruption provisoire et qu'il ne peut déterminer si le client a reçu les dernières informations transmises.

Contenu d'un message SC_EVENT

Le message SC_EVENT contient le message exact qui a été généré au sein du cluster, retranscrit au format de message XML SC_EVENT. Le tableau indiqué ci-dessous présente les types d'événements que le protocole CRNP envoie, y compris les paires nom/valeurs requises, l'éditeur et le fournisseur.