Le protocole CRNP définit les couches application, présentation et session de la pile de protocoles OSI (Open System Interconnect/Interconnexion de systèmes ouverts) standard constituée de sept couches. La couche transport doit utiliser le protocole TCP, et la couche réseau le protocole IP. Le protocole CRNP est indépendant des couches liaison de données et physique. Tous les messages de la couche application échangés au moyen du protocole CRNP utilisent le langage XML 1.0.
Le protocole CRNP propose des mécanismes et des démons qui génèrent des événements de reconfiguration de cluster, les acheminent via le cluster et les transmettent aux clients intéressés.
Le démon cl_apid interagit avec les clients. Le gestionnaire de groupe de ressources (RGM, Resource Group Manager) de Sun Cluster génère des événements de reconfiguration de cluster. Ce démon utilise syseventd pour transmettre des événements à chaque noeud local. Le démon cl_apid communique avec les clients intéressés, via le protocole TCP/IP, en langage XML (Extensible Markup Language).
Le schéma suivant met en évidence le flux d'événements entre les composants CRNP. Un client est exécuté sur le noeud 2 du cluster tandis que l'autre fonctionne sur un ordinateur n'appartenant pas au cluster.
Les clients débutent des communications en envoyant un message d'enregistrement (SC_CALLBACK_RG) au serveur. Ce message indique le type d'événements dont les clients souhaitent être avertis, ainsi que le port auquel ces événements peuvent être transmis. L'IP source de la connexion d'enregistrement et le port spécifié constituent l'adresse de rappel.
Chaque fois qu'un événement susceptible d'intéresser un client est généré au sein du cluster, le serveur contacte le client à son adresse de rappel (IP et port) et lui transmet l'événement (SC_EVENT). Le serveur est hautement disponible car il fonctionne sur le cluster lui-même. Il enregistre les connexions client en mémoire et en conserve la trace même après la réinitialisation du cluster.
Les clients annulent leur enregistrement en envoyant un message d'enregistrement (SC_CALLBACK_RG contenant un message REMOVE_CLIENT) au serveur. Lorsque ce dernier leur renvoie le message SC_REPLY, les clients ferment leur connexion.
Le schéma suivant met en évidence le flux de communications entre un client et un serveur.
Le protocole CRNP utilise trois types de messages XML. Leur utilisation est décrite dans le tableau suivant. Ces trois types de messages sont également décrits plus en détail dans ce chapitre.
Type de message utilisé par le protocole CRNP |
Description |
---|---|
SC_CALLBACK_REG |
Ce message se présente sous quatre formes : ADD_CLIENT, REMOVE_CLIENT , ADD_EVENTS et REMOVE_EVENTS. Elles contiennent toutes les informations suivantes :
ADD_CLIENT, ADD_EVENTS et REMOVE_EVENTS contiennent également une liste non bornée de types d'événements, comprenant chacun les informations suivantes :
La classe et la sous-classe d'événement définissent un “type d'événements” unique. La DTD (définition du type de document) qui permet de générer les classes de SC_CALLBACK_REG est SC_CALLBACK_REG. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP. |
SC_REPLY |
Ce message contient les informations suivantes :
La DTD qui permet de générer les classes de SC_REPLY est SC_REPLY. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP. |
SC_EVENT |
Ce message contient les informations suivantes :
Les valeurs d'un message SC_EVENT ne sont pas typées. La DTD qui permet de générer les classes de SC_EVENT est SC_EVENT. Elle est décrite plus en détail à l'Annexe F, Définitions de types de documents pour le protocole CRNP. |