m padrão que vemos constantemente: uma empresa contrata 100 SMS por segundo, direciona a sua aplicação para o servidor de destino e regista apenas doze. A largura de banda está normal. O endereço SMSC está normal. Ninguém teve a sua velocidade limitada. O tráfego está simplesmente muito lento, e o primeiro instinto é sempre culpar a rota. Quase nunca é a rota. É a janela de tráfego.
SMPP é um protocolo assíncrono que a maioria das integrações executa acidentalmente de forma síncrona. Entender o porquê disso faz toda a diferença entre pagar por capacidade de processamento e realmente recebê-la.
O que a janela realmente é
A janela é o número de PDUs que você pode ter enviado, mas ainda não ter recebido confirmação, numa única conexão, em qualquer momento. Envie um submit_sm e o SMSC responderá com submit_sm_resp — mas o SMPP nunca exigiu que você esperasse por essa resposta antes de enviar a próxima mensagem. A janela é o quanto você pode avançar no tempo.
Com uma janela de 1, você envia, espera, recebe e envia novamente. A sua taxa de transferência agora é limitada pelo tempo de ida e volta (RTT), e não por qualquer acordo comercial prévio. Com um RTT de 40 ms, isso corresponde a 25 mensagens por segundo — independentemente do que o seu contrato diga. Com uma janela de 10, você tem dez mensagens em trânsito simultaneamente, e o mesmo link transporta aproximadamente dez vezes mais tráfego do que a mesma conexão.
O tamanho da janela é o fator determinante mais importante da taxa de transferência obtida numa conexão (bind), e é a configuração que geralmente permanece com o valor padrão da biblioteca, o que limita silenciosamente a integração muito abaixo da taxa acordada.
Porque tantas bibliotecas usam uma como padrão?
Uma janela de 1 é o valor padrão seguro para um autor de biblioteca. Não requer estado de correlação, controlo de tempo limite ou reordenação: cada solicitação tem exatamente uma resposta pendente, então um cliente desavisado pode tratar SMPP como solicitação/resposta e nunca perceber a diferença. Funciona, é fácil de entender e é lento. Muitas bibliotecas cliente SMPP são distribuídas dessa forma, e o valor nunca é revisado porque nada parece estar quebrado — as mensagens chegam, apenas não rapidamente.
Os números de sequência são o que tornam uma janela possível.
Cada PDU SMPP carrega um sequence_number no seu cabeçalho de 16 octetos. Quando várias submissões estão em andamento simultaneamente, esse número é a única coisa que vincula cada submit_sm_resp ao submit_sm que o originou. Não há garantia de que as respostas cheguem na ordem em que as solicitações foram enviadas; portanto, um cliente que execute uma janela maior que 1 deve manter um mapa dos números de sequência pendentes e fazer a correspondência assim que chegarem.
Duas regras são importantes. Nunca reutilize um número de sequência enquanto ele ainda estiver em trânsito — uma resposta tardia a um número reciclado será atribuída à mensagem errada. E sempre defina um tempo limite para as entradas: se uma resposta nunca chegar, o slot deve ser liberado ou a janela efetiva se reduzirá a zero ao longo da sessão, o que produz o sintoma irritante de uma vinculação que começa rápida e se deteriora ao longo de horas.
Você pode acompanhar esse processo campo por campo em nosso simulador de sessão SMPP — ele mostra o sequence_number no cabeçalho de cada PDU e qual resposta está a atender a qual solicitação.
O tamanho da janela e o TPS são limites diferentes.
Esses conceitos são constantemente confundidos. TPS é um limite de taxa imposto pelo operador: submissões por segundo, medidas num determinado período. A janela SMPP é um limite de concorrência que você configura: PDUs pendentes num dado momento. Eles interagem, mas não representam o mesmo número.
A relação é aproximadamente a seguinte: TPS alcançável ≈ janela ÷ tempo de ida e volta. Uma janela de 10 com um tempo de ida e volta de 50 ms resulta em cerca de 200 TPS. Se a operadora limitar a sua capacidade a 100, você atingirá o limite e receberá ESME_RTHROTTLED pelo excesso. Se a operadora permitir 500 e a sua janela for de 10, você nunca verá 500, independentemente do volume de tráfego oferecido — você está limitado pela concorrência, não pela taxa de transferência.
| Janela | Ida e volta | Teto | Sintoma |
|---|---|---|---|
| 1 | 40 ms | ~25 TPS | A taxa contratada nunca foi atingida; o link parece inativo. |
| 10 | 40 ms | ~250 TPS | Adequado para a maioria dos remetentes corporativos. |
| 50 | 40 ms | ~1.250 TPS | Somente se a operadora concordar; caso contrário, espere limitação de velocidade. |
| 10 | 250 ms | ~40 TPS | Limitado pela latência — aumente a janela ou aproxime-se. |
Lendo ESME_RTHROTTLED corretamente
ESME_RTHROTTLED (0x00000058) significa que você excedeu a taxa de envio acordada. Não se trata de uma rejeição da mensagem nem de uma falha de encaminhamento. A resposta correta é recuar e tentar novamente com a mensagem — tratá-la como permanente descarta silenciosamente o tráfego que o operador teria aceitado momentos depois.
É também um sinal de que a sua janela agora é grande demais para a taxa que você está a utilizar. Se aumentar a janela resultou em limitação em vez de aumento de desempenho, a restrição passou de concorrência para contrato, e a próxima conversa será comercial em vez de técnica.
enquire_link: a outra razão liga a morte
Uma conexão que não envia nada é idêntica a uma conexão TCP que foi silenciosamente encerrada — timeouts de NAT e firewalls com estado descartam sessões ociosas sem avisar nenhuma das partes. A mensagem enquire_link a cada 30 a 60 segundos comprova que o socket ainda está utilizável em ambas as direções. Se você perder a janela de espera do operador, a mensagem SMSC irá descartá-lo, geralmente no momento menos conveniente.
Envie enquire_link no mesmo bind em que você submete os dados, responda prontamente ao enquire_link do SMSC e trate uma resposta perdida como uma sessão encerrada: unbind, reconecte e retome. Um cliente que continua a enviar dados para um socket semiaberto produz o incidente clássico em que tudo parece normal, mas nada é entregue.
Como dimensionar uma janela na prática
- Meça o tempo de ida e volta no servidor que você realmente usa, não no seu laptop. Envie uma única mensagem com uma janela de 1 e cronometre de submit_sm a submit_sm_resp.
- Divida o seu TPS contratado pela quantidade de mensagens por segundo que uma viagem de ida e volta permite. Esse quociente representa a sua janela mínima viável.
- Adicione uma margem de segurança — arredonde para cima e depois adicione aproximadamente 50% — porque o tempo de ida e volta não é constante e uma janela dimensionada exatamente para a média terá um desempenho inferior na mediana.
- Aumente a potência gradualmente, não de uma vez, e fique atento ao sinal ESME_RTHROTTLED. A primeira redução de potência sustentada indica qual é o limite real do operador.
- Confirme o valor com o operador. Alguns sistemas SMSC impõem um limite máximo de tempo por vinculação e, ao ultrapassarem esse limite, enfileiram ou descartam silenciosamente as solicitações.
- Só então considere uma segunda vinculação. Vinculações múltiplas multiplicam a concorrência, mas também multiplicam as maneiras pelas quais uma sessão pode falhar.
Quando mais vínculos vencem uma janela maior
Existe um limite para o que uma conexão TCP deve suportar. Acima de algumas centenas de PDUs pendentes, as falhas se tornam problemáticas: um único problema de socket leva todo o tráfego consigo, o bloqueio de cabeçalho de fila se torna visível e a recuperação após uma queda significa reproduzir um grande conjunto de pacotes em trânsito. A maioria dos operadores prefere ver várias conexões moderadas a uma enorme, e a maioria dirá qual formato prefere se questionada.
Dividir por classe de tráfego em vez de arbitrariamente. Manter palavras-passe de uso único com tempo crítico numa vinculação separada do marketing em massa significa que uma explosão de marketing não pode atrasar um código de login — o que é uma decisão de desempenho que, na verdade, é uma decisão de produto.
Uma lista de verificação antes de culpar o percurso.
- Qual é a janela configurada e alguém a configurou deliberadamente?
- Os números de sequência pendentes expiraram e foram liberados?
- O programa enquire_link está a ser executado no intervalo esperado pela operadora?
- As respostas ESME_RTHROTTLED são repetidas com um intervalo de espera (backoff) ou contabilizadas como falhas?
- O tempo de viagem de ida e volta medido corresponde ao que você considerou ao dimensionar a janela?
- Os recibos (deliver_sm) estão a ser reconhecidos prontamente — um fluxo de recibos não reconhecidos também pode interromper a sessão?
Perguntas frequentes
Qual o tamanho ideal de uma janela SMPP?
Não existe um número universal, pois o valor ideal depende do seu tempo de ida e volta e da sua tarifa contratada. Um ponto de partida prático para tráfego corporativo é 10, e você pode aumentá-lo até atingir o TPS contratado ou começar a ver ESME_RTHROTTLED. Dimensionar como TPS contratado × tempo de ida e volta, mais uma margem de segurança de cerca de 50%, geralmente resolve a maioria das integrações na primeira tentativa.
Uma janela maior aumenta a minha taxa de transferência sem limite?
Não. Quando a janela de tempo é grande o suficiente para atingir o limite de taxa da operadora, aumentos adicionais produzem ESME_RTHROTTLED em vez de mais mensagens. A janela remove um gargalo de concorrência; ela não pode aumentar um limite comercial.
Porque a minha taxa de transferência diminui ao longo de horas em vez de imediatamente?
Este é o sintoma clássico de números de sequência pendentes que nunca expiram. Cada resposta que desaparece consome permanentemente um espaço na janela, de modo que a janela efetiva diminui ao longo da sessão até que a vinculação se comporte como se a janela fosse 1. Liberar espaços quando ocorre um tempo limite resolve o problema.
ESME_RTHROTTLED é um fracasso permanente?
Não, e considere isso como uma perda de tráfego. Significa que você excedeu a taxa acordada naquele instante. Recue, tente novamente a mesma mensagem e, se a limitação persistir, reduza a janela ou renegocie a taxa.
Com que frequência devo enviar enquire_link?
A cada 30 a 60 segundos é o intervalo usual, e o valor exato deve corresponder ao que o operador espera. O objetivo é comprovar que uma sessão TCP possivelmente ociosa ainda está ativa em ambas as direções antes que um NAT ou firewall a descarte silenciosamente.
Devo usar uma ligação grande ou várias menores?
Várias conexões moderadas geralmente são mais saudáveis do que uma única conexão muito grande, porque uma falha de socket custa apenas uma fração da sua capacidade, em vez de toda ela. Divida por classe de tráfego — palavras-passe críticas em relação ao tempo separadamente das conexões em massa — para que um pico de tráfego de marketing não atrase um código de login.
A janela de tempo também afeta os comprovativos de entrega?
Sim, na direção oposta. O SMSC envia recibos deliver_sm para você e, se a sua aplicação demorar para devolver deliver_sm_resp, o fluxo de recibos fica congestionado. Numa vinculação de transceptor, esse congestionamento pode afetar toda a sessão, portanto, confirme os recibos prontamente, mesmo que você os processe de forma assíncrona.
Onde posso observar esse comportamento sem me conectar a um SMSC real?
Nosso simulador de sessão SMPP percorre uma sessão completa do SMPP 3.4 no navegador — vinculação, envio, relatório de entrega assíncrono, enquire_link e unbind — e mostra os campos de cada PDU mapeados nos octetos reais na rede. Nada se conecta e nada é enviado.
A versão curta
Se uma conexão estiver com desempenho abaixo do esperado, verifique a janela antes de verificar a rede. SMPP é assíncrono por design e a maioria das integrações o executa de forma síncrona por engano. Dimensione a janela com base no tempo de ida e volta medido e na taxa contratada, defina o tempo limite dos seus números de sequência, mantenha enquire_link funcionando corretamente e tente novamente com ESME_RTHROTTLED com um intervalo de espera. Essa sequência resolve a grande maioria das reclamações de throughput sem que ninguém precise mexer numa rota.