SMPP-Sitzungsgesundheit: Verschlechterung erkennen, bevor Nachrichten verloren gehen

Eine verbundene Sitzung ist nicht immer eine gesunde Sitzung

Die Gesundheit von SMPP-Sitzungen muss schichtweise bewertet werden. Zunächst besteht eine Netzwerkverbindung, üblicherweise TCP/IP. Anschließend sendet das ESME eine Bind-Anfrage, um die SMPP-Sitzung im benötigten Modus zu öffnen. Dass TCP aufgebaut ist und der Bind akzeptiert wurde, bestätigt den Abschluss dieser beiden Schritte, beweist jedoch nicht, dass die Sitzung unter Last normal antwortet oder dass zukünftige Nachrichten akzeptiert oder zugestellt werden.

Eine Sitzung kann einen scheinbar aktiven Bind behalten, während Antwortzeiten steigen, unbeantwortete Anfragen sich ansammeln oder Socket-Schließungen und Resets auftreten. Deshalb ist das Signal „verbunden“ erforderlich, aber nicht ausreichend. Der Betrieb muss die tatsächliche Fähigkeit überwachen, korrelierte PDUs innerhalb der erwarteten Zeit auszutauschen.

Die Sitzungsgesundheit darf auch nicht mit dem Endergebnis einer SMS gleichgesetzt werden. Die Annahme eines submit_sm wird über submit_sm_resp und command_status beobachtet. Die nachgelagerte Phase wird, falls ein Zustellbericht angefordert wird, über DLRs beobachtet, die in deliver_sm oder data_sm transportiert werden. Ein korrekter Bind, ein offener Socket oder ein enquire_link_resp ersetzen diese Nachweise nicht.

• Verfügbares TCP: bestätigt die Transportschicht, nicht die Öffnung einer SMPP-Sitzung.
• Akzeptierter Bind: bestätigt, dass der SMSC die Sitzung und den angeforderten Modus akzeptiert hat.
• Operative Antworten: zeigen, ob PDUs einschließlich submit_sm eine korrelierte Antwort erhalten.
• DLRs: liefern spätere Informationen über den vom SMSC gemeldeten Status; sie dürfen nicht mit einem unabhängig verifizierten Nachweis der Zustellung an das Endgerät verwechselt werden.

Beobachtbare Komponenten: Transport, Bind, offene Anfragen und Antworten

SMPP arbeitet mit Request- und Response-PDUs. Mit Ausnahme von alert_notification muss jede Operation eine zugehörige Antwort haben. Das Feld sequence_number ermöglicht die Korrelation einer Anfrage mit ihrer Antwort und muss der primäre Identifikator sein, um Antwortzeiten zu messen und offene Operationen zu zählen.

Antworten sollten nicht anhand ihrer Ankunftsreihenfolge zugeordnet werden. SMPP erlaubt eine Ankunft in anderer Reihenfolge; daher muss eine Implementierung die Korrelation über sequence_number auflösen. Diese Vorsichtsmaßnahme ist besonders wichtig bei Sitzungen mit mehreren gleichzeitigen Operationen.

Das Protokoll definiert keine universelle Höchstzahl offener Operationen. Dieses Limit hängt von der Implementierung des SMSC ab; die Spezifikation empfiehlt als Richtwert, zehn gleichzeitig offene Operationen nicht zu überschreiten. Im Produktivbetrieb sollte das operative Limit, wenn möglich, mit dem Anbieter abgestimmt und gegen das tatsächliche Verhalten jeder Sitzung validiert werden.

• Sitzungskennung und Remote-Endpunkt.
• TCP-Status: verbunden, geschlossen, Fehler oder Reset.
• Ergebnis und Dauer des Bind.
• sequence_number, command_id und command_status.
• Zeitstempel für Versand und Empfang jeder PDU.
• Anzahl offener Anfragen nach Operationstyp.
• RTT von enquire_link und RTT von submit_sm_resp, getrennt gespeichert.

Bind-Modi und ihre operativen Auswirkungen

Der Bind-Modus definiert die erlaubte Verkehrsrichtung in einer Sitzung. bind_transmitter wird für Verkehr vom ESME zum SMSC verwendet. bind_receiver wird für Verkehr vom SMSC zum ESME verwendet. bind_transceiver ermöglicht bidirektionalen Austausch in einer einzigen Sitzung.

