Processus de connexion d'un client au serveur

Cette rubrique décrit comment un administrateur configure le serveur, comment les clients sont enregistrés et les informations transmises aux couches application et session, ainsi que les conditions d'erreur.

Hypothèses sur la configuration du serveur par les administrateurs

L'administrateur système doit configurer le serveur à l'aide d'une adresse IP à haut niveau de disponibilité (c'est-à-dire une adresse IP qui n'est pas liée à une machine particulière du cluster) ni à un numéro de port. L'administrateur 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. Les administrateurs utilisent un service d'attribution de noms qui permet aux clients de rechercher l'adresse réseau du serveur de façon dynamique ou ajoutent le nom du réseau au fichier de configuration que le client doit lire. Le serveur fonctionne au sein du cluster comme un type de ressources de basculement.

Processus d'identification d'un client par le serveur

Chaque client est identifié de façon unique au moyen de 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 suppose que des messages SC_CALLBACK_REG ultérieurs, possédant la même adresse de rappel, proviendront 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

Un client initie une connexion en ouvrant 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 la lecture, le client doit envoyer son message de connexion. Il doit s'agir d'un message SC_CALLBACK_REG correctement formaté qui n'est ni 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 client. Si ce dernier ne formate pas le message correctement, le serveur n'enregistre pas le client et lui transmet un message d'erreur. Si le client ferme la connexion de prise avant que le serveur n'envoie sa réponse, ce dernier enregistre le client comme d'habitude.

Un client peut 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é, en dérangement ou non valide, il renvoie un message d'erreur au client.

Un client ne peut pas transmettre un message ADD_EVENTS, REMOVE_EVENTS ou REMOVE_CLIENT avant d'avoir envoyé un message ADD_CLIENT. Un client ne peut pas transmettre un message REMOVE_CLIENT avant d'avoir envoyé un message ADD_CLIENT.

Si un client envoie un message ADD_CLIENT alors qu'il est déjà connecté, le serveur peut supporter ce message. Dans cette situation, le serveur remplace la connexion client antérieure par la nouvelle qui est spécifiée dans le second message ADD_CLIENT.

Mais en règle générale, un client se connecte une seule fois au serveur par l'envoi d'un message ADD_CLIENT. De même, il se déconnecte une seule fois en envoyant au serveur un message REMOVE_CLIENT. 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, ADD_EVENTS et REMOVE_EVENTS contient une liste d'événements. Le tableau indiqué ci-après présente les types d'événements que le protocole CRNP accepte, y compris les paires nom/valeurs requises.

Si un client :

• envoie un message REMOVE_EVENTS spécifiant un ou plusieurs types d'événements auxquels le client ne s'est pas précédemment connecté ;

• se connecte deux fois au même type d'événements ;