Client-Registrierung beim Server

In diesem Abschnitt wird beschrieben, wie ein Cluster-Administrator den Server einrichtet, wie Clients identifiziert werden, wie Informationen über die Anwendungs- und Sitzungsschichten gesendet werden, sowie die Fehlermeldungen.

Annahmen zur Konfiguration des Servers durch den Administrator

Der Cluster-Administrator muss den Server mit einer hoch verfügbaren IP-Adresse (eine Adresse, die nicht an einen bestimmten Rechner im Cluster gebunden ist) und einer Portnummer konfigurieren. Der Cluster-Administrator muss diese Netzwerkadresse für potenzielle Clients veröffentlichen. Das CRNP definiert nicht, wie der Servername den Clients verfügbar gemacht wird. Der Cluster-Administrator verwendet entweder einen Namensdienst, mit dem Clients die Netzwerkadresse des Servers dynamisch suchen können, oder fügt den Netzwerknamen einer Konfigurationsdatei hinzu, die der Client lesen soll. Der Server wird innerhalb des Clusters als Failover-Ressourcentyp ausgeführt.

Client-Identifizierung durch den Server

Jeder Client wird durch seine Rückrufadresse eindeutig identifiziert, d.h. seine IP-Adresse und Port-Nummer. 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 nachfolgende SC_CALLBACK_REG-Meldungen mit derselben Rückrufadresse von demselben Client stammen, selbst wenn der Quell-Port, von dem die Meldungen gesendet werden, ein anderer ist.

Senden von SC_CALLBACK_REG-Meldungen zwischen einem Client und dem Server

Ein Client initiiert eine Registrierung, indem eine TCP-Verbindung mit der IP-Adresse und der Port-Nummer des Servers hergestellt wird. 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 von diesem Client keine ADD_CLIENT-Meldung gesendet wurde. Ein Client kann keine REMOVE_CLIENT-Meldung senden, bevor von diesem Client keine 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. Ein Client wird einmalig deregistriert, indem eine REMOVE_CLIENT-Meldung an den Server gesendet wird. 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-, REMOVE_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 der folgenden Aktionen durchführt, ignoriert der Server diese Meldungen automatisch:

• Sendet eine REMOVE_EVENTS-Meldung, die mindestens einen Ereignistyp angibt, für den der Client zuvor nicht registriert wurde

• sich zweimal für den gleichen Ereignistyp registriert,