# Boas práticas de integração SMPP

> 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.

- URL canônico: https://www.broadnet.me/pt/reference/smpp-integration-best-practices
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

Como construir uma integração SMPP que se mantém fiável em produção: estratégia de bind, disciplina de sequence_number, janela, repetições com recuo, idempotência, tratamento de DLR e reconexão.

## 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 de correlação e controlo de fluxo a manter*

| 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.

## Fontes

- [SMPP v3.4 specification](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v5.0 specification](https://smpp.org/SMPP_v5.pdf)
- [3GPP TS 23.040 — SMS technical realization](https://www.3gpp.org/dynareport/23040.htm)

## Relacionados

- [Lista de verificação (guia) para integração SMPP](https://www.broadnet.me/pt/guides/smpp-integration-checklist)
- [enquire_link SMPP e throttling](https://www.broadnet.me/pt/reference/smpp-enquire-link-throttling)
- [Códigos de erro command_status SMPP](https://www.broadnet.me/pt/reference/smpp-command-status-errors)
- [Relatórios de entrega SMPP (formato DLR)](https://www.broadnet.me/pt/reference/smpp-delivery-receipts-dlr)
- [Documentação do desenvolvedor](https://www.broadnet.me/pt/developers)