Skip to main content
SMPP es una sesión TCP persistente. Se enlaza una vez, se mantiene abierta y se envía por ella. Por eso supera a una llamada HTTPS por mensaje con volumen sostenido.

​
Qué necesita

Pida a su proveedor:
Una credencial HTTP no puede hacer bind, y una credencial SMPP no puede usar la API REST. Las credenciales tienen tipo, y no son intercambiables. Pida una de cada si necesita ambas.

​
Qué tipo de bind

Un bind solo de receptor no envía nada y parece perfectamente sano. Si su sesión está arriba y no sale ningún mensaje, compruebe el tipo de bind antes que nada. Es la causa más común, con diferencia, de “enlazado pero no pasa nada”.

​
Los límites que se le aplican

Su proveedor los fija; saber que existen ahorra especular ante un bind rechazado. El tamaño de ventana es el que da forma a su throughput. Es cuántos submit_sm puede tener pendientes sin respuesta. Un cliente que espere cada respuesta antes de enviar el siguiente está limitado por el tiempo de ida y vuelta, por grande que sea la ventana.

​
Si su bind se rechaza

Cuatro causas, y el rechazo no siempre las distingue:
1

Tipo de credencial incorrecto

Un login HTTP. Se rechaza como fallo de autenticación.
2

system_id o password incorrectos

Ambos son sensibles a mayúsculas.
3

Un límite ya alcanzado

Otra sesión suya sigue abierta, incluida una obsoleta que el extremo remoto todavía no ha dejado caer por timeout.
4

Su IP no está permitida

Si hay una lista permitida configurada, todo lo demás puede ser correcto y el bind sigue fallando.
Una sesión obsoleta es la sorprendente. Si se reconecta más rápido de lo que el servidor deja caer su sesión anterior, está compitiendo consigo mismo por un límite por usuario. Deshaga el bind limpiamente al apagar, y deje que enquire_link detecte un peer muerto en lugar de reconectar agresivamente.

​
Mantener viva la sesión

Envíe enquire_link en un intervalo: cada 30 segundos es típico. Es cómo ambos extremos detectan una conexión que ha muerto sin un FIN, que es el resultado normal de un timeout NAT o un firewall que segando un flujo inactivo. Su librería casi con seguridad lo hace por usted. Confírmelo, porque una sesión muerta pero no cerrada acepta sus submit_sm en un buffer de socket y los pierde.

​
Sin dirección de bind en el listener

Merece la pena saberlo si pide a su proveedor que restrinja el acceso: ambos listeners se enlazan a todas las interfaces, y no hay ajuste de dirección de bind. La librería subyacente no tiene esa opción. Restringir la exposición se hace con un firewall, un namespace de red o vinculando el contenedor a una interfaz. Si su proveedor le dice que un listener está “solo en la interfaz interna”, eso es algo que arreglaron alrededor de la pasarela, no dentro de ella.

​
Relacionado

Enviar mensajes

submit_sm, codificación y los campos que importan.

Ajustes del listener

Toda propiedad de listener y vendor.