enquire_link (0x00000015) ist ein leichtgewichtiges Keepalive, das bestätigt, dass eine gebundene SMPP-Sitzung über TCP weiterhin gesund ist. Der Durchsatz wird durch zwei Grenzen bestimmt: das Fenster (wie viele PDUs gleichzeitig unbestätigt sein dürfen) und die TPS-Obergrenze des Anbieters. Ein Überschreiten der Rate gibt ESME_RTHROTTLED (0x00000058) zurück; die Lösung ist ein Backoff.
bind_transceiverSitzung öffnen und authentifizierenbind_transceiver_respSitzung akzeptiertsubmit_smNachricht sendensubmit_sm_respAkzeptiert, Nachrichten-ID zurückgegebendeliver_smZustellungsbericht oder eingehende Nachrichtdeliver_sm_respBestätigtenquire_linkKeepalive im Leerlauf
enquire_link-Keepalive
Eine gebundene SMPP-Sitzung kann lange Zeit untätig sein, und eine halb offene TCP-Verbindung wirkt auf Socket-Ebene lebendig. enquire_link löst dies: Jede Gegenstelle sendet es auf einem Leerlauf-Timer (üblich alle 30–60 Sekunden) und erwartet umgehend ein enquire_link_resp. Eine ausbleibende Antwort bedeutet, dass die Sitzung tot ist — bauen Sie die TCP-Verbindung ab und verbinden Sie mit Backoff erneut. Es ist der einzige zuverlässige Weg, eine stillschweigend gebrochene Verbindung zu erkennen.
ESME → SMSC enquire_link seq=1200
SMSC → ESME enquire_link_resp seq=1200 status=ESME_ROK
(no response within timeout ⇒ treat session as dead, reconnect)Das Fenster: ausstehende unbestätigte PDUs
SMPP ist asynchron: Sie können viele submit_sm-PDUs senden, bevor deren submit_sm_resp eintrifft. Die Fenstergröße begrenzt, wie viele gleichzeitig ausstehen (unbestätigt) dürfen. Ist das Fenster voll, müssen Sie das Einreichen pausieren, bis eine Response einen Platz freigibt. Über das Fenster hinaus zu senden ist eine führende Ursache für Drosselung und verworfene PDUs. Die Fenstergröße wird mit dem Anbieter vereinbart — es gibt keinen einheitlichen Protokoll-Standard.
Drosselung und TPS
Getrennt vom Fenster erzwingt der Anbieter eine maximale Nachrichtenrate — Transaktionen pro Sekunde (TPS) — je Bind oder je Konto. Ein Überschreiten gibt ESME_RTHROTTLED (0x00000058) zurück. Die richtige Reaktion ist, langsamer zu werden: pausieren, mit Backoff und Jitter warten und unter der Obergrenze fortfahren. Wiederholen Sie eine gedrosselte PDU niemals sofort und öffnen Sie keine zusätzlichen Binds, um das Limit zu umgehen — beides riskiert eine Kontosperrung. Bei v5.0 kann das SMSC zusätzlich über das congestion_state-TLV Überlast anzeigen, sodass ESMEs vorbeugend langsamer werden.
| Limit | Regelt | Signal bei Überschreitung |
|---|---|---|
| Fenstergröße | Unbestätigte PDUs in Übertragung | Backpressure / verworfene PDUs |
| TPS-Limit | Nachrichten pro Sekunde | ESME_RTHROTTLED (0x58) |
| Anzahl der Binds | Parallele Sitzungen | Bind abgelehnt / Kontoaktion |
Abstimmung für anhaltenden Durchsatz
Der tatsächliche Durchsatz entspricht grob der Fenstergröße geteilt durch die Umlaufzeit, begrenzt durch die TPS-Obergrenze. Ein größeres Fenster hilft auf Verbindungen mit hoher Latenz; mehr Binds helfen nur, wenn der Anbieter sie bereitstellt. Instrumentieren Sie die Fensterbelegung, die Submit-/Response-Latenz und die Drosselfehlerrate und werten Sie eine steigende ESME_RTHROTTLED-Rate als Signal, die Senderate zu reduzieren, statt stärker zu drücken.
Häufig gestellte Fragen
Wie oft sollte ich enquire_link senden?
Üblich alle 30–60 Sekunden auf einem Leerlauf-Timer. Senden Sie es, wenn die Sitzung ruhig war, und behandeln Sie ein ausbleibendes enquire_link_resp innerhalb Ihres Timeouts als tote Sitzung, die neu verbunden werden muss.
Was ist die SMPP-Fenstergröße?
Das Fenster ist die maximale Anzahl an PDUs, die Sie gleichzeitig ausstehend (gesendet, aber noch nicht bestätigt) haben dürfen. Sie wird mit Ihrem Anbieter ausgehandelt und nicht durch das Protokoll festgelegt; pausieren Sie das Einreichen, wenn das Fenster voll ist.
Wie behebe ich ESME_RTHROTTLED?
Reduzieren Sie Ihre Senderate. Pausieren Sie, warten Sie mit Backoff und Jitter und fahren Sie unter der TPS-Obergrenze des Anbieters fort. Wiederholen Sie nicht sofort und öffnen Sie keine zusätzlichen Binds, um das Limit zu umgehen — beides kann zu stärkerer Drosselung oder Sperrung des Kontos führen.
Erhöht ein größeres Fenster meine TPS?
Bis zu einem gewissen Punkt. Der Durchsatz entspricht grob der Fenstergröße geteilt durch die Umlaufzeit, ist aber weiterhin durch die TPS-Obergrenze des Anbieters begrenzt. Ein größeres Fenster hilft vor allem, Latenz auf Verbindungen mit hoher Umlaufzeit zu verbergen.
Was ist congestion_state in SMPP v5.0?
v5.0 ergänzt ein congestion_state-TLV, mit dem das SMSC anzeigen kann, wie ausgelastet es ist (0–100). Eine kooperative ESME liest es und wird vorbeugend langsamer, bevor sie auf harte Drosselung stößt, was den Durchsatz unter Last glättet.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)