# Simulatore di sessione SMPP.

- URL canonico: https://www.broadnet.me/it/tools/smpp-simulator
- Lingua: it
- Ultimo aggiornamento: 2026-10-21
- Editore: BroadNet (https://www.broadnet.me)
- Versione Markdown della pagina, generata dalla pagina pubblicata.

Strumento di sviluppo gratuito · Protocollo

Analizza una vera conversazione SMPP 3.4: la PDU che un ESME e un SMSC si scambiano effettivamente, byte per byte. Seleziona una PDU qualsiasi per visualizzare i suoi campi mappati sugli ottetti trasmessi.

**Questo non invia mai un messaggio**

Tutto ciò che appare in questa pagina viene elaborato dal tuo browser. Non viene stabilita alcuna connessione, non viene effettuata alcuna richiesta a BroadNet o a terzi e non viene inviato alcun messaggio di alcun tipo ad alcuna rete. Gli ID dei messaggi e i timestamp vengono ricavati dai tuoi input, quindi gli stessi input producono sempre lo stesso output: sono a scopo illustrativo e non rappresentano dati reali.

non vincolato

## Sessione

## Messaggio

segmenti 1 × 160

Fits one PDU (160 characters at this encoding).

## comportamento SMSC

Il caso normale: bind accettato, messaggio accettato, la ricevuta indica DELIVRD.

filo — ESME ⇄ SMSC 0 PDU

ESME SMSC

Ancora niente in transito. Avvia la sessione per osservare lo scambio di PDU tra ESME e SMSC, quindi seleziona uno qualsiasi di essi per visualizzarne i byte.

## Come si svolge effettivamente una sessione SMPP

1. **1 · Lega.** La tua applicazione apre una connessione TCP con l' SMSC e invia il comando bind_transceiver con un system_id e una password. Finché l' SMSC non risponde con command_status 0, non viene accettato nient'altro.
2. **2 · Invia.** Ogni messaggio è una PDU submit_sm. La risposta fornisce un message_id: si tratta di un'accettazione, non di una consegna.
3. **3 · Ricevuta.** Se ne hai fatto richiesta, l' SMSC in seguito invia un deliver_sm contenente esm_class 0x04 e un corpo di ricevuta che fa riferimento a tale message_id.
4. **4 · Mantieniti in vita.** enquire_link ogni 30-60 secondi verifica che la connessione sia ancora utilizzabile. Se lo si perde, l' SMSC interrompe la connessione.
5. **5 · Scollega.** Chiudi la chiamata con cortesia, in modo che l'operatore non la consideri una disconnessione anomala.

## Domande che gli ingegneri si pongono

**Questo simulatore invia un SMS reale?**

No. Nessuna parte della pagina apre una connessione o invia un messaggio. Ogni PDU e ogni risposta SMSC vengono calcolate nel browser in base ai valori inseriti, quindi gli stessi input producono sempre la stessa trascrizione. Si tratta di uno strumento didattico per il protocollo, non di uno strumento di invio.

**Che cos'è un bind in SMPP?**

Il bind è l'handshake di sessione tra un ESME (la tua applicazione) e l' SMSC (il centro messaggi dell'operatore). bind_transmitter può solo inviare, bind_receiver può solo ricevere e bind_transceiver fa entrambe le cose su un'unica connessione, che è la soluzione utilizzata dalla maggior parte delle integrazioni. Nessun altro messaggio viene accettato sulla sessione finché il bind non ha successo.

**A cosa serve la funzione registered_delivery?**

Impostando registered_delivery su 1, si richiede SMSC di confermare l'esito finale. Tale conferma arriva successivamente come una PDU deliver_sm separata contenente esm_class 0x04 — la ricevuta di consegna — che fa riferimento al message_id fornito in submit_sm_resp. Senza di essa, si viene a sapere solo che l' SMSC ha accettato il messaggio, non che un dispositivo mobile lo ha ricevuto.

**Perché il mio messaggio viene suddiviso in più segmenti?**

Un singolo PDU SMS contiene 160 caratteri nell'alfabeto GSM-7 o 70 in UCS-2. I testi più lunghi vengono concatenati: ogni parte cede 6 ottetti a un'intestazione dati utente in modo che il telefono possa riassemblarli, lasciando 153 o 67 caratteri per segmento. Un singolo carattere arabo o un'emoji obbliga l'intero messaggio a utilizzare UCS-2, motivo per cui un messaggio arabo di 100 caratteri occupa due segmenti.

**Qual è la differenza tra submit_sm_resp e una ricevuta di consegna?**

submit_sm_resp è sincrono e indica solo che l' SMSC ha accettato la PDU e le ha assegnato un message_id. La conferma di consegna arriva in modo asincrono, spesso dopo pochi secondi o minuti, e riporta l'esito reale: DELIVRD, UNDELIV, EXPIRED, REJECTD. Considerare submit_sm_resp come prova di consegna è l'errore più comune nella prima integrazione SMPP.

**Cos'è una finestra SMPP e perché limita la mia velocità di trasmissione?**

La finestra indica il numero PDU che è possibile aver inviato ma non ancora confermato in un singolo bind in un dato momento. Poiché SMPP è asincrono, non si attende ogni submit_sm_resp prima di inviare il successivo, ma la finestra limita la quantità di tempo che è possibile utilizzare in anticipo. Se il valore predefinito è 1, il bind si riduce a una modalità richiesta/risposta e la velocità di trasmissione si riduce a un solo messaggio per round trip, indipendentemente dalla frequenza concordata con l'operatore.

[Decodifica una PDU reale che hai catturato](https://www.broadnet.me/it/tools/smpp-pdu-decoder) [Riferimento al codice di errore SMPP](https://www.broadnet.me/it/tools/smpp-error-codes) [Panoramica del protocollo SMPP](https://www.broadnet.me/it/reference/smpp-protocol-overview) [Corso sui fondamenti SMPP](https://www.broadnet.me/it/academy/smpp-fundamentals) [Connettersi a BroadNet tramite SMPP](https://www.broadnet.me/it/developers/smpp)