Processus d'enregistrement d'un client auprès du serveur

Cette section indique comment un administrateur de cluster configure le serveur, comment les clients sont identifiés, comment les informations sont envoyées via les couches application et session, ainsi que les conditions d'erreur.

Hypothèses sur la configuration du serveur par les administrateurs

L'administrateur du cluster doit configurer le serveur à l'aide d'une adresse IP à haute disponibilité (une adresse IP qui n'est pas liée à une machine en particulier du cluster) et d'un numéro de port. L'administrateur du cluster doit transmettre cette adresse réseau aux clients potentiels. Le protocole CRNP ne définit pas comment ce nom de serveur est rendu accessible aux clients. L'administrateur du cluster utilise un service d'attribution de noms, ce qui permet aux clients de trouver l'adresse réseau du serveur de manière dynamique, ou ajoute le nom du réseau à un fichier de configuration que le client doit lire. Le serveur fonctionne au sein du cluster comme un type de ressource de basculement.

Processus d'identification d'un client par le serveur

Chaque client est identifié de manière unique par son adresse de rappel, c'est-à-dire son adresse IP et son numéro de port. Le port est spécifié dans les messages SC_CALLBACK_REG et l'adresse IP obtenue à partir de la connexion d'enregistrement TCP. Le protocole CRNP considère que les messages SC_CALLBACK_REG suivants ayant la même adresse de rappel proviennent du même client, même si le port source de transmission des messages est différent.

Processus de transmission des messages SC_CALLBACK_REG entre un client et le serveur

Pour procéder à l'enregistrement, le client commence par ouvrir une connexion TCP sur l'adresse IP et le numéro de port du serveur. Une fois la connexion TCP établie et prête pour l'écriture, le client doit envoyer son message d'enregistrement. Il doit s'agir d'un message SC_CALLBACK_REG correctement formaté, qui ne doit pas être suivi ni précédé d'octets supplémentaires.

Une fois tous les octets émis, le client doit rester connecté pour recevoir une réponse du serveur. S'il ne formate pas le message correctement, le serveur n'enregistre pas le client et lui transmet un message d'erreur. Toutefois, si le client ferme la connexion (au niveau du socket) avant que le serveur n'ait envoyé sa réponse, ce dernier enregistre le client en suivant la procédure habituelle.

Les clients peuvent contacter le serveur à tout moment. Chaque fois qu'un client contacte le serveur, il doit envoyer un message SC_CALLBACK_REG. Si le serveur reçoit un message malformé, non fonctionnel ou non valide, il renvoie un message d'erreur au client.

Pour transmettre un message ADD_EVENTS, REMOVE_EVENTS ou REMOVE_CLIENT, un client doit d'abord envoyer un message ADD_CLIENT. De même, avant de transmettre un message REMOVE_CLIENT, il doit envoyer un message ADD_CLIENT.

Si un client envoie un message ADD_CLIENT alors qu'il est déjà enregistré, le serveur peut tolérer ce message. Il remplace l'enregistrement client antérieur par le nouvel enregistrement spécifié dans le second message ADD_CLIENT.

Mais en règle générale, un client s'enregistre une seule fois auprès du serveur par l'envoi d'un message ADD_CLIENT. Un client annule une seule fois son enregistrement en envoyant un message REMOVE_CLIENT au serveur. Le protocole CRNP offre une plus grande souplesse aux clients qui doivent modifier de façon dynamique leur liste de types d'événements.

Contenu d'un message SC_CALLBACK_REG

Chaque message ADD_CLIENT, REMOVE_CLIENT, ADD_EVENTS et REMOVE_EVENTS contient une liste d'événements. Le tableau ci-après présente les types d'événements que le protocole CRNP accepte, avec les paires nom/valeurs requises.

Si un client effectue l'une des actions suivantes, le serveur ignore ces messages sans vous en avertir :

• Il envoie un message REMOVE_EVENTS qui spécifie un ou plusieurs types d'événements pour lesquels il ne s'est pas enregistré précédemment.

• Il s'enregistre deux fois pour le même type d'événement.