Wenn ein ESME im üblichen SMPP-3.4-Modell getrennte Sitzungen zum Senden und Empfangen verwendet, benötigt es zwei Netzwerkverbindungen und zwei SMPP-Sitzungen: eine Transmitter- und eine Receiver-Sitzung. Operativ müssen beide unabhängig überwacht werden. Eine gesunde Sendesitzung bestätigt nicht, dass die Empfangssitzung für DLRs oder andere eingehende PDUs verfügbar ist.

Bei einer Transceiver-Sitzung entfällt durch die gemeinsame Verbindung nicht die Notwendigkeit, beide Richtungen zu messen. Ausgehende Anfragen, ihre Antworten, eingehende PDUs und die Antworten, die das ESME gegebenenfalls auf diese PDUs zurückgibt, müssen getrennt beobachtet werden.

• Transmitter: überwachen Sie submit_sm und die zugehörigen submit_sm_resp.
• Receiver: überwachen Sie den Empfang von deliver_sm oder data_sm und die Antwort, die das ESME zurückgibt.
• Transceiver: überwachen Sie beide Richtungen und reduzieren Sie die Gesundheit nicht auf eine einzige aggregierte Kennzahl.
• Prüfen Sie, ob der Bind-Modus der für Route oder Verbindung erforderlichen operativen Funktion entspricht.

enquire_link: eine Sitzungssonde, kein Zustellbarkeitsnachweis

enquire_link ermöglicht einem ESME oder SMSC, den Kommunikationspfad auf SMPP-Anwendungsebene zu prüfen. Wenn ein enquire_link_resp mit derselben sequence_number eintrifft, gibt es einen Nachweis dafür, dass die Sitzung diesen Test zu diesem Zeitpunkt austauschen konnte.

Dieses Signal ist nützlich, um Inaktivität zu überwachen, eine Verschlechterung der RTT zu erkennen und eine halb offene Verbindung früher zu entdecken. Bei TCP kann ein Endpunkt eine Verbindung schließen oder abbrechen, ohne dass der andere dies sofort erkennt; das Problem kann erst beim Senden von Daten und dem Empfang eines Resets sichtbar werden. Eine SMPP-Sonde schafft Aktivität auf Anwendungsebene, beseitigt aber nicht jede Unsicherheit.

Verwenden Sie enquire_link nicht als Ersatz für submit_sm. Ein enquire_link_resp bestätigt weder, dass der SMSC Sendeverkehr akzeptiert, noch dass er ihn auf einer bestimmten Route verarbeiten kann oder dass ein Endempfänger eine Nachricht erhält. Messen Sie die RTT von enquire_link getrennt von der RTT von submit_sm_resp, damit eine gesunde Sonde keine Verschlechterung bei der Nachrichtenannahme verdeckt.

Ein einzelner fehlgeschlagener Sondentest sollte außerdem nicht automatisch zu dem Schluss führen, dass die Gegenstelle ausgefallen ist. Die Entscheidung muss Wiederholung, Dauer, Socket-Signale, Bind-Status und das Verhalten realer Anfragen berücksichtigen.

• Was geprüft wird: SMPP-Anwendungsaustausch in der aktiven Sitzung.
• Was nicht geprüft wird: Annahme von submit_sm, Routenfähigkeit, DLRs oder Endzustellung.
• Was zu messen ist: Versand, Empfang von enquire_link_resp, RTT, Timeout und sequence_number.
• Was zu vermeiden ist: eine Nichtverfügbarkeit wegen einer einzelnen fehlgeschlagenen Sonde ohne zusätzliche Signale erklären.

Frühe Verschlechterungssignale, die überwacht werden sollten

Das erste Signal ist meist eine anhaltende Abweichung von der eigenen Referenzlinie und nicht zwingend ein expliziter Fehler. Ein nachhaltiger Anstieg der RTT von enquire_link_resp kann darauf hinweisen, dass die Sitzung schlechter antwortet. Ein nachhaltiger Anstieg der RTT von submit_sm_resp oder der in command_status ersichtlichen Fehler weist auf ein Problem hin, das näher an der Verkehrsannahme liegt.

