Qu’est-ce que SMPP ? La session SMS
SMPP sans jargon : binds, fenêtres, PDU et le chemin de l’accusé, et pourquoi la forme de la session compte à volume.
SMPP est le protocole par lequel une plateforme échange des messages courts avec un centre de messagerie sur une session persistante. Un bind déclare la direction, la session porte une fenêtre de débit et les accusés reviennent sous forme de PDU. Ce n’est pas une API de requête et réponse.
Faits clés
- SMPP est une session persistante avec une direction de bind déclarée.
- Un bind porte une allocation de débit et une fenêtre de requêtes en cours.
- Une PDU a un en-tête de 16 octets et un corps qui dépend de la commande.
- Les accusés arrivent de façon asynchrone sur la session ; ils se rapprochent par message ID.
Sur cette page
Une session, pas un appel
SMPP maintient une connexion ouverte entre votre plateforme et un centre de messagerie. La plateforme s’authentifie une fois, déclare ce qu’elle veut faire, puis envoie des messages et reçoit des événements sur la même session. Le centre n’attend pas une nouvelle requête pour envoyer un accusé ou un message entrant ; il pousse une PDU quand il a quelque chose à signaler.
Cette forme convient à un flux régulier. Le coût par message est faible parce que l’état de la session est déjà établi et que le canal des accusés est déjà ouvert. Elle signifie aussi que votre client porte un état qu’un client HTTP n’a pas : état du bind, fenêtre en cours, cadence du keep-alive et comportement de reconnexion.
Le bind déclare une direction
Un bind, c’est la session authentifiée plus une direction. Un bind émetteur envoie des messages. Un bind récepteur reçoit les messages émis depuis le mobile et les accusés. Un bind émetteur-récepteur fait les deux sur une seule session. Le fournisseur émet des identifiants pour chaque bind et peut limiter le nombre de binds ouverts.
Montez en charge en ajoutant des binds, pas en poussant un bind au-delà de son allocation. Un bind porte une allocation de débit et une fenêtre de requêtes en cours. Si votre pic demande davantage, demandez un autre bind et répartissez le trafic. Un seul bind poussé au-delà de sa fenêtre produit limitation, timeouts et reprises qui ressemblent à une panne réseau mais naissent dans le client.
Bind, envoi, accusé
- Application (ESME)
- bind_transceiver Ouvrir la session
- SMSC
- submit_sm_resp Accepté pour remise
- Accusé de remise
Description textuelle
L’application ouvre un bind et le centre de messagerie répond. L’application envoie un message court avec submit_sm et reçoit submit_sm_resp avec un message ID. Plus tard, le centre envoie une PDU deliver_sm portant l’accusé de remise. L’application la confirme avec deliver_sm_resp. Un unbind ferme la session quand le travail est terminé.
La fenêtre est le contrat
La fenêtre est le nombre de requêtes que votre client peut avoir en cours avant d’attendre les réponses. Ce n’est pas une suggestion. Envoyez plus que la fenêtre ne le permet et le centre vous limite ; continuez au même rythme et la file grossit. Lisez le code de réponse de chaque envoi, ralentissez en cas de limitation et laissez la fenêtre se vider avant la rafale suivante.
Le trafic de keep-alive maintient la session en vie. Un client qui n’envoie jamais enquire_link peut rester sur une connexion morte jusqu’à l’échec du premier envoi. Un client qui se reconnecte immédiatement après chaque coupure peut marteler le fournisseur. Utilisez un backoff, plafonnez la cadence de reconnexion et alertez quand le bind est tombé plus longtemps que votre trafic ne le tolère.
Une PDU, champ par champ
- 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
- Texte
- Test
Description textuelle
Toute PDU commence par une longueur de commande de quatre octets, un command ID de quatre octets, un état de commande de quatre octets et un numéro de séquence de quatre octets. Le corps suit. Pour submit_sm, il porte les adresses source et destination, le message court, le codage des données et l’indicateur d’accusé enregistré. Les paramètres facultatifs voyagent en champs étiquette-longueur-valeur.
Une journée dans la vie d’un message
Le client ouvre un bind émetteur-récepteur et lit la réponse. Il envoie un message et conserve le message ID de la réponse. Le centre achemine le message vers le réseau de destination. Quelques minutes plus tard, une PDU deliver_sm arrive avec l’accusé : le message ID d’origine, un état et souvent un code réseau. Le client confirme l’accusé et rapproche l’état de son propre enregistrement.
Chaque étape a son mode de défaillance. Un bind peut être refusé pour de mauvais identifiants ou une mauvaise version d’interface. Un envoi peut être limité, refusé, ou accepté puis échouer dans l’accusé. Un accusé peut arriver après l’expiration du code. Concevez le client pour conserver le message ID, accepter un accusé tardif et laisser l’état de l’application faire foi sur ce que l’utilisateur a fait.
Décodez un accusé avant de déboguer une route
Collez un accusé de remise dans le décodeur SMPP et DLR et lisez les champs. Vérifiez le message ID, l’état, la date de fin et le code d’erreur. Si l’état n’est pas DELIVRD, le code d’erreur, lu dans la table des codes du fournisseur, peut indiquer si le numéro, le téléphone ou le réseau a refusé le message. Faites-le avant de demander au fournisseur de changer la route.
Accusés et débogage
Un accusé est asynchrone. Il arrive sur la session sous forme de PDU deliver_sm, et son format dépend du centre de messagerie. Les implémentations récentes portent l’état dans un champ étiquette-longueur-valeur message_state. Les anciennes placent un accusé texte dans le champ du message court, avec des paires clé-valeur comme id, stat et err. Analysez les deux au lieu d’en supposer un.
Rapprochez par message ID, pas par ordre d’arrivée. Deux messages envoyés à une seconde d’intervalle peuvent revenir dans l’ordre inverse, et une reprise peut produire un doublon. Conservez l’ID à l’envoi, mettez à jour l’enregistrement à l’arrivée de l’accusé et ignorez un second accusé pour le même ID sauf si son état est plus récent. Le guide de connexion en fait une séquence d’exploitation.
Vérifiez vos acquis
-
Pourquoi un second bind aide-t-il plus qu’une cadence de reprise plus élevée ?
Un bind porte une fenêtre. Ajouter un bind ajoute de la capacité ; réessayer contre une fenêtre pleine ajoute de la file et du délai.
-
D’où vient le message ID ?
Le centre de messagerie le renvoie dans submit_sm_resp. Conservez-le et rapprochez l’accusé ultérieur par cet ID.
-
Que prouve un accusé de remise ?
Que le réseau a accepté et remis le message vers le téléphone. Cela ne prouve pas qu’une personne l’a lu.
Les réponses s’affichent sur demande. Rien n’est noté, stocké ni envoyé.
Questions fréquentes
Faut-il SMPP pour commencer ?
Qu’est-ce qu’un bind ?
Qu’est-ce qu’une PDU ?
Peut-on utiliser SMPP sur l’internet public ?
Comment sont traités les messages longs ?
Voir aussi
- Se connecter en SMPP et en HTTP
Passer d’une route de test à la production sans casser les binds, les fenêtres ni les accusés : débit, keep-alive, codage, callbacks et pannes.
- Pack de modèles RFQ et RFP
Listes de champs pour les demandes de SMS en gros, eSIM et données, IoT et connectivité vers la Chine, avec une liste de contrôle en ligne.
- Rapport type de test de route
Exemple statique anonymisé d’un rapport de test de route : ce que vérifie un test de route, comment lire les échecs et ce qui déclenche une revue.
Produits associés
Passez à la pratique
Indiquez le trafic, la destination et la mesure nécessaire ; nous répondons avec l’étape suivante.