n patrón que vemos constantemente: una empresa contrata 100 SMS por segundo, dirige su aplicación al límite y solo recibe doce. El ancho de banda es correcto. La dirección SMSC es correcta. Nadie ha sufrido limitaciones de velocidad. El tráfico es muy lento, y el primer instinto siempre es culpar a la ruta. Casi nunca es la ruta. Es la ventana.
SMPP es un protocolo asíncrono que la mayoría de las integraciones ejecutan accidentalmente de forma síncrona. Comprender el porqué es la clave para diferenciar entre pagar por el rendimiento y obtenerlo.
Lo que realmente es la ventana
La ventana es el número de PDU que puede haber enviado pero que aún no han sido confirmadas, en una sola conexión, en un momento dado. Envíe un submit_sm y el SMSC responderá con submit_sm_resp; pero SMPP nunca le exigirá que espere esa respuesta antes de enviar el siguiente mensaje. La ventana indica hasta qué punto puede avanzar.
Con una ventana de 1, envías, esperas, recibes y vuelves a enviar. Tu rendimiento ahora está limitado por el tiempo de ida y vuelta, no por ningún acuerdo comercial. Con un tiempo de ida y vuelta de 40 ms, eso equivale a 25 mensajes por segundo, independientemente de lo que diga tu contrato. Con una ventana de 10, tienes diez mensajes en tránsito simultáneamente y el mismo enlace transporta aproximadamente diez veces más tráfico que la misma conexión.
El tamaño de la ventana es el factor determinante más importante del rendimiento que se obtiene de una vinculación, y es la configuración que con mayor frecuencia se deja con el valor predeterminado de la biblioteca, lo que limita silenciosamente una integración muy por debajo de su velocidad acordada.
¿Por qué tantas bibliotecas tienen por defecto una?
Para un autor de biblioteca, una ventana de 1 es la configuración predeterminada segura. No requiere estado de correlación, gestión de tiempos de espera ni reordenamiento: cada solicitud tiene exactamente una respuesta pendiente, por lo que un cliente ingenuo puede tratar SMPP como solicitud/respuesta sin notar la diferencia. Funciona, es fácil de entender y es lento. Muchas bibliotecas cliente SMPP se distribuyen de esta manera, y el valor nunca se revisa porque no parece haber ningún problema: los mensajes llegan, pero no con rapidez.
Los números de secuencia son lo que hace posible una ventana.
Cada PDU SMPP lleva un sequence_number en su encabezado de 16 octetos. Cuando varias solicitudes se envían simultáneamente, ese número es lo único que vincula cada submit_sm_resp con el submit_sm que la originó. No se garantiza que las respuestas lleguen en el orden en que se enviaron las solicitudes, por lo que un cliente que ejecute una ventana mayor a 1 debe mantener un mapa de los números de secuencia pendientes y compararlos al recibirlos.
Dos reglas son fundamentales. Nunca reutilices un número de secuencia mientras esté en circulación: una respuesta tardía a un número reciclado se atribuirá al mensaje incorrecto. Y siempre establece un tiempo de espera para las entradas: si no llega ninguna respuesta, el espacio debe liberarse o la ventana efectiva se reduce a cero durante la duración de la sesión, lo que produce el frustrante síntoma de un bloqueo que comienza rápidamente y se agrava con el paso de las horas.
Puedes ver cómo sucede campo por campo en nuestro simulador de sesión SMPP: muestra el sequence_number en el encabezado de cada PDU y qué respuesta responde a qué solicitud.
El tamaño de la ventana y el TPS son límites diferentes.
Estos conceptos suelen confundirse. TPS es un límite de velocidad que impone el operador: envíos por segundo, medidos en un intervalo de tiempo. El intervalo SMPP es un límite de concurrencia que usted configura: PDU pendientes en un instante. Ambos conceptos interactúan, pero no representan la misma cantidad.
La relación es aproximadamente: TPS alcanzable ≈ ventana ÷ tiempo de ida y vuelta. Una ventana de 10 con un tiempo de ida y vuelta de 50 ms proporciona aproximadamente 200 TPS. Si el operador te limita a 100, alcanzarás el límite y recibirás ESME_RTHROTTLED por el excedente. Si el operador permite 500 y tu ventana es de 10, nunca verás 500, independientemente de la cantidad de tráfico que ofrezcas; estás limitado por la concurrencia, no por la tasa.
| Ventana | Ida y vuelta | Techo | Síntoma |
|---|---|---|---|
| 1 | 40 ms | ~25 TPS | Nunca se alcanzó la tarifa contratada; el enlace parece inactivo. |
| 10 | 40 ms | ~250 TPS | Saludable para la mayoría de los remitentes empresariales |
| 50 | 40 ms | ~1250 TPS | Solo si el operador lo acepta; de lo contrario, se aplicará una limitación de velocidad. |
| 10 | 250 ms | ~40 TPS | Limitado por la latencia: aumente la ventana o acérquese. |
Lectura correcta de ESME_RTHROTTLED
El código ESME_RTHROTTLED (0x00000058) indica que se ha superado la tasa de envío acordada. No se trata de un rechazo del mensaje ni de un fallo de enrutamiento. La respuesta correcta es volver a intentar enviar el mensaje; tratarlo como un rechazo permanente descarta silenciosamente el tráfico que el operador habría aceptado un momento después.
También indica que su ventana de acceso es ahora demasiado grande para la tasa que mantiene. Si al aumentar la ventana se produjo una limitación en lugar de un aumento del rendimiento, la restricción ha pasado de la concurrencia al contrato, y la siguiente conversación será comercial en lugar de técnica.
enquire_link: la otra razón vincula el dado
Una conexión que no envía datos se ve idéntica a una conexión cuya conexión TCP se ha interrumpido silenciosamente: los tiempos de espera de NAT y los cortafuegos con estado descartan las sesiones inactivas sin avisar a ninguno de los extremos. El mensaje enquire_link cada 30 a 60 segundos demuestra que el socket sigue siendo utilizable en ambas direcciones. Si se pierde la ventana que espera el operador, el mensaje SMSC provocará la desconexión, generalmente en el momento menos oportuno.
Envía enquire_link en el mismo enlace en el que envías, responde rápidamente al enquire_link del SMSC y trata una respuesta perdida como una sesión muerta: unbind, reconecta y reanuda. Un cliente que sigue enviando a un socket semiabierto produce el incidente clásico en el que todo parece correcto pero no se entrega nada.
Cómo ajustar el tamaño de una ventana en la práctica
- Mide el tiempo de ida y vuelta en el dispositivo que uses habitualmente, no desde tu portátil. Envía un único mensaje con una ventana de 1 y un intervalo de tiempo de submit_sm a submit_sm_resp.
- Divide tu TPS contratado entre la cantidad de mensajes por segundo que permite un viaje de ida y vuelta. Ese cociente es tu ventana mínima viable.
- Añada un margen de seguridad (redondee al alza y añada aproximadamente un 50 %), ya que el tiempo de ida y vuelta no es constante y una ventana cuyo tamaño sea exactamente igual a la media tendrá un rendimiento inferior en la mediana.
- Auméntalo gradualmente, no de golpe, y presta atención a ESME_RTHROTTLED. La primera reducción de potencia sostenida te indicará cuál es el límite real del operador.
- Confirme el valor con el operador. Algunos SMSC imponen un límite máximo de tiempo por enlace y, si se supera dicho límite, se pondrán en cola o se descartarán silenciosamente.
- Solo entonces, considere una segunda vinculación. Las vinculaciones múltiples aumentan la concurrencia, pero también multiplican las formas en que una sesión puede fallar.
Cuando más ataduras superan a una ventana más grande
Existe un límite en la cantidad de PDU que una conexión TCP puede manejar. Más allá de unos cientos de PDU pendientes, los modos de fallo se vuelven problemáticos: un solo problema de socket afecta a todo ese tráfico, se produce un bloqueo en la cabecera de la cola y la recuperación tras una caída implica reproducir un gran conjunto de datos en tránsito. La mayoría de los operadores prefieren ver varias conexiones de tamaño moderado en lugar de una enorme, y la mayoría indicará la configuración que prefieren si se les pregunta.
Dividir por clase de tráfico en lugar de arbitrariamente. Mantener los códigos de acceso de un solo uso críticos en un enlace separado del marketing masivo significa que una campaña de marketing no puede retrasar un código de inicio de sesión, lo cual es una decisión de rendimiento que en realidad es una decisión de producto.
Una lista de verificación antes de culpar a la ruta
- ¿Cuál es la ventana configurada y alguien la configuró deliberadamente?
- ¿Se han agotado los números de secuencia pendientes y se han liberado?
- ¿Está funcionando enquire_link con el intervalo que espera el operador?
- ¿Las respuestas ESME_RTHROTTLED se reintentan con retroceso o se consideran fallos?
- ¿El tiempo de ida y vuelta medido coincide con lo que usted supuso al dimensionar la ventana?
- ¿Se están confirmando los recibos (deliver_sm) con prontitud? Un flujo de recibos no confirmados también puede retrasar la sesión.
Preguntas frecuentes
¿Cuál es un buen tamaño de ventana SMPP?
No existe un valor universal, ya que el correcto depende del tiempo de ida y vuelta y de la tarifa contratada. Un punto de partida práctico para el tráfico empresarial es 10; luego, auméntelo hasta alcanzar el TPS contratado o hasta que comience a ver ESME_RTHROTTLED. Calcularlo como TPS contratado × tiempo de ida y vuelta, más un margen de aproximadamente el 50 %, permite que la mayoría de las integraciones se acerquen al primer intento.
¿Una ventana más grande aumenta mi rendimiento sin límite?
No. Una vez que la ventana es lo suficientemente grande como para alcanzar el límite de velocidad del operador, los aumentos posteriores generan ESME_RTHROTTLED en lugar de más mensajes. La ventana elimina un cuello de botella de concurrencia; no puede aumentar un límite comercial.
¿Por qué mi rendimiento se degrada con el paso de las horas en lugar de hacerlo de inmediato?
Este es el síntoma clásico de secuencias de números pendientes que nunca caducan. Cada respuesta que se pierde consume permanentemente un espacio de ventana, por lo que la ventana efectiva se reduce a lo largo de la sesión hasta que el enlace se comporta como si la ventana fuera 1. Liberar los espacios al expirar el tiempo de espera soluciona el problema.
¿Es ESME_RTHROTTLED un fracaso permanente?
No, y tratarlo como una pérdida de tráfico significa que superaste la tasa acordada en ese instante. Retrocede, vuelve a intentar enviar el mismo mensaje y, si la limitación persiste, reduce el intervalo o renegocia la tasa.
¿Con qué frecuencia debo enviar enquire_link?
El intervalo habitual es de 30 a 60 segundos, y la cifra exacta debería coincidir con las expectativas del operador. El objetivo es comprobar que una sesión TCP posiblemente inactiva sigue activa en ambas direcciones antes de que un NAT o un cortafuegos la descarte silenciosamente.
¿Debo usar un bind grande o varios más pequeños?
Varias conexiones moderadas suelen ser más saludables que una muy grande, ya que un fallo de conexión reduce la capacidad en lugar de consumirla por completo. Se divide por clase de tráfico (contraseñas críticas por tiempo separadas de tráfico masivo) para que un pico de marketing no retrase un código de inicio de sesión.
¿El plazo de entrega también afecta a las confirmaciones de entrega?
Sí, en la dirección opuesta. El dispositivo SMSC te envía recibos deliver_sm, y si tu aplicación tarda en devolver deliver_sm_resp, el flujo de recibos se acumula. En una conexión de transceptor, esa congestión puede afectar a toda la sesión, así que confirma los recibos rápidamente, incluso si los procesas de forma asíncrona.
¿Dónde puedo ver este comportamiento sin conectarme a un SMSC real?
Nuestro simulador de sesión SMPP ejecuta una sesión completa de SMPP 3.4 en el navegador (binding, submit, la confirmación de entrega asíncrona, enquire_link y unbind) y muestra los campos de cada PDU mapeados a los octetos reales en el cable. No se establece ninguna conexión ni se envía nada.
La versión corta
Si una conexión presenta un rendimiento deficiente, verifique la ventana antes de revisar la red. SMPP es asíncrono por diseño, pero la mayoría de las integraciones lo ejecutan de forma síncrona por error. Ajuste el tamaño de la ventana según el tiempo de ida y vuelta medido y la tasa contratada, establezca un tiempo de espera para los números de secuencia, mantenga enquire_link en funcionamiento y vuelva a intentar ESME_RTHROTTLED con retroceso. Esta secuencia resuelve la gran mayoría de las quejas sobre el rendimiento sin necesidad de modificar la ruta.