# SMPP enquire_link, windowing e throttling

> enquire_link (0x00000015) è un keepalive leggero che conferma che una sessione SMPP in stato bound è ancora integra sul TCP. Il throughput è governato da due limiti: la finestra (quante PDU possono restare non riscontrate contemporaneamente) e il tetto TPS del provider. Il superamento della velocità restituisce ESME_RTHROTTLED (0x00000058); la soluzione è eseguire un backoff.

- URL canonico: https://www.broadnet.me/it/reference/smpp-enquire-link-throttling
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

Come SMPP mantiene attiva una sessione con enquire_link, come la finestra limita le PDU non riscontrate in sospeso e come ESME_RTHROTTLED e il TPS per bind governano il throughput reale.

## Keepalive enquire_link

Una sessione SMPP in stato bound può restare inattiva a lungo e una connessione TCP half-open appare viva a livello di socket. enquire_link risolve il problema: uno dei due peer la invia su un timer di inattività (di norma ogni 30–60 secondi) e attende prontamente un enquire_link_resp. Una risposta mancante significa che la sessione è morta — abbattete la connessione TCP e riconnettetevi con backoff. È l'unico modo affidabile per rilevare un collegamento interrotto in silenzio.

*Scambio di keepalive*

```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)
```

## La finestra: PDU non riscontrate in sospeso

SMPP è asincrono: potete inviare molte PDU submit_sm prima che arrivi il relativo submit_sm_resp. La window size limita quante possono restare in sospeso (non riscontrate) contemporaneamente. Quando la finestra è piena occorre sospendere i submit finché una risposta libera uno slot. Inviare oltre la finestra è una causa primaria di throttling e PDU scartate. La window size è concordata con il provider — non esiste un unico valore predefinito nel protocollo.

## Throttling e TPS

Indipendentemente dalla finestra, il provider impone una velocità massima di messaggi — transazioni al secondo (TPS) — per bind o per account. Superarla restituisce ESME_RTHROTTLED (0x00000058). La risposta corretta è rallentare: sospendere, eseguire un backoff con jitter e riprendere sotto il tetto. Non riprovate mai immediatamente una PDU throttled né aprite bind aggiuntivi per aggirare il limite — entrambe le cose rischiano la sospensione dell'account. Nella v5.0 l'SMSC può inoltre segnalare la congestione tramite il TLV congestion_state affinché gli ESME rallentino preventivamente.

*I tre limiti che determinano il throughput*

| Limite | Governa | Segnale di superamento |
|---|---|---|
| Dimensione della finestra | PDU non confermate in transito | Backpressure / PDU scartate |
| Limite TPS | Messaggi al secondo | ESME_RTHROTTLED (0x58) |
| Numero di bind | Sessioni parallele | Bind rifiutato / azione sull'account |

## Ottimizzazione per un throughput sostenuto

Il throughput reale è all'incirca la window size divisa per la latenza di andata e ritorno, limitata dal tetto TPS. Una finestra più ampia aiuta sui collegamenti ad alta latenza; più bind aiutano solo se il provider li assegna. Monitorate l'occupazione della finestra, la latenza submit/risposta e il tasso di errori di throttling, e trattate un tasso crescente di ESME_RTHROTTLED come il segnale per ridurre la velocità di invio anziché forzare.

## Domande frequenti

### Con quale frequenza dovrei inviare enquire_link?

Di norma ogni 30–60 secondi su un timer di inattività. Inviatelo quando la sessione è rimasta silente e trattate un enquire_link_resp mancante entro il vostro timeout come una sessione morta da riconnettere.

### Che cos'è la window size di SMPP?

La finestra è il numero massimo di PDU che potete avere in sospeso (inviate ma non ancora riscontrate) contemporaneamente. È negoziata con il provider anziché fissata dal protocollo; sospendete i submit quando la finestra è piena.

### Come risolvo ESME_RTHROTTLED?

Riducete la velocità di invio. Sospendete, eseguite un backoff con jitter e riprendete sotto il tetto TPS del provider. Non riprovate immediatamente né aprite bind aggiuntivi per aggirare il limite — entrambe le cose possono portare a un throttling più severo o alla sospensione.

### Una finestra più ampia aumenta il mio TPS?

Fino a un certo punto. Il throughput è all'incirca la window size divisa per il tempo di andata e ritorno, ma resta limitato dal tetto TPS del provider. Una finestra più ampia serve soprattutto a mascherare la latenza su collegamenti ad alto RTT.

### Che cos'è congestion_state nella v5.0 di SMPP?

La v5.0 aggiunge un TLV congestion_state che permette all'SMSC di segnalare quanto è carico (0–100). Un ESME cooperativo lo legge e rallenta preventivamente prima di incorrere in un throttling severo, uniformando il throughput sotto carico.

## Fonti

- [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)

## Correlati

- [Codici di errore command_status di SMPP](https://www.broadnet.me/it/reference/smpp-command-status-errors)
- [Operazioni di bind SMPP](https://www.broadnet.me/it/reference/smpp-bind-operations)
- [Best practice di integrazione SMPP](https://www.broadnet.me/it/reference/smpp-integration-best-practices)
- [Ricerca codici di errore SMPP (strumento gratuito)](https://www.broadnet.me/it/tools/smpp-error-codes)
- [Checklist di integrazione SMPP (guida)](https://www.broadnet.me/it/guides/smpp-integration-checklist)