# SMPP enquire_link, Windowing und Drosselung

> 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.

- Kanonische URL: https://www.broadnet.me/de/reference/smpp-enquire-link-throttling
- Sprache: de
- Zuletzt aktualisiert: 2026-07-18
- Herausgeber: BroadNet (https://www.broadnet.me)

Wie SMPP eine Sitzung mit enquire_link am Leben hält, wie das Fenster ausstehende unbestätigte PDUs begrenzt und wie ESME_RTHROTTLED und TPS je Bind Ihren tatsächlichen Durchsatz bestimmen.

## 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.

*Keepalive-Austausch*

```text
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.

*Die drei Grenzen, die den Durchsatz bestimmen*

| 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äufige 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.

## Quellen

- [SMPP v3.4 specification — §4.11 enquire_link](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v5.0 specification — congestion state](https://smpp.org/SMPP_v5.pdf)

## Verwandte Seiten

- [SMPP command_status Fehlercodes](https://www.broadnet.me/de/reference/smpp-command-status-errors)
- [SMPP-Bind-Operationen](https://www.broadnet.me/de/reference/smpp-bind-operations)
- [Best Practices für die SMPP-Integration](https://www.broadnet.me/de/reference/smpp-integration-best-practices)
- [SMPP-Fehlercode-Suche (kostenloses Tool)](https://www.broadnet.me/de/tools/smpp-error-codes)
- [SMPP-Integrations-Checkliste (Leitfaden)](https://www.broadnet.me/de/guides/smpp-integration-checklist)