Ein wachsender Bestand offener sequence_number ist ein weiteres kritisches Signal. Solange die entsprechende Antwort nicht eintrifft, muss der Absender davon ausgehen, dass die PDU am Ziel nicht empfangen wurde. Dieses Ausbleiben einer Bestätigung darf jedoch nicht als Beweis behandelt werden, dass nie eine Remote-Aktion erfolgte: Nach einem Ausfall oder einer verlorenen Antwort kann operative Unsicherheit bestehen, die Kontrollen gegen Duplikate erfordert.

Wiederholte Timeouts des Transaktions-Timers, Socket-Fehler, unerwartete Schließungen und TCP-Resets rechtfertigen eine höhere Schweregradeinstufung. Ein Reset bricht die TCP-Verbindung ab; er liefert für sich genommen kein Ergebnis zu den noch offenen PDUs. Diese PDUs müssen für Untersuchung und weitere Behandlung als unsicher markiert werden.

Bind-Fehler oder -Ablehnungen sind ein direktes Signal dafür, dass keine geeignete Sitzung im angeforderten Modus besteht. Selbst bei korrektem Bind können eine Ansammlung offener Anfragen oder eine Verschlechterung von submit_sm_resp rechtfertigen, die Annahme neuer Sendungen zu begrenzen, bevor die Sitzung vollständig ausfällt.

• Erhöhte Latenz von enquire_link_resp über einen anhaltenden Zeitraum.
• Erhöhte Latenz oder Fehler bei submit_sm_resp.
• Anhaltender Anstieg offener Anfragen.
• Wiederkehrende Transaktions-Timeouts.
• Socket-Schließungen, -Fehler und -Resets.
• Bind-Fehler oder -Ablehnungen.
• Ausbleibende Antworten, obwohl zuvor ein normales Aktivitätsmuster bestand.

Operative Zustände: gesund, beeinträchtigt, nicht verfügbar und in Wiederherstellung

Die Definition expliziter Zustände verhindert, dass Warnmeldungen zu improvisierten Reaktionen führen. Die genauen Kriterien müssen für jeden Anbieter, jede Sitzung und jedes Verkehrsmuster angepasst werden, da SMPP keine universellen Zeitvorgaben und keine feste Höchstzahl offener Operationen vorgibt.

Eine gesunde Sitzung kombiniert verfügbaren Transport, einen für die erforderliche Rolle gültigen Bind, Antworten innerhalb ihrer üblichen Referenzwerte und keine ungewöhnliche Ansammlung offener Anfragen. Eine beeinträchtigte Sitzung behält eine gewisse Kommunikationsfähigkeit bei, zeigt jedoch anhaltende Verschlechterungen: höhere Latenz, mehr Timeouts, mehr offene Anfragen oder zunehmende Fehler.

Eine nicht verfügbare Sitzung kann für die benötigte Rolle nicht sicher verwendet werden. Ursache können ein Bind-Fehler oder eine Bind-Ablehnung, eine Socket-Schließung oder ein Reset oder wiederholte Transaktionsabläufe ohne Wiederherstellung von Antworten sein. Die Wiederherstellung muss ein eigener Zustand sein: Transport und Bind können wiederhergestellt sein, doch die Verkehrsannahme sollte pausiert oder eingeschränkt bleiben, bis Stabilität beobachtet wurde.

• Gesund: TCP verfügbar, gültiger Bind, normale Antworten und kontrollierte offene Anfragen.
• Beeinträchtigt: aktive Sitzung mit anhaltenden Verschlechterungssignalen.
• Nicht verfügbar: kein nutzbarer Transport oder Bind oder wiederholte Ausfälle ohne Wiederherstellung.
• In Wiederherstellung: Konnektivität wiederhergestellt, aber unter Beobachtung vor der Rückkehr zum Normalbetrieb.

Schwellenwerte und Warnungen ohne Abhängigkeit von einem einzelnen Ereignis gestalten

Schwellenwerte sollten auf einer eigenen Referenzlinie pro Verbindung und PDU-Typ basieren. Vergleichen Sie beispielsweise die übliche RTT-Verteilung von enquire_link mit jener von submit_sm_resp und beobachten Sie anhaltende Veränderungen hoher Perzentile, nicht nur Durchschnittswerte. Der Durchschnitt kann eine lange Reihe langsamer Antworten verbergen, die bereits das Fenster offener Anfragen belegt.

