enquire_link (0x00000015) est un message de maintien (keepalive) léger qui confirme qu'une session SMPP liée est toujours saine sur TCP. Le débit est régi par deux limites : la fenêtre (combien de PDU peuvent être non acquittées à la fois) et le plafond de TPS du fournisseur. Dépasser le débit renvoie ESME_RTHROTTLED (0x00000058) ; la solution est de temporiser.
bind_transceiverOuvrir et authentifier la sessionbind_transceiver_respSession acceptéesubmit_smEnvoyer un messagesubmit_sm_respAccepté, ID du message renvoyédeliver_smAccusé de réception ou message entrantdeliver_sm_respConfirméenquire_linkKeepalive en cas d'inactivité
Maintien de session par enquire_link
Une session SMPP liée peut rester inactive de longues périodes, et une connexion TCP semi-ouverte paraît vivante au niveau du socket. enquire_link résout cela : chaque pair l'envoie sur un minuteur d'inactivité (couramment toutes les 30–60 secondes) et attend rapidement un enquire_link_resp. Une réponse manquante signifie que la session est morte — fermez la connexion TCP et reconnectez-vous avec temporisation. C'est le seul moyen fiable de détecter un lien rompu silencieusement.
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 fenêtre : PDU non acquittées en attente
Le SMPP est asynchrone : vous pouvez envoyer de nombreuses PDU submit_sm avant l'arrivée de leur submit_sm_resp. La taille de fenêtre plafonne le nombre de PDU pouvant être en attente (non acquittées) simultanément. Lorsque la fenêtre est pleine, vous devez suspendre les submits jusqu'à ce qu'une réponse libère un emplacement. Émettre au-delà de la fenêtre est une cause majeure de throttling et de PDU perdues. La taille de fenêtre se convient avec le fournisseur — il n'y a pas de valeur par défaut unique dans le protocole.
Throttling et TPS
Indépendamment de la fenêtre, le fournisseur impose un débit maximal de messages — transactions par seconde (TPS) — par bind ou par compte. Le dépasser renvoie ESME_RTHROTTLED (0x00000058). La bonne réaction est de ralentir : suspendre, temporiser avec gigue, et reprendre sous le plafond. Ne réémettez jamais une PDU throttled immédiatement et n'ouvrez pas de binds supplémentaires pour contourner la limite — les deux risquent la suspension du compte. En v5.0, le SMSC peut en outre signaler la congestion via le TLV congestion_state pour que les ESME ralentissent de façon préventive.
| Limite | Régit | Signal de dépassement |
|---|---|---|
| Taille de fenêtre | PDU non acquittées en transit | Contre-pression / PDU perdues |
| Plafond de TPS | Messages par seconde | ESME_RTHROTTLED (0x58) |
| Nombre de binds | Sessions parallèles | Liaison refusée / action sur le compte |
Ajuster pour un débit soutenu
Le débit réel est à peu près la taille de fenêtre divisée par la latence aller-retour, plafonnée par le TPS. Une fenêtre plus grande aide sur les liens à forte latence ; davantage de binds n'aide que si le fournisseur les provisionne. Instrumentez l'occupation de la fenêtre, la latence submit/réponse et le taux d'erreurs de throttling, et traitez une hausse du taux d'ESME_RTHROTTLED comme le signal de réduire le débit d'émission plutôt que de forcer davantage.
Questions fréquemment posées
À quelle fréquence envoyer enquire_link ?
Couramment toutes les 30–60 secondes sur un minuteur d'inactivité. Envoyez-le lorsque la session est restée silencieuse, et traitez un enquire_link_resp manquant dans votre délai comme une session morte à reconnecter.
Qu'est-ce que la taille de fenêtre SMPP ?
La fenêtre est le nombre maximal de PDU que vous pouvez avoir en attente (envoyées mais pas encore acquittées) simultanément. Elle se négocie avec votre fournisseur plutôt que d'être fixée par le protocole ; suspendez les submits quand la fenêtre est pleine.
Comment corriger ESME_RTHROTTLED ?
Réduisez votre débit d'émission. Suspendez, temporisez avec gigue, et reprenez sous le plafond de TPS du fournisseur. Ne réémettez pas immédiatement et n'ouvrez pas de binds supplémentaires pour contourner la limite — les deux peuvent vous faire throttler plus fort ou suspendre le compte.
Une fenêtre plus grande augmente-t-elle mon TPS ?
Jusqu'à un certain point. Le débit est à peu près la taille de fenêtre divisée par le temps aller-retour, mais il reste plafonné par le TPS du fournisseur. Une fenêtre plus grande sert surtout à masquer la latence sur les liens à fort RTT.
Qu'est-ce que congestion_state en SMPP v5.0 ?
La v5.0 ajoute un TLV congestion_state qui permet au SMSC d'annoncer sa charge (0–100). Un ESME coopératif le lit et ralentit de façon préventive avant d'atteindre un throttling brutal, lissant ainsi le débit sous charge.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.