O enquire_link (0x00000015) é um keepalive leve que confirma que uma sessão SMPP bound continua saudável sobre TCP. O débito é governado por dois limites: a janela (quantos PDUs podem estar por confirmar de cada vez) e o teto de TPS do fornecedor. Exceder a taxa devolve ESME_RTHROTTLED (0x00000058); a solução é recuar.
bind_transceiverAbrir e autenticar a sessãobind_transceiver_respSessão aceitasubmit_smEnviar uma mensagemsubmit_sm_respAceito, ID da mensagem devolvidadeliver_smRelatório de entrega ou mensagem recebidadeliver_sm_respConfirmadoenquire_linkKeepalive em modo ocioso
Keepalive com enquire_link
Uma sessão SMPP bound pode ficar inativa durante longos períodos, e uma ligação TCP meio-aberta parece viva ao nível do socket. O enquire_link resolve isto: qualquer dos pares envia-o num temporizador de inatividade (comummente a cada 30–60 segundos) e espera prontamente um enquire_link_resp. Uma resposta em falta significa que a sessão está morta — desfaça a ligação TCP e volte a ligar com recuo. É a única forma fiável de detetar uma ligação silenciosamente quebrada.
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)A janela: PDUs pendentes por confirmar
O SMPP é assíncrono: pode enviar muitos PDUs submit_sm antes de o seu submit_sm_resp chegar. O tamanho da janela limita quantos podem estar pendentes (por confirmar) de cada vez. Quando a janela está cheia, tem de suspender os submits até uma resposta libertar um lugar. Disparar para além da janela é uma das principais causas de limitação de taxa e de PDUs descartados. O tamanho da janela é acordado com o fornecedor — não há um único valor por omissão do protocolo.
Limitação de taxa e TPS
Separadamente da janela, o fornecedor impõe uma taxa máxima de mensagens — transações por segundo (TPS) — por bind ou por conta. Excedê-la devolve ESME_RTHROTTLED (0x00000058). A resposta correta é abrandar: pausar, recuar com jitter e retomar abaixo do teto. Nunca repita imediatamente um PDU limitado nem abra binds extra para contornar o limite — ambos arriscam a suspensão da conta. Na v5.0 o SMSC pode ainda anunciar congestão via o TLV congestion_state para que os ESMEs abrandem preventivamente.
| Limite | Rege | Sinal de ultrapassagem |
|---|---|---|
| Tamanho da janela | PDUs não confirmadas em trânsito | Backpressure / PDUs descartadas |
| Teto de TPS | Mensagens por segundo | ESME_RTHROTTLED (0x58) |
| Número de binds | Sessões paralelas | Bind recusado / ação na conta |
Afinação para débito sustentado
O débito real é aproximadamente o tamanho da janela dividido pela latência de ida e volta, limitado pelo teto de TPS. Uma janela maior ajuda em ligações de elevada latência; mais binds só ajudam se o fornecedor os aprovisionar. Instrumente a ocupação da janela, a latência de submit/resposta e a taxa de erros de limitação, e trate uma taxa crescente de ESME_RTHROTTLED como o sinal para reduzir a taxa de envio em vez de forçar mais.
Perguntas frequentes
Com que frequência devo enviar enquire_link?
Comummente a cada 30–60 segundos num temporizador de inatividade. Envie-o quando a sessão tem estado silenciosa e trate um enquire_link_resp em falta dentro do seu tempo-limite como uma sessão morta que tem de ser reconectada.
O que é o tamanho de janela do SMPP?
A janela é o número máximo de PDUs que pode ter pendentes (enviados mas ainda não confirmados) de cada vez. É negociado com o seu fornecedor em vez de fixado pelo protocolo; suspenda os submits quando a janela estiver cheia.
Como corrijo o ESME_RTHROTTLED?
Reduza a sua taxa de envio. Pause, recue com jitter e retome abaixo do teto de TPS do fornecedor. Não repita imediatamente nem abra binds adicionais para contornar o limite — ambos podem levar a uma limitação mais severa ou à suspensão da conta.
Uma janela maior aumenta o meu TPS?
Até certo ponto. O débito é aproximadamente o tamanho da janela dividido pelo tempo de ida e volta, mas continua limitado pelo teto de TPS do fornecedor. Uma janela maior serve sobretudo para ocultar a latência em ligações de RTT elevado.
O que é o congestion_state no SMPP v5.0?
A v5.0 acrescenta um TLV congestion_state que permite ao SMSC anunciar quão carregado está (0–100). Um ESME cooperante lê-o e abranda preventivamente antes de atingir uma limitação de taxa dura, suavizando o débito sob carga.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.