Fügen Sie eine zeitliche Dimension hinzu. Eine Warnung wegen eines einzelnen Timeouts oder einer verlorenen Sonde kann Rauschen und unnötige Maßnahmen erzeugen. Sicherer ist die Kombination aus Intensität, Dauer und Wiederholung: anhaltende Verschlechterung, mehrere Abläufe, kontinuierlich steigende offene Anfragen oder ein Transportereignis zusammen mit ausbleibender Wiederherstellung.

Warnungen müssen handlungsrelevanten Kontext enthalten: betroffene Sitzung, Bind-Modus, Remote-Endpunkt, PDU-Typ, Latenzentwicklung, offene Anfragen, letzter Socket-Fehler und Ergebnis des letzten Bind. Ohne diesen Kontext kann das Team ein Problem beim Empfang von DLRs mit einem Problem bei der Annahme von submit_sm verwechseln.

• Verwenden Sie Referenzwerte pro Sitzung, Anbieter und Operationstyp.
• Beobachten Sie neben Durchschnittswerten auch Perzentile und Trends.
• Fordern Sie Dauer oder Wiederholung, bevor ein isoliertes Signal eskaliert wird.
• Unterscheiden Sie Warnungen zu Transport, Bind, submit_sm-Antwort und DLR-Empfang.
• Überprüfen Sie Schwellenwerte nach Vorfällen und Konfigurationsänderungen.

Sichere Maßnahmen bei jedem Signal

Bei einer beginnenden Verschlechterung sollte das Risiko reduziert werden, bevor eine aggressive Wiederverbindung versucht wird. Sie können neue Annahmen begrenzen, die Sendegeschwindigkeit senken und bereits gesendeten Anfragen erlauben, innerhalb des konfigurierten Timers eine Antwort zu erhalten. Die Entscheidung hängt von der Kapazität der Sitzung und der vereinbarten Verkehrspolitik ab, sollte aber verhindern, dass das Fenster offener Anfragen unkontrolliert wächst.

Bei einer Schließung, einem Reset oder einem Bind-Fehler markieren Sie die Sitzung als nicht verfügbar und protokollieren, welche Anfragen noch offen waren. Stellen Sie die Verbindung kontrolliert wieder her: Transport erneut aufbauen, den erforderlichen Bind ausführen und eine Beobachtungsphase mit normalen Antworten abwarten, bevor die Annahme vollständig geöffnet wird.

Eine Eskalation an den Anbieter ist angemessen, wenn nachvollziehbare Nachweise für einen Ausfall oder eine anhaltende Verschlechterung vorliegen: Startzeit, Remote-Endpunkt, Bind-Modus, Bind-Ergebnisse, Abfolge der Timeouts, command_status, Socket-Ereignisse und Entwicklung offener Anfragen. Das Ziel ist nicht, ohne Beweise eine Ursache zuzuschreiben, sondern reproduzierbare Beobachtungen zu teilen.

Senden Sie nicht automatisch alle von einem Timeout oder Ausfall betroffenen Anfragen erneut. Das Ausbleiben einer Antwort bestätigt eine fehlende korrelierte Bestätigung, kann das Remote-Ergebnis jedoch unbestimmt lassen. Jeder Wiederholungsversuch muss einer vom Unternehmen definierten Idempotenz- oder Duplikatkontrollrichtlinie folgen.

• Leichte Verschlechterung: Annahmen begrenzen sowie offene Anfragen und RTT überwachen.
• Zunehmende Timeouts: Druck reduzieren und eine Ausweitung des Fensters offener Anfragen vermeiden.
• Socket geschlossen oder Reset: Sitzung aus dem Versand nehmen und offene Anfragen als unsicher klassifizieren.
• Bind fehlgeschlagen: keinen Verkehr für diese Rolle annehmen, bis eine gültige Sitzung wiederhergestellt ist.
• Wiederherstellung: Transport, Bind und eine Phase normaler Antworten validieren, bevor vollständig wieder geöffnet wird.
• Eskalation: korrelierte Nachweise teilen, nicht nur die Aussage „Verbindung ausgefallen“.