Eine robuste SMPP-Integration ist eine Frage der Betriebsdisziplin, nicht nur korrekter PDUs: den richtigen Bind-Modus wählen, sequence_number und das Fenster sorgfältig verwalten, mit Jitter-Backoff wiederholen, das Einreichen idempotent machen, um Doppelabrechnung zu vermeiden, jedes deliver_sm bestätigen und bei Fehlern sauber neu verbinden. Machen Sie dies richtig, erledigen sich die Protokolldetails von selbst.
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
Bind-Strategie
Bevorzugen Sie einen Transceiver-Bind, wo der Anbieter dies zulässt, sodass eine Verbindung sowohl Submit als auch Empfang trägt und die DLR-Korrelation vereinfacht. Vereinbaren Sie die Anzahl gleichzeitiger Binds und die TPS je Bind vor dem Skalieren schriftlich mit dem Anbieter. Bestätigen Sie die ausgehandelte SMPP-Version aus dem bind_resp und behandeln Sie Bind-Fehler explizit — wiederholen Sie transiente Zustände wie ESME_RALYBND, behandeln Sie aber ESME_RINVPASWD/ESME_RINVSYSID als fatale Konfigurationsfehler, statt zu loopen.
sequence_number und das Fenster
Vergeben Sie eine monoton steigende sequence_number (1 bis 0x7FFFFFFF, dann Umbruch) und nutzen Sie sie, um jede Response ihrem Request zuzuordnen. Verfolgen Sie ausstehende Requests in einer nach sequence_number geschlüsselten Map mit Timeout, sodass eine nie eintreffende Response erkannt wird. Respektieren Sie das Fenster: Begrenzen Sie die in Flug befindlichen unbestätigten PDUs und pausieren Sie das Einreichen, wenn es voll ist, statt blind zu senden, was Drosselung auslöst.
| Status | Warum |
|---|---|
| Outstanding-Request-Map (nach sequence_number) | Antworten korrelieren, Timeouts erkennen |
| Fensterbelegungszähler | Backpressure vor ESME_RTHROTTLED |
| Idempotenzschlüssel pro logischer Nachricht | Doppelte Sendungen bei Wiederholungen verhindern |
| Bind-Status + Zeitpunkt des letzten enquire_link_resp | Inaktive Sitzungen erkennen |
Retries, Backoff und Idempotenz
Wiederholen Sie transiente Fehler (ESME_RMSGQFUL, ESME_RTHROTTLED, Systemfehler, Timeouts) mit exponentiellem Backoff und Jitter, damit sich Reconnect-Stürme nicht über Worker hinweg synchronisieren. Wiederholen Sie keine dauerhaften Fehler (ungültige Adresse, ungültiges Passwort). Entscheidend: Machen Sie das Einreichen idempotent — hängen Sie Ihre eigene Referenz an (zum Beispiel über user_message_reference) und entfernen Sie Duplikate, sodass ein Retry nach einem uneindeutigen Timeout nicht doppelt abrechnet oder doppelt zustellt.
Verarbeitung von Zustellberichten
Fordern Sie registered_delivery nur dort an, wo Sie die Berichte verarbeiten. Antworten Sie stets umgehend mit deliver_sm_resp und verarbeiten Sie asynchron. Korrelieren Sie Berichte über das receipted_message_id-TLV, normalisieren Sie Hex-/Dezimal-ID-Formate und schließen Sie eine Nachricht nur bei einem endgültigen stat ab. Bilden Sie Netz-err-Codes auf eine normalisierte Taxonomie ab, damit die Qualität routenübergreifend vergleichbar ist. Behandeln Sie Zwischenbenachrichtigungen getrennt von Endzuständen.
Keepalive und Reconnect
Senden Sie enquire_link auf einem Leerlauf-Timer und behandeln Sie eine ausbleibende Antwort als tote Sitzung. Verbinden Sie bei jeder Trennung mit Backoff und Jitter neu, statt heiß zu loopen. Setzen Sie beim Reconnect auf einem sauberen Zustand auf: neu binden, die Map ausstehender Requests zurücksetzen und sich auf Idempotenz verlassen, um in Flug befindliches sicher erneut einzureichen. Instrumentieren Sie Bind-Zustand, Fensterbelegung, Submit-/DLR-Latenz und Fehlercode-Raten und alarmieren Sie bei all dem.
Häufig gestellte Fragen
Wie sollte ich sequence_number vergeben?
Verwenden Sie einen monoton steigenden Zähler von 1 bis 0x7FFFFFFF, dann Umbruch. Führen Sie eine Map ausstehender sequence_numbers mit Timeouts, sodass Sie jede Response korrelieren und Requests erkennen können, die nie eine erhielten.
Wie vermeide ich Doppelabrechnung bei Retries?
Machen Sie das Einreichen idempotent. Hängen Sie Ihre eigene Referenz an (z. B. user_message_reference), entfernen Sie darauf basierend Duplikate und gestalten Sie Retries so, dass ein erneutes Senden nach einem uneindeutigen Timeout erkannt und unterdrückt wird, statt doppelt zugestellt und abgerechnet zu werden.
Welche SMPP-Fehler sollte ich wiederholen?
Wiederholen Sie transiente — ESME_RMSGQFUL, ESME_RTHROTTLED, Systemfehler und Timeouts — mit exponentiellem Backoff und Jitter. Wiederholen Sie keine dauerhaften Fehler wie ESME_RINVDSTADR oder ESME_RINVPASWD; korrigieren Sie stattdessen die Eingabe oder Konfiguration.
Was sollte ich an einem SMPP-Bind überwachen?
Bind-Zustand, Zeit seit dem letzten enquire_link_resp, Fensterbelegung, Submit- und DLR-Latenz sowie Fehlerraten je Code (besonders ESME_RTHROTTLED). Alarmieren Sie bei steigender Drosselung oder einem blockierten Fenster als frühe Warnsignale.
Wie sollte ich den Reconnect nach einer abgebrochenen Sitzung handhaben?
Verbinden Sie mit Jitter-basiertem exponentiellem Backoff neu, binden Sie erneut, setzen Sie Ihre Map ausstehender Requests zurück und reichen Sie in Flug befindliche Nachrichten erneut ein, gestützt auf Idempotenz zur Vermeidung von Duplikaten. Loopen Sie Reconnects niemals heiß, da dies Ihre IP sperren lassen kann.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)