n schéma récurrent : une entreprise souscrit un abonnement pour 100 SMS par seconde, configure son application pour qu'elle envoie le paquet, et constate une latence de 12. La bande passante est suffisante. Le serveur est fonctionnel. Personne n'est limité en débit. Le trafic est simplement extrêmement lent, et le premier réflexe est toujours d'incriminer la route. Or, le problème vient presque toujours de la fenêtre de connexion.
SMPP est un protocole asynchrone que la plupart des intégrations exécutent par erreur de manière synchrone. Comprendre pourquoi fait toute la différence entre payer pour du débit et en bénéficier réellement.
Ce que la fenêtre est réellement
La fenêtre correspond au nombre de PDU que vous avez pu soumettre mais qui n'ont pas encore reçu d'accusé de réception, lors d'une liaison unique, à un instant donné. Envoyez un message submit_sm et le système SMSC répond par un message submit_sm_resp ; toutefois, le système SMPP ne vous oblige jamais à attendre cette réponse avant d'envoyer le message suivant. La fenêtre détermine l'avance maximale autorisée.
Avec une fenêtre de 1, vous envoyez un message, vous attendez, vous le recevez, puis vous envoyez à nouveau. Votre débit est alors limité par le temps d'aller-retour, et non par un quelconque accord commercial. Avec un aller-retour de 40 ms, cela représente 25 messages par seconde, indépendamment de votre contrat. Avec une fenêtre de 10, dix messages transitent simultanément et la même liaison supporte environ dix fois plus de trafic.
La taille de la fenêtre est le facteur déterminant le plus important du débit obtenu lors d'une liaison, et c'est le paramètre le plus souvent laissé à sa valeur par défaut dans une bibliothèque, ce qui limite silencieusement une intégration bien en deçà du débit convenu.
Pourquoi tant de bibliothèques utilisent-elles une valeur par défaut ?
Une fenêtre de 1 est la valeur par défaut sûre pour un développeur de bibliothèque. Elle ne nécessite ni état de corrélation, ni gestion des délais d'attente, ni réordonnancement : chaque requête a exactement une réponse en attente, si bien qu'un client novice peut interpréter SMPP comme une requête/réponse sans même s'en apercevoir. Ce système fonctionne, est facile à comprendre, mais lent. De nombreuses bibliothèques clientes SMPP sont distribuées ainsi, et cette valeur n'est jamais remise en question car tout semble fonctionner correctement : les messages arrivent bien, mais lentement.
Ce sont les numéros de séquence qui rendent une fenêtre possible
Chaque PDU SMPP contient un sequence_number dans son en-tête de 16 octets. Lorsque plusieurs requêtes sont traitées simultanément, ce numéro est le seul élément permettant de relier chaque submit_sm_resp au submit_sm qui l'a déclenché. Les réponses n'étant pas garanties d'arriver dans l'ordre d'envoi des requêtes, un client utilisant une fenêtre de traitement supérieure à 1 doit conserver une liste des numéros de séquence en attente et effectuer la correspondance à la réception.
Deux règles sont essentielles. Ne jamais réutiliser un numéro de séquence pendant son transfert : une réponse tardive à un numéro réutilisé sera attribuée au mauvais message. Et toujours imposer un délai d’expiration aux entrées : si aucune réponse n’arrive, le créneau horaire doit être libéré, faute de quoi la fenêtre de réponse effective se réduit à zéro au fil de la session, ce qui provoque le symptôme exaspérant d’une liaison qui se met en place rapidement et s’aggrave au fil des heures.
Vous pouvez observer ce processus champ par champ dans notre simulateur de session SMPP — il affiche le sequence_number dans l'en-tête de chaque PDU, et quelle réponse répond à quelle requête.
La taille de la fenêtre et le TPS sont des limites différentes
Ces deux notions sont souvent confondues. Le TPS (Total Processing Secondary) est une limite de débit imposée par l'opérateur : le nombre de soumissions par seconde, mesuré sur une période donnée. La fenêtre SMPP correspond à une limite de concurrence que vous configurez : le nombre d'unités de données de protocole (PDU) en attente à un instant donné. Ces deux notions interagissent, mais leur nombre est différent.
La relation est approximativement la suivante : débit de transactions par seconde (TPS) atteignable ≈ fenêtre ÷ temps d'aller-retour. Une fenêtre de 10 avec un temps d'aller-retour de 50 ms permet d'atteindre environ 200 TPS. Si l'opérateur limite votre débit à 100 TPS, vous atteindrez cette limite et recevrez ESME_RTHROTTLED pour le dépassement. Si l'opérateur autorise 500 TPS et que votre fenêtre est de 10, vous n'atteindrez jamais 500 TPS, quel que soit le volume de trafic que vous fournissez : vous êtes limité par la concurrence, et non par le débit.
| Fenêtre | Aller-retour | Plafond | Symptôme |
|---|---|---|---|
| 1 | 40 ms | ~25 TPS | Le tarif contractuel n'a jamais été atteint ; le lien semble inactif. |
| 10 | 40 ms | ~250 TPS | Sain pour la plupart des expéditeurs d'entreprise |
| 50 | 40 ms | ~1 250 TPS | Uniquement si l'opérateur l'a accepté ; sinon, attendez-vous à une limitation de débit. |
| 10 | 250 ms | ~40 TPS | Problème de latence : agrandissez la fenêtre ou rapprochez-vous. |
Lecture correcte de ESME_RTHROTTLED
L'erreur ESME_RTHROTTLED (0x00000058) indique que vous avez dépassé le débit d'envoi convenu. Il ne s'agit ni d'un rejet du message, ni d'une erreur de routage. La solution consiste à patienter et à réessayer d'envoyer le message. Considérer cette erreur comme définitive entraîne la perte silencieuse de trafic que l'opérateur aurait accepté ultérieurement.
C'est aussi le signe que votre fenêtre d'exécution est désormais trop large pour le débit actuel. Si l'augmentation de cette fenêtre a entraîné une limitation du débit plutôt qu'une augmentation du débit global, la contrainte est passée de la concurrence au contrat, et la prochaine discussion sera d'ordre commercial plutôt que technique.
enquire_link : l'autre raison lie la mort
Une liaison qui n'envoie rien ressemble trait pour trait à une liaison dont la connexion TCP s'est interrompue silencieusement : les délais d'expiration NAT et les pare-feu avec état interrompent les sessions inactives sans prévenir les deux extrémités. L'envoi de enquire_link toutes les 30 à 60 secondes prouve que la connexion est toujours utilisable dans les deux sens. Si vous manquez la fenêtre temporelle prévue par l'opérateur, l'envoi de SMSC entraînera la déconnexion, généralement au pire moment.
Envoyez enquire_link sur la même liaison que celle utilisée pour la soumission, répondez rapidement à la réponse enquire_link de SMSC et considérez une réponse manquée comme une session interrompue : unbind, reconnectez-vous et reprenez la connexion. Un client qui soumet continuellement des données à une socket semi-ouverte provoque l'incident classique où tout semble fonctionner correctement, mais aucune donnée n'est transmise.
Comment dimensionner une fenêtre en pratique
- Mesurez le temps d'aller-retour sur la liaison que vous utilisez réellement, et non depuis votre ordinateur portable. Envoyez un seul message avec une fenêtre de 1 et une plage horaire de submit_sm à submit_sm_resp.
- Divisez votre débit contractuel de messages par seconde (TPS) par le nombre de messages par seconde qu'un aller-retour permet. Ce quotient représente votre fenêtre de traitement minimale viable.
- Ajoutez une marge de sécurité — arrondissez à l'entier supérieur, puis ajoutez environ 50 % — car le temps d'aller-retour n'est pas constant et une fenêtre dimensionnée exactement à la moyenne sera moins performante à la médiane.
- Augmentez la puissance par paliers, et non d'un coup, et surveillez l'apparition de ESME_RTHROTTLED. La première réduction de puissance soutenue vous indiquera la limite réelle de l'opérateur.
- Veuillez confirmer la valeur auprès de l'opérateur. Certains systèmes SMSC imposent une durée maximale de fenêtre par liaison et, au-delà de cette limite, mettront silencieusement en file d'attente ou abandonneront les requêtes sans avertissement.
- Ensuite, et seulement ensuite, envisagez une seconde liaison. Les liaisons multiples augmentent la concurrence, mais aussi les risques d'échec d'une session.
Quand plus de liens l'emportent sur une plus grande fenêtre
Il existe une limite à la capacité d'une connexion TCP. Au-delà de quelques centaines d'unités de données de protocole (PDU) en attente, les pannes deviennent problématiques : un simple problème de socket peut entraîner la perte de tout le trafic, le blocage en tête de file devient visible et la récupération après une interruption nécessite la relecture d'un grand nombre de paquets en transit. La plupart des opérateurs préfèrent plusieurs connexions de taille modérée à une seule connexion excessive, et la plupart vous indiqueront la configuration qu'ils privilégient si on leur pose la question.
Le traitement par classe de trafic est préférable à une répartition arbitraire. En séparant les codes d'accès à usage unique et urgents du marketing de masse, on évite qu'une campagne marketing ne retarde la réception d'un code de connexion ; il s'agit donc d'une décision d'optimisation du débit qui relève en réalité du produit.
Liste de vérification avant de blâmer la route
- Quelle est la fenêtre configurée, et quelqu'un l'a-t-il définie délibérément ?
- Les numéros de séquence en attente ont-ils expiré puis été libérés ?
- Le processus enquire_link s'exécute-t-il à l'intervalle attendu par l'opérateur ?
- Les réponses ESME_RTHROTTLED sont-elles retentées avec un délai d'attente, ou sont-elles comptabilisées comme des échecs ?
- Le temps de trajet aller-retour mesuré correspond-il à ce que vous aviez supposé lors du dimensionnement de la fenêtre ?
- Les accusés de réception (deliver_sm) sont-ils acquittés rapidement ? Un flux d’accusés de réception non acquittés peut également bloquer la session.
Foire aux questions
Quelle est une bonne taille de fenêtre SMPP ?
Il n'existe pas de valeur universelle, car la valeur optimale dépend de votre temps d'aller-retour et de votre débit contractuel. Pour le trafic d'entreprise, un point de départ pratique est de 10, puis augmentez-la jusqu'à atteindre votre débit contractuel ou jusqu'à constater un nombre anormalement élevé de requêtes. En calculant la valeur comme suit : débit contractuel × temps d'aller-retour, plus une marge d'environ 50 %, la plupart des intégrations fonctionnent correctement dès la première tentative.
Une fenêtre plus grande augmente-t-elle mon débit sans limite ?
Non. Dès que la fenêtre est suffisamment grande pour atteindre la limite de débit de l'opérateur, toute augmentation supplémentaire génère ESME_RTHROTTLED au lieu de nouveaux messages. La fenêtre supprime un goulot d'étranglement lié à la concurrence ; elle ne peut pas augmenter le plafond commercial.
Pourquoi mon débit se dégrade-t-il sur plusieurs heures plutôt qu'immédiatement ?
Il s'agit du symptôme classique des numéros de séquence en attente qui n'expirent jamais. Chaque réponse manquante occupe définitivement un emplacement de fenêtre, ce qui réduit progressivement la taille effective de la fenêtre au fil de la session, jusqu'à ce que la liaison se comporte comme si la fenêtre était de taille 1. La libération des emplacements lors d'un délai d'expiration résout le problème.
ESME_RTHROTTLED est-il une panne définitive ?
Non, et considérer cela comme une perte de trafic est contre-productif. Cela signifie que vous avez dépassé le débit convenu à ce moment précis. Réduisez la fréquence, réessayez d'envoyer le même message, et si la limitation persiste, réduisez la fenêtre d'envoi ou renégociez le débit.
À quelle fréquence dois-je envoyer enquire_link ?
L'intervalle habituel est de 30 à 60 secondes, et cette valeur doit correspondre aux attentes de l'opérateur. L'objectif est de vérifier qu'une session TCP potentiellement inactive est toujours active dans les deux sens avant qu'un NAT ou un pare-feu ne la ferme silencieusement.
Dois-je utiliser un grand bind ou plusieurs plus petits ?
Plusieurs connexions modérées sont généralement plus saines qu'une seule très importante, car une panne de socket ne vous coûte alors qu'une fraction de votre capacité au lieu de la totalité. Il est conseillé de segmenter le trafic par classe (les codes d'accès critiques en temps réel séparément du trafic plus important) afin qu'un pic de trafic marketing ne retarde pas la transmission d'un code de connexion.
La fenêtre a-t-elle également une incidence sur les accusés de réception de livraison ?
Oui, dans l'autre sens. Le serveur SMSC vous envoie des accusés de réception deliver_sm, et si votre application tarde à renvoyer les accusés de réception deliver_sm_resp, le flux d'accusés de réception s'engorge. Lors d'une liaison transceiver-récepteur, cette congestion peut affecter toute la session ; il est donc important d'accuser réception rapidement, même si vous traitez les accusés de réception de manière asynchrone.
Où puis-je observer ce comportement sans me connecter à un véritable SMSC ?
Notre script simulateur de session SMPP simule une session SMPP 3.4 complète dans le navigateur (liaison, soumission, accusé de réception asynchrone, enquire_link et unbind) et affiche les champs de chaque PDU mappés sur les octets correspondants sur le réseau. Aucune connexion n'est établie et aucune donnée n'est envoyée.
La version courte
Si une liaison présente des performances insuffisantes, vérifiez la fenêtre avant de vérifier le réseau. SMPP est asynchrone par conception et la plupart des intégrations l'exécutent de manière synchrone par erreur. Dimensionnez la fenêtre en fonction du temps d'aller-retour mesuré et du débit contractuel, définissez un délai d'expiration pour vos numéros de séquence, assurez-vous que enquire_link fonctionne correctement et relancez ESME_RTHROTTLED avec un délai d'attente. Cette séquence résout la grande majorité des problèmes de débit sans intervention humaine sur le routage.