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.
bind_transceiverAprire e autenticare la sessionebind_transceiver_respSessione accettatasubmit_smInviare un messaggiosubmit_sm_respAccettato, ID messaggio restituitodeliver_smRicevuta di consegna o messaggio in entratadeliver_sm_respConfermatoenquire_linkKeepalive durante l'inattività
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.
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.
| 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.
Specifiche della fonte
Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.