Processus de notification des événements au client par le serveur

À mesure que les événements sont générés dans le cluster, le serveur CRNP les notifie à tous les clients qui ont demandé à être avertis de ce type d'événements. 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.

Aussitôt un client enregistré pour un type d'événement (à 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 peut déterminer 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 un message SC_EVENT du serveur.

4. Lit un message SC_EVENT du serveur.

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 enregistrés, tous les clients doivent écouter leur adresse de rappel (adresse IP et numéro de port) en permanence afin de recevoir les éventuelles connexions entrantes 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. Pour recevoir d'autres notifications d'événements, le client doit se ré-enregistrer en envoyant un autre message SC_CALLBACK_REG contenant un message ADD_CLIENT.

Mécanisme garantissant la notification des événements

Au sein du cluster, l'avertissement des clients suit l'ordre de génération des événements. En d'autres termes, si un événement A est généré au sein du cluster avant un événement B, le client X reçoit l'événement A avant l'événement B. Cependant, l'ordre d'envoi des notifications d'événements à tous les clients n'est pas conservé. 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 », c'est-à-dire que le serveur peut envoyer la même notification d'événement à un client plus d'une fois. Cette autorisation est nécessaire lorsque le serveur s'arrête momentanément et qu'il est incapable de déterminer si le client a reçu les toutes dernières informations lorsqu'il se remet à fonctionner.

Contenu d'un message SC_EVENT

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

Les positions des éléments du tableau state_list sont synchronisées avec celles de node_list. Cela signifie que l'état du noeud répertorié en première position dans le tableau node_list se trouve en première position dans le tableau state_list.

Les autres noms commençant par ev_ et les valeurs connexes peuvent être présents, mais ne sont pas destinés à être utilisés par les clients.