Nach Verarbeitung der Registrierung sendet der Server, dem die Registrierungsanforderung zugestellt wurde, die SC_REPLY-Meldung mit der TCP-Verbindung, die vom Client hergestellt wurde. Der Server schließt 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 vom Server
Erhalten einer SC_REPLY-Meldung vom Server
Erhalten einer Anzeige, dass der Server die Verbindung beendet hat (Lesen von 0 Bytes vom Socket),
Beenden der Verbindung.
Zu einem späteren Zeitpunkt führt der Client die folgenden Aktionen aus:
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 vom Server
Erhalten einer SC_REPLY-Meldung vom Server
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 die möglichen Fehlermeldungen, die diese Meldung beinhalten kann.
Eine SC_REPLY-Meldung gibt an, ob eine Operation erfolgreich oder fehlerhaft war. Diese Meldung enthält die Version der CRNP-Meldung, einen Statuscode sowie eine Statusmeldung, die den Statuscode detailliert 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 aufgrund eines Übergangsfehlers zurückgewiesen. Der Client sollte die Registrierung erneut versuchen, mit unterschiedlichen Argumenten. |
LOW_RESOURCE |
Die Cluster-Ressourcen sind gering und der Client kann es nur zu einem späteren Zeitpunkt erneut versuchen. Der Cluster-Administrator für den Cluster kann auch die Ressourcen im Cluster erhöhen. |
SYSTEM_ERROR |
Ein schwerwiegendes Problem ist aufgetreten. Wenden Sie sich an den Cluster-Administrator. |
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, d.h. sie erfüllt die XML-Spezifikationen nicht. |
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, ob die Registrierung erfolgreich oder fehlerhaft war.
Der Server kann jedoch bei der Client-Registrierung eine Fehlerbedingung erfahren, die verbietet, dass der Server eine SC_REPLY-Meldung an den Client sendet. In diesem Fall kann die Registrierung entweder vor Auftreten der Fehlerbedingung erfolgreich verlaufen sein, oder sie konnte noch nicht verarbeitet werden.
Da der Server im Cluster als Failover funktionieren oder hoch verfügbar sein muss, bedeutet diese Fehlerbedingung keine Beendigung des Dienstes. Es kann sogar sein, dass der Server bald beginnt, Ereignisse an den neu registrierten Client zu senden.
Um diese Situation zu beheben, sollte Ihr Client die folgenden Aktionen durchführen:
Er muss eine Zeitüberschreitung auf Anwendungsebene für eine Registrierungsverbindung festlegen, die auf eine SC_REPLY-Meldung wartet, nach der der Client die Registrierung erneut versuchen muss.
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.