Che cos’è SMPP? Il protocollo di sessione per gli SMS
SMPP spiegato senza gergo: bind, finestre, PDU e percorso delle ricevute, e perché la forma della sessione conta quando i volumi crescono.
SMPP è il protocollo con cui una piattaforma scambia messaggi brevi con un centro messaggi tramite una sessione persistente. Un bind dichiara la direzione, la sessione prevede una finestra di throughput e le ricevute di consegna tornano come PDU. Non è un’API a richiesta e risposta.
Dati essenziali
- SMPP è una sessione persistente con una direzione di bind dichiarata.
- Un bind prevede un’assegnazione di throughput e una finestra di richieste in sospeso.
- Un PDU ha un’intestazione di 16 byte e un corpo specifico del comando.
- Le ricevute di consegna arrivano in modo asincrono sulla sessione; vanno abbinate tramite l’ID del messaggio.
In questa pagina
Una sessione, non una chiamata
SMPP mantiene aperta una connessione tra la piattaforma del cliente e un centro messaggi. La piattaforma si autentica una sola volta, dichiara che cosa intende fare e poi invia messaggi e riceve eventi sulla stessa sessione. Il centro messaggi non attende una nuova richiesta per inviare una ricevuta o un messaggio in entrata: invia un PDU quando ha qualcosa da segnalare.
Questa forma si adatta a un flusso costante. L’overhead per messaggio è ridotto perché lo stato della sessione è già stabilito e il canale delle ricevute è già aperto. Significa anche che il client gestisce uno stato che un client HTTP non gestisce: stato del bind, finestra delle richieste in corso, tempi di keep-alive e comportamento di riconnessione.
I bind dichiarano una direzione
Un bind è la sessione autenticata più una direzione. Un bind transmitter invia messaggi. Un bind receiver riceve messaggi originati dal mobile e ricevute. Un bind transceiver svolge entrambe le funzioni su una sola sessione. Il provider rilascia le credenziali per ciascun bind e può limitare il numero di bind che è possibile aprire.
Si scala aggiungendo bind, non spingendo un bind oltre la sua assegnazione. Un bind prevede un’assegnazione di throughput e una finestra di richieste in sospeso. Se il picco richiede di più, conviene chiedere un altro bind e distribuire il traffico. Un singolo bind spinto oltre la sua finestra produce throttling, timeout e nuovi tentativi che sembrano un guasto di rete ma hanno origine nel client.
Bind, invio, ricevuta
- Applicazione (ESME)
- bind_transceiver Aprire la sessione
- SMSC
- submit_sm_resp Accettato per la consegna
- Ricevuta di consegna
Descrizione testuale
L’applicazione apre un bind e il centro messaggi risponde. L’applicazione invia un messaggio breve con submit_sm e riceve submit_sm_resp con un ID del messaggio. Più tardi, il centro messaggi invia un PDU deliver_sm che contiene la ricevuta di consegna. L’applicazione ne conferma la ricezione con deliver_sm_resp. Un unbind chiude la sessione al termine del lavoro.
La finestra è il contratto
La finestra è il numero di richieste che il client può avere in sospeso prima di attendere le risposte. Non è un suggerimento. Se si inviano più richieste di quante la finestra ne consenta, il centro messaggi applica il throttling; se si continua a ripetere allo stesso ritmo, la coda cresce. Occorre leggere il codice di risposta di ogni invio, rallentare in caso di throttling e lasciare svuotare la finestra prima del picco successivo.
Il traffico di keep-alive mantiene aperta la sessione. Un client che non invia mai enquire_link può restare su una connessione interrotta finché il primo invio non fallisce. Un client che si riconnette subito dopo ogni interruzione può sovraccaricare il provider. Conviene usare un backoff, limitare la frequenza di riconnessione e generare un avviso quando il bind resta fuori servizio più a lungo di quanto il traffico possa tollerare.
Un PDU, campo per campo
- command_length
- 53
- command_id
- 0x00000004
- command_status
- 0x00000000
- sequence_number
- 1
- service_type
- source_addr_ton
- 1
- source_addr_npi
- 1
- source_addr
- 12345
- dest_addr_ton
- 1
- dest_addr_npi
- 1
- destination_addr
- 15551234567
- esm_class
- 0x00
- protocol_id
- 0x00
- priority_flag
- 0
- schedule_delivery_time
- validity_period
- registered_delivery
- 0x01
- replace_if_present_flag
- 0x00
- data_coding
- 0x00
- sm_default_msg_id
- 0x00
- sm_length
- 4
- short_message
- 54657374
- Testo
- Test
Descrizione testuale
Ogni PDU inizia con una lunghezza del comando di quattro byte, un ID del comando di quattro byte, uno stato del comando di quattro byte e un numero di sequenza di quattro byte. Segue il corpo. Per submit_sm contiene gli indirizzi di origine e di destinazione, il messaggio breve, la codifica dei dati e il flag di consegna registrata. I parametri opzionali viaggiano come campi tag-length-value.
Una giornata nella vita di un messaggio
Il client apre un bind transceiver e legge la risposta al bind. Invia un messaggio e memorizza l’ID del messaggio contenuto nella risposta. Il centro messaggi instrada il messaggio verso la rete di destinazione. Alcuni minuti dopo arriva un PDU deliver_sm con la ricevuta: l’ID del messaggio originale, uno stato e spesso un codice di rete. Il client conferma la ricezione della ricevuta e riconcilia lo stato con il proprio record.
Ogni passaggio ha una propria modalità di errore. Un bind può essere rifiutato per credenziali errate o per una versione dell’interfaccia non corretta. Un invio può essere sottoposto a throttling, rifiutato, oppure accettato e poi fallire nella ricevuta. Una ricevuta può arrivare dopo la scadenza del codice. Il client va progettato per memorizzare l’ID del messaggio, accettare una ricevuta tardiva e lasciare che lo stato dell’applicazione resti la fonte di riferimento per ciò che l’utente ha fatto.
Decodificare una ricevuta prima di analizzare una rotta
Incollare una ricevuta di consegna nel decodificatore SMPP e DLR e leggerne i campi. Verificare l’ID del messaggio, lo stato, la data di completamento e il codice di errore. Se lo stato non è DELIVRD, il codice di errore, letto in base alla tabella dei codici del provider, può indicare se il messaggio è stato rifiutato dal numero, dal terminale o dalla rete. Farlo prima di chiedere al provider di cambiare la rotta.
Ricevute e debug
Una ricevuta è asincrona. Arriva sulla sessione come PDU deliver_sm e il suo formato dipende dal centro messaggi. Le implementazioni più recenti riportano lo stato in un campo tag-length-value message_state. Quelle meno recenti inseriscono una ricevuta testuale nel campo del messaggio breve, con coppie chiave-valore come id, stat ed err. Conviene analizzare entrambi i formati anziché presumerne uno.
L’abbinamento va fatto tramite l’ID del messaggio, non in base all’ordine di arrivo. Due messaggi inviati a un secondo di distanza possono tornare in ordine inverso, e una ripetizione può produrre un duplicato. Memorizzare l’ID al momento dell’invio, aggiornare il record all’arrivo della ricevuta e ignorare una seconda ricevuta per lo stesso ID, a meno che il suo stato non sia più recente. La guida alla connessione trasforma questi principi in una sequenza operativa.
Verifichi ciò che ha imparato
-
Perché un secondo bind è più utile di una frequenza di ripetizione più alta?
Un bind prevede una sola finestra. Aggiungere un bind aggiunge capacità; ripetere su una finestra piena aggiunge coda e ritardo.
-
Da dove proviene l’ID del messaggio?
Lo restituisce il centro messaggi in submit_sm_resp. Va memorizzato per abbinare la ricevuta successiva tramite quell’ID.
-
Che cosa dimostra una ricevuta di avvenuta consegna?
Che la rete ha accettato il messaggio e lo ha consegnato sul percorso verso il terminale. Non dimostra che una persona lo abbia letto.
Le risposte vengono mostrate su richiesta. Nulla viene valutato, salvato o inviato.
Domande frequenti
Serve SMPP per iniziare?
Che cos’è un bind?
Che cos’è un PDU?
È possibile usare SMPP sulla rete Internet pubblica?
Come vengono gestiti i messaggi lunghi?
Correlati
- Connessione via SMPP e HTTP
Portare una rotta di test in produzione senza compromettere bind, finestre o ricevute: bind, throughput, keep-alive, codifica, callback e gestione degli errori.
- Pacchetto di modelli RFQ e RFP
Elenchi dei campi per le richieste di SMS all’ingrosso, eSIM e dati, IoT e connettività verso la Cina, più la checklist online che si invia come RFQ.
- Report di esempio di test della rotta
Un esempio statico e privo di dati sensibili di report di test della rotta: che cosa verifica un test della rotta, come si leggono i fallimenti e che cosa attiva una revisione della rotta.
Prodotti correlati
Metterlo in pratica
Ci indichi il traffico, la destinazione e la misurazione di cui ha bisogno; le risponderemo con il passo successivo.