Nach Verarbeiten der Registrierung sendet der Server die SC_REPLY-Meldung. Der Server sendet diese Meldung über die offene TCP-Verbindung des Clients, über die er die Registrierungsanforderung erhalten hatte. Daraufhin beendet der Server die Verbindung. Der Client muss die TCP-Verbindung so lange offen halten, bis er die SC_REPLY-Meldung vom Server erhalten hat.
Der Client führt zum Beispiel folgende Aktionen aus:
Herstellen einer TCP-Verbindung mit dem Server,
Warten, bis die Verbindung “schreibbereit” ist,
Senden einer SC_CALLBACK_REG-Meldung mit einer ADD_CLIENT-Meldung,
Warten auf eine SC_REPLY-Meldung,
Erhalten einer SC_REPLY-Meldung,
Erhalten einer Anzeige, dass der Server die Verbindung beendet hat (Lesen von 0 Bytes vom Socket),
Beenden der Verbindung.
Herstellen einer TCP-Verbindung mit dem Server,
Warten, bis die Verbindung “schreibbereit” ist,
Senden einer SC_CALLBACK_REG -Meldung mit einer REMOVE_CLIENT-Meldung,
Warten auf eine SC_REPLY-Meldung,
Erhalten einer SC_REPLY-Meldung,
Erhalten einer Anzeige, dass der Server die Verbindung beendet hat (Lesen von 0 Bytes vom Socket),
Beenden der Verbindung.
Jedes Mal, wenn der Server eine SC_CALLBACK_REG-Meldung von einem Client erhält, sendet er eine SC_REPLY-Meldung über dieselbe offene Verbindung. Diese Meldung gibt an, ob der Vorgang erfolgreich war oder fehlgeschlagen ist. SC_REPLY-XML-DTD enthält die XML-Dokumenttypdefinition einer SC_REPLY-Meldung sowie der möglichen Fehlermeldungen, die darin enthalten sein können.
Eine SC_REPLY-Meldung gibt an, ob ein Vorgang erfolgreich war oder fehlgeschlagen ist. Diese Meldung enthält die Version der CRNP-Protokollmeldung, einen Statuscode und eine Statusmeldung, die den Statuscode detaillierter beschreibt. In der folgenden Tabelle werden die möglichen Werte für den Statuscode aufgelistet.
Statuscode |
Beschreibung |
---|---|
OK |
Die Meldung wurde erfolgreich verarbeitet. |
RETRY |
Die Client-Registrierung wurde vom Server aufgrund eines temporären Fehlers zurückgewiesen. Der Client sollte einen weiteren Registrierungsversuch mit anderen Parametern unternehmen. |
LOW_RESOURCE |
Die Cluster-Ressourcen sind ausgelastet, und der Client muss für einen erneuten Registrierungsversuch einen späteren Zeitpunkt abwarten. Eine andere Möglichkeit wäre, dass der Systemverwalter die entsprechenden Cluster-Ressourcen erhöht. |
SYSTEM_ERROR |
Ein schwerwiegendes Problem ist aufgetreten. Nehmen Sie Kontakt mit dem Systemverwalter für den Cluster auf. |
FAIL |
Die Autorisierung ist fehlgeschlagen, oder ein sonstiges Problem hat das Scheitern der Registrierung verursacht. |
MALFORMED |
Die XML-Anforderung war fehlerhaft und konnte nicht analysiert werden. |
INVALID |
Die XML-Anforderung war ungültig (entspricht nicht der XML-Spezifikation). |
VERSION_TOO_HIGH |
Die Meldungsversion war für eine erfolgreiche Verarbeitung zu hoch. |
VERSION_TOO_LOW |
Die Meldungsversion war für eine erfolgreiche Meldungsverarbeitung zu niedrig. |
Unter normalen Bedingungen erhält ein Client, der eine SC_CALLBACK_REG-Meldung sendet, eine Antwort, die eine erfolgreiche oder fehlgeschlagene Registrierung angibt.
Bei der Client-Registrierung kann jedoch auf der Serverseite eine Fehlerbedingung auftreten, die den Server davon abhält, eine SC_REPLY-Meldung an den Client zu senden. In diesem Fall kann die Registrierung entweder vor Auftreten der Fehlerbedingung erfolgreich verlaufen sein, oder sie konnte noch nicht verarbeitet werden.
Da der Server auf dem Cluster als Failover- oder hoch verfügbarer Server auf dem Cluster eingesetzt werden muss, bedeutet diese Fehlerbedingung nicht, dass der Dienst beendet wird. Es kann sogar sein, dass der Server bald beginnt, Ereignisse an den neu registrierten Client zu senden.
Um diese Fehlerbedingungen zu beheben, muss der Client folgendermaßen verfahren:
Er muss auf Anwendungsebene eine Zeitüberschreitung für die Registrierungsverbindung einsetzen, die auf eine SC_REPLY-Meldung wartet. Nach Ablauf der Zeitüberschreitung muss der Client einen erneuten Registrierungsversuch unternehmen.
Er muss beginnen, an der Rückmelde-IP-Adresse und Port-Nummer Ereigniszustellungen abzuhören, bevor er sich für die Ereignisrückmeldungen registriert. Der Client muss parallel eine Registrierungs-Bestätigungsmeldung und Ereigniszustellungen abwarten. Wenn der Client Ereignisse erhält, bevor die Bestätigungsmeldung bei ihm eingegangen ist, sollte er die Registrierungsverbindung stillschweigend beenden.