Uma integração SMPP robusta é sobre disciplina operacional, não apenas PDUs corretos: escolha o modo de bind certo, gira cuidadosamente o sequence_number e a janela, repita com recuo com jitter, torne a submissão idempotente para evitar dupla faturação, confirme cada deliver_sm e reconecte de forma limpa em caso de falha. Acerte nisto e os detalhes do protocolo tratam de si mesmos.
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
Estratégia de bind
Prefira um bind transceiver quando o fornecedor o permitir, para que uma ligação transporte submit e receção e simplifique a correlação de DLR. Acorde por escrito o número de binds concorrentes e o TPS por bind com o fornecedor antes de escalar. Confirme a versão SMPP negociada a partir do bind_resp e trate as falhas de bind explicitamente — repita estados transitórios do tipo ESME_RALYBND, mas trate ESME_RINVPASWD/ESME_RINVSYSID como erros fatais de configuração em vez de entrar em ciclo.
sequence_number e a janela
Atribua um sequence_number monotonamente crescente (1 até 0x7FFFFFFF, depois volta ao início) e use-o para correlacionar cada resposta ao seu pedido. Acompanhe os pedidos pendentes num mapa indexado por sequence_number com um tempo-limite, para que uma resposta que nunca chega seja detetada. Respeite a janela: limite os PDUs em voo por confirmar e suspenda os submits quando estiver cheia em vez de disparar às cegas, o que despoleta limitação de taxa.
| Estado | Porquê |
|---|---|
| Mapa de solicitações pendentes (por sequence_number) | Correlacionar respostas, detetar tempos limite |
| Contador de ocupação da janela | Backpressure antes de ESME_RTHROTTLED |
| Chave de idempotência por mensagem lógica | Impedir envios duplicados em novas tentativas |
| Estado do bind + hora do último enquire_link_resp | Detetar sessões inativas |
Repetições, recuo e idempotência
Repita as falhas transitórias (ESME_RMSGQFUL, ESME_RTHROTTLED, erros de sistema, tempos-limite) com recuo exponencial e jitter para que as tempestades de reconexão não se sincronizem entre workers. Não repita erros permanentes (endereço inválido, password inválida). Fundamental: torne a submissão idempotente: anexe a sua própria referência (por exemplo via user_message_reference) e desduplique, para que uma repetição após um tempo-limite ambíguo não faça dupla faturação nem dupla entrega.
Tratamento de relatórios de entrega
Peça registered_delivery apenas onde consome os recibos. Responda sempre deliver_sm_resp prontamente e processe de forma assíncrona. Correlacione os recibos pelo TLV receipted_message_id, normalizando os formatos de id em hexadecimal/decimal, e encerre uma mensagem apenas com um stat final. Mapeie os códigos err da rede para uma taxonomia normalizada para que a qualidade seja comparável entre rotas. Trate as notificações intermédias separadamente dos estados terminais.
Keepalive e reconexão
Envie enquire_link num temporizador de inatividade e trate uma resposta em falta como uma sessão morta. Em qualquer desligação, reconecte com recuo e jitter em vez de entrar em hot-loop. Na reconexão, retome a partir de um estado limpo: refaça o bind, reinicie o mapa de pedidos pendentes e confie na idempotência para resubmeter em segurança o que estava em voo. Instrumente o estado do bind, a ocupação da janela, a latência de submit/DLR e as taxas de código de erro, e alerte sobre todos eles.
Perguntas frequentes
Como devo atribuir o sequence_number?
Use um contador monotonamente crescente de 1 até 0x7FFFFFFF, depois volte ao início. Mantenha um mapa de sequence_numbers pendentes com tempos-limite para poder correlacionar cada resposta e detetar pedidos que nunca receberam uma.
Como evito dupla faturação nas repetições?
Torne a submissão idempotente. Anexe a sua própria referência (por exemplo user_message_reference), desduplique por ela e desenhe as repetições de modo a que um reenvio após um tempo-limite ambíguo seja reconhecido e suprimido em vez de entregue e faturado duas vezes.
Que erros SMPP devo repetir?
Repita os transitórios — ESME_RMSGQFUL, ESME_RTHROTTLED, erros de sistema e tempos-limite — com recuo exponencial e jitter. Não repita erros permanentes como ESME_RINVDSTADR ou ESME_RINVPASWD; corrija antes a entrada ou a configuração.
O que devo monitorizar num bind SMPP?
O estado do bind, o tempo desde o último enquire_link_resp, a ocupação da janela, a latência de submit e DLR e as taxas de erro por código (sobretudo ESME_RTHROTTLED). Alerte sobre limitação crescente ou uma janela bloqueada como sinais precoces de problema.
Como devo tratar a reconexão após uma sessão perdida?
Reconecte com recuo exponencial com jitter, refaça o bind, reinicie o mapa de pedidos pendentes e resubmeta as mensagens em voo confiando na idempotência para prevenir duplicados. Nunca faça hot-loop de reconexões, o que pode levar ao bloqueio do seu IP.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.