Une application peut soumettre un texte avant que le téléphone du destinataire soit joignable. Une connexion SMPP porte cette soumission et les opérations ultérieures qui rapportent ce qui s'est passé.
Que transporte la connexion ?
SMPP transporte les soumissions de messages, les messages entrants et les rapports de livraison entre les systèmes connectés.
Votre application peut se connecter à une passerelle qui achemine le trafic. Elle peut aussi se connecter directement à un centre de messages lorsque le fournisseur prend en charge cette configuration.
La référence SMPP décrit ces rôles et opérations. Un centre de messages stocke les textes et les transmet aux destinataires.
Une passerelle entre votre application et le centre ajoute une étape de routage supplémentaire. Le nom du protocole seul ne vous indique pas combien de systèmes traitent le message.
Comment fonctionne une session SMPP ?
Votre client ouvre une connexion. Il authentifie la session et la maintient disponible pour les opérations de messagerie.
L'étape d'authentification s'appelle un bind. Une session transmitter envoie des messages. Une session receiver les reçoit. Une session transceiver prend en charge les deux directions.
Utilisez le type de session que votre flux de travail exige. Une connexion en envoi seul ne peut pas remplacer une session de réception lorsque vous avez besoin d'opérations entrantes.
Votre client doit gérer la perte de connexion. Il doit aussi acquitter les opérations qu'il reçoit. Suivez les requêtes en attente de réponse afin qu'une réponse différée soit associée à la bonne requête.
Une réponse de soumission prouve-t-elle la livraison ?
Une réponse de soumission indique si le service connecté a accepté la soumission, et non si le téléphone a reçu le texte.
L'opération submit_sm soumet un message. La réponse submit_sm_resp correspondante rapporte le résultat de cette requête.
Les messages entrants et les accusés de réception peuvent arriver via deliver_sm. La référence des accusés de réception explique les opérations de réception et leur contenu.
Séparez le résultat de soumission du résultat de livraison dans votre application. Un message peut être accepté puis échouer parce que le destinataire reste injoignable.
Qu'est-ce qui change lorsque j'utilise une HTTP API à la place ?
HTTP expose les opérations de requête et de réponse sans exiger de votre application qu'elle gère un bind SMPP.
Votre application doit toujours gérer les réessais. Elle doit aussi traiter les résultats de livraison ultérieurs. HTTP ne transforme pas la livraison asynchrone d'un opérateur en garantie synchrone.
Avec Bird, vous soumettez via POST /v1/sms/messages et suivez l'identifiant de message renvoyé. Le guide d'envoi explique la réponse d'acceptation 202. Événements SMS fournit les rapports de livraison ultérieurs.
Ces responsabilités API sont distinctes de la gestion d'une connexion SMPP vers un fournisseur. API et passerelles explique les différentes couches.
L'utilisation de SMPP rend-elle les fournisseurs interchangeables ?
Les fournisseurs ne sont pas interchangeables simplement parce qu'ils partagent un protocole. Ils peuvent prendre en charge des opérations, des encodages et des limites différents.
Testez les capacités utilisées par votre application avant de migrer le trafic. Un bind réussi ne prouve pas que chaque opération requise fonctionne chez ce fournisseur.
La référence passerelle recommande de tester le support d'implémentation et les performances. Conservez vos vérifications de livraison lorsque vous changez de connexion, plutôt que de traiter un nouveau point de terminaison comme une migration complète.
Quand choisir SMPP ?
Choisissez SMPP lorsqu'un système existant a besoin d'un bind persistant ou d'opérations entrantes propres à SMPP.
- Utilisez HTTP pour une nouvelle application sans exigence SMPP spécifique.
- Utilisez SMPP lorsqu'un système existant a besoin d'un bind persistant ou d'opérations entrantes propres à SMPP.
- Testez le support du fournisseur et les résultats de livraison avant de migrer le trafic de production.
En bref
Votre client gère une session.
Il authentifie la connexion et gère la reprise lorsque cette connexion échoue.
Soumission et livraison sont des opérations distinctes.
Une réponse de soumission réussie ne prouve pas que le terminal a reçu le message.
Le support varie selon les fournisseurs.
Testez les opérations, l'encodage et la capacité plutôt que de supposer que le protocole rend les fournisseurs interchangeables.
HTTP peut éviter la gestion de session SMPP.
HTTP évite de gérer un bind SMPP, tandis que votre application continue de traiter les événements de livraison.