# SMPP enquire_link, ventana y limitación

> enquire_link (0x00000015) es un keepalive ligero que confirma que una sesión SMPP enlazada sigue sana sobre TCP. El rendimiento se rige por dos límites: la ventana (cuántas PDU pueden estar sin confirmar a la vez) y el techo de TPS del proveedor. Superar la tasa devuelve ESME_RTHROTTLED (0x00000058); la solución es reducir el ritmo.

- URL canónica: https://www.broadnet.me/es/reference/smpp-enquire-link-throttling
- Idioma: es
- Última actualización: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

Cómo SMPP mantiene viva una sesión con enquire_link, cómo la ventana limita las PDU pendientes sin confirmar y cómo ESME_RTHROTTLED y el TPS por bind rigen tu rendimiento real.

## Keepalive con enquire_link

Una sesión SMPP enlazada puede permanecer inactiva durante largos periodos, y una conexión TCP semiabierta parece viva a nivel de socket. enquire_link resuelve esto: cualquiera de los extremos lo envía con un temporizador de inactividad (normalmente cada 30–60 segundos) y espera un enquire_link_resp con prontitud. Una respuesta perdida significa que la sesión está muerta: cierra la conexión TCP y reconecta con espera. Es la única forma fiable de detectar un enlace roto de forma silenciosa.

*Intercambio de keepalive*

```text
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)
```

## La ventana: PDU pendientes sin confirmar

SMPP es asíncrono: puedes enviar muchas PDU submit_sm antes de que llegue su submit_sm_resp. El tamaño de ventana limita cuántas pueden estar pendientes (sin confirmar) a la vez. Cuando la ventana está llena, debes pausar los envíos hasta que una respuesta libere un hueco. Disparar más allá de la ventana es una de las principales causas de limitación y PDU descartadas. El tamaño de ventana se acuerda con el proveedor: no hay un valor por defecto único del protocolo.

## Limitación y TPS

Aparte de la ventana, el proveedor impone una tasa máxima de mensajes —transacciones por segundo (TPS)— por bind o por cuenta. Superarla devuelve ESME_RTHROTTLED (0x00000058). La respuesta correcta es reducir el ritmo: pausa, espera con variación aleatoria y reanuda por debajo del techo. Nunca reintentes de inmediato una PDU limitada ni abras bind adicionales para eludir el límite: ambas cosas arriesgan la suspensión de la cuenta. En la v5.0, el SMSC puede además anunciar la congestión mediante el TLV congestion_state para que los ESME reduzcan el ritmo de forma preventiva.

*Los tres límites que dan forma al rendimiento*

| Límite | Rige | Señal de superación |
|---|---|---|
| Tamaño de ventana | PDU no confirmadas en tránsito | Contrapresión / PDU descartadas |
| Techo de TPS | Mensajes por segundo | ESME_RTHROTTLED (0x58) |
| Número de binds | Sesiones paralelas | Bind rechazado / acción sobre la cuenta |

## Ajuste para un rendimiento sostenido

El rendimiento real es aproximadamente el tamaño de ventana dividido por la latencia de ida y vuelta, con el tope del techo de TPS. Una ventana mayor ayuda en enlaces de alta latencia; más bind solo ayudan si el proveedor los provisiona. Instrumenta la ocupación de la ventana, la latencia de envío/respuesta y la tasa de errores de limitación, y trata un aumento de ESME_RTHROTTLED como la señal para reducir la tasa de envío en lugar de forzar más.

## Preguntas frecuentes

### ¿Con qué frecuencia debo enviar enquire_link?

Normalmente cada 30–60 segundos con un temporizador de inactividad. Envíalo cuando la sesión haya estado en silencio y trata un enquire_link_resp ausente dentro de tu tiempo de espera como una sesión muerta que hay que reconectar.

### ¿Qué es el tamaño de ventana de SMPP?

La ventana es el número máximo de PDU que puedes tener pendientes (enviadas pero aún no confirmadas) a la vez. Se negocia con tu proveedor en lugar de fijarlo el protocolo; pausa los envíos cuando la ventana esté llena.

### ¿Cómo soluciono ESME_RTHROTTLED?

Reduce tu tasa de envío. Pausa, espera con variación aleatoria y reanuda por debajo del techo de TPS del proveedor. No reintentes de inmediato ni abras bind adicionales para eludir el límite: ambas cosas pueden hacer que te limiten con más dureza o suspendan la cuenta.

### ¿Una ventana mayor aumenta mi TPS?

Hasta cierto punto. El rendimiento es aproximadamente el tamaño de ventana dividido por el tiempo de ida y vuelta, pero sigue con el tope del techo de TPS del proveedor. Una ventana mayor sirve sobre todo para ocultar la latencia en enlaces de alto RTT.

### ¿Qué es congestion_state en SMPP v5.0?

La v5.0 añade un TLV congestion_state que permite al SMSC anunciar su nivel de carga (0–100). Un ESME cooperativo lo lee y reduce el ritmo de forma preventiva antes de alcanzar la limitación estricta, suavizando el rendimiento bajo carga.

## Fuentes

- [SMPP v3.4 specification — §4.11 enquire_link](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v5.0 specification — congestion state](https://smpp.org/SMPP_v5.pdf)

## Relacionado

- [Códigos de error SMPP command_status](https://www.broadnet.me/es/reference/smpp-command-status-errors)
- [Operaciones de enlace SMPP](https://www.broadnet.me/es/reference/smpp-bind-operations)
- [Mejores prácticas de integración SMPP](https://www.broadnet.me/es/reference/smpp-integration-best-practices)
- [Consulta de códigos de error SMPP (herramienta gratuita)](https://www.broadnet.me/es/tools/smpp-error-codes)
- [Lista de verificación (guía) para la integración SMPP](https://www.broadnet.me/es/guides/smpp-integration-checklist)