Client-Registrierung beim Server

Dieser Abschnitt beschreibt, wie ein Verwalter den Server einrichtet, wie Clients identifiziert werden, wie Informationen über die Anwendungsschicht und die Sitzungsebene gesendet werden, sowie die Fehlerbedingungen.

Annahmen bezüglich der Serverkonfiguration durch Verwalter

Der Systemadministrator muss den Server mit einer hoch verfügbaren IP-Adresse, also einer IP-Adresse, die nicht an einen bestimmten Rechner im Cluster gebunden ist, sowie mit einer Port-Nummer konfigurieren. Er muss diese Netzwerkadresse an mögliche Clients veröffentlichen. Das CRNP definiert nicht, wie der Servername den Clients verfügbar gemacht wird. Die Verwalter können entweder einen Namensdienst einsetzen, mit dessen Hilfe die Clients die Netzwerkadresse des Servers dynamisch finden können, oder sie fügen den Netzwerknamen einer vom Client gelesenen Konfigurationsdatei hinzu. Der Server wird im Cluster als Failover-Ressourcentyp ausgeführt.

Client-Identifizierung durch den Server

Jeder Client wird durch seine Rückmeldeadresse, also die IP-Adresse und Port-Nummer, eindeutig identifiziert. Der Port wird in den SC_CALLBACK_REG-Meldungen angegeben, und die IP-Adresse wird aus der TCP-Registrierungsverbindung abgerufen. Das CRNP geht davon aus, dass alle folgenden SC_CALLBACK_REG-Meldungen mit der gleichen Rückmeldeadresse von demselben Client kommen, auch wenn der Quell-Port, von dem aus die Meldungen gesendet werden, unterschiedlich ist.

Senden von SC_CALLBACK_REG-Meldungen zwischen einem Client und dem Server

Ein Client leitet die Registrierung ein, indem er eine TCP-Verbindung mit der IP-Adresse und Port-Nummer des Servers herstellt. Wenn die TCP-Verbindung hergestellt und schreibbereit ist, muss der Client die Registrierungsmeldung senden. Die Registrierungsmeldung muss eine korrekt formatierte SC_CALLBACK_REG-Meldung sein, die weder vor noch nach der Meldung zusätzliche Bytes enthält.

Nach Schreiben aller Bytes an den Strom muss der Client die Verbindung aufrechterhalten, um die Antwort des Servers erhalten zu können. Wenn der Client die Meldung nicht korrekt formatiert, wird er vom Server nicht registriert, und dieser sendet eine Fehlerantwort an den Client. Wenn der Client die Socketverbindung beendet, bevor der Server eine Antwort gesendet hat, wird er dennoch vom Server ordnungsgemäß registriert.

Ein Client kann jederzeit Kontakt mit dem Server aufnehmen. Bei jeder Kontaktaufnahme mit dem Server muss der Client eine SC_CALLBACK_REG-Meldung senden. Wenn der Server eine Meldung erhält, die fehlerhaft, beschädigt oder ungültig ist, sendet er eine Fehlerantwort an den Client.

Ein Client kann keine ADD_EVENTS-, REMOVE_EVENTS- oder REMOVE_CLIENT-Meldung senden, bevor seine ADD_CLIENT-Meldung gesendet wurde. Er kann auch keine REMOVE_CLIENT-Meldung senden, bevor seine ADD_CLIENT-Meldung gesendet wurde.

Wenn ein Client eine ADD_CLIENT-Meldung sendet, obwohl er bereits registriert ist, kann der Server diese Meldung tolerieren. In diesem Fall ersetzt der Server die alte Client-Registrierung stillschweigend durch die neue Client-Registrierung, die in der zweiten ADD_CLIENT-Meldung angegeben ist.

In den meisten Fällen registriert sich ein Client einmal beim Server. Dies geschieht beim Starten des Clients mittels Senden einer ADD_CLIENT-Meldung. Ebenso deregistriert sich ein Client nur einmal, indem er eine REMOVE_CLIENT-Meldung an den Server sendet. Das CRNP bietet jedoch größere Flexibilität für diejenigen Clients, die ihre Ereignistypliste dynamisch ändern möchten.

Inhalt einer SC_CALLBACK_REG-Meldung

Jede ADD_CLIENT-, ADD_EVENTS- und REMOVE_EVENTS-Meldung enthält eine Ereignisliste. Die folgende Tabelle beschreibt die Ereignistypen, die das CRNP akzeptiert, einschließlich der erforderlichen Namens- und Wertepaare.

Wenn ein Client:

• eine REMOVE_EVENTS-Meldung sendet, die einen oder mehrere Ereignistypen angibt, für die der Client nicht zuvor registriert wurde, oder

• sich zweimal für den gleichen Ereignistyp registriert,

ignoriert der Server diese Meldungen stillschweigend.

Klasse und Unterklasse	Namens- und Wertepaare	Beschreibung
EC_Cluster ESC_cluster_membership	Erforderlich: Keine  Optional: Keine	Wird für alle Änderungsereignisse bezüglich der Cluster-Mitgliedschaft registriert (Knotenversagen oder -beitritt)
EC_Cluster ESC_cluster_rg_state	Eines erforderlich, wie folgt:  rg_name Werttyp: Zeichenkette  Optional: Keine	Wird für alle Zustandsänderungsereignisse für Ressourcengruppe Name registriert
EC_Cluster ESC_cluster_r_state	Eines erforderlich, wie folgt:  r_name Werttyp: Zeichenkette  Optional: Keine	Wird für alle Zustandsänderungsereignisse für Ressource Name registriert
EC_Cluster Keine	Erforderlich: Keine   Optional: Keine	Wird für alle Sun Cluster-Ereignisse registriert