SMPP frente a HTTP: qué conexión encaja

La decisión en un párrafo

Empiece con HTTP si el volumen es bajo, el tráfico va a ráfagas y el equipo ya opera endpoints web. Pase a SMPP cuando el tráfico sea un flujo constante, cuando la autenticación y el establecimiento de conexión por petición tengan un coste visible, o cuando los acuses deban llegar por la misma sesión transceptor que los envíos. Muchas plataformas usan ambos: SMPP para el flujo de envío y HTTP para los callbacks entrantes.

El protocolo no es el producto. La ruta, el registro del remitente y las pruebas en teléfonos deciden si un mensaje llega. SMPP y HTTP son dos formas de alcanzar el mismo centro de mensajes, y cualquiera de las dos se puede operar bien o mal.

La pregunta correcta no es qué protocolo es más nuevo. Es qué fallo puede ver y corregir su equipo a la velocidad que produce el tráfico. Un bind silencioso a las dos de la madrugada y un callback que falla a las dos de la madrugada son problemas operativos. Elija el que sus herramientas sepan diagnosticar.

El caudal sigue a la forma

Un bind SMPP se aprovisiona con una tasa de caudal y una ventana. Con la sesión abierta, un envío cuesta una PDU y una respuesta, sin un nuevo handshake. Eso hace que SMPP sea eficiente para un flujo sostenido y predecible para planificar capacidad: cuente los binds, lea la asignación y mantenga las peticiones en vuelo por debajo de la ventana.

HTTP paga la autenticación y el establecimiento de conexión en cada petición, aunque la reutilización de conexiones reduce el coste. La capacidad viene de la concurrencia, no de una ventana de bind, así que el cliente puede hacer una ráfaga y luego chocar con un límite de tasa o una cola. Esa flexibilidad encaja con campañas y aplicaciones de bajo volumen; también hace que el pico sea más difícil de razonar si el cliente no limita la concurrencia. Un límite de tasa y una ventana son controles distintos: uno limita peticiones por segundo, el otro peticiones en vuelo. El coste por petición se nota a volumen alto, no con unos miles de mensajes al día.

Los acuses y el entrante deciden la integración

SMPP entrega los acuses y los mensajes entrantes por un bind receptor o transceptor. El cliente debe mantener viva la sesión para recibirlos, emparejar cada acuse con el message ID guardado y responder con deliver_sm_resp. No hay un endpoint de callback que asegurar, pero sí una sesión que vigilar: un bind abierto y silencioso es un modo de fallo.

HTTP entrega los acuses y los mensajes entrantes a una URL. El receptor verifica la firma, responde rápido y procesa el evento de forma asíncrona. Un callback lento es el fallo habitual: el proveedor agota el tiempo, reintenta y el mismo evento se procesa dos veces. Las claves de idempotencia y un acuse rápido forman parte de la integración, no son una optimización.

Sea cual sea el camino del acuse, guarde el payload original. La interpretación del proveedor puede cambiar, y un caso de soporte a menudo depende del estado o del código de error original. Guárdelo con el message ID, la ruta y la hora.

Elegir e integrar

Elija SMPP cuando el flujo de envío sea sostenido, el proveedor asigne una ventana que usted pueda dimensionar y el equipo sepa operar una sesión: gestión de binds, keep-alive, reconexión y registros a nivel de PDU. Elija HTTP cuando el volumen sea moderado, el equipo ya opere endpoints web seguros y un callback encaje en la arquitectura. Elija ambos cuando el envío y el entrante tengan responsables distintos.

Elija lo que elija, pida la misma evidencia: una ruta de prueba, la asignación de caudal, el formato del acuse, la lista de códigos de error y la política de reintentos. La explicación de SMPP cubre la sesión, y la guía de conexión cubre el camino a producción.

Escriba la elección con números: tasa de pico, ventana por bind, timeout del callback y presupuesto de reintentos. Una decisión sin esos números es una preferencia. Revísela cuando cambie el pico o el equipo.