Cuando trabajamos con nuevos clientes en la plataforma GATUM, nos enfrentamos a la pregunta: tiene varias formas de conectar «cliente-servidor», pero ¿qué significan y por qué son necesarias?
Para considerar este tema, primero debe averiguar qué tipo de métodos de conexión existen:
- El transceptor (TRX) es un método de conexión en el que puede tener lugar tanto el envío de SMS al servidor como la recepción de informes del servidor.
- Transmisor (TX) es un método de conexión en el que solo se pueden enviar SMS al servidor.
- Receptor (RX): método de conexión en el que solo se pueden recibir informes del servidor.
De hecho, solo hay 3 métodos de conexión, pero ¿cuál elegir, cuál es el mejor para el trabajo?
Según la descripción de los métodos de conexión, puede ver que el transmisor y el receptor generalmente funcionan en conjunto y se complementan entre sí. Por supuesto, se pueden ejecutar por separado, según la tarea. Por ejemplo, si no necesitamos informes, entonces podemos lanzar un Transmisor y solo enviar SMS. Y si solo necesitamos SMS entrantes desde la conexión, entonces podemos lanzar un Receptor.
Si estamos usando exclusivamente una comprensión filosófica de los métodos de conexión, entonces, por supuesto, el Transceptor puede hacer todo y será suficiente usar solo él. Pero al configurar los procesos de trabajo, no todo es tan simple.
Para comprender la diferencia, imagine una puerta o incluso una puerta. Cuando están abiertos, personas en diferentes cantidades pueden pasar por ellos. Sí, si entre 10 y 20 personas pasan al mismo tiempo en una dirección y casi lo mismo en la otra, no se avergonzarán entre sí y caminarán en la dirección correcta. Usando estas puertas como ejemplo, puede comprender cómo funciona técnicamente el transceptor.
Como puedes imaginar, estas personas son SMS (personas que salen de la puerta) e informes de entrega (personas que entran por la puerta). Pero en el mundo moderno, todo el mundo quiere tener una puerta, o mejor, una puerta, y miles de personas entran y salen cada segundo.
Entonces, si el transmisor y el receptor funcionan (en tándem), tendremos dos puertas. En una puerta, la gente saldrá exclusivamente en formación, y en la segunda, entrará. Y nada más. Nadie empuja o pregunta «Solo pregunto». Todo está en el orden de la cola.
En ambos casos, existe el tamaño del rendimiento, es decir, la cantidad de personas que pueden pasar la puerta por segundo de tiempo.
Ahora volvamos a nuestro SMS. Ya ha imaginado estas diferentes puertas y tiene una idea aproximada de cómo funcionan. En consecuencia, debe comprender que cuando una gran cantidad de SMS comienza a enviarse por unidad de tiempo a través del Transceptor, entonces durante los primeros segundos se enviarán exclusivamente, saldrán en una dirección. Pero en algún momento, el servidor comenzará a devolver informes de entrega, y luego comienza el «flechazo». Los informes «interferirán» con los SMS, ya que todo va en un solo flujo. Cualquiera que diga: “Siempre lo he enviado de esta manera y nunca he visto ningún problema” puede que no siga leyendo, no puedo convencerlos.
Pero, si está interesado en cómo optimizar el proceso de envío de tráfico, esto es lo que le diré. En caso de que esta conexión se utilice para una gran cantidad de tráfico todos los días, mi recomendación es utilizar la conexión Transmisor + Receptor (TX + RX). Esto es correcto solo porque ni los SMS ni los informes de entrega interferirán entre sí, y con un gran volumen de tráfico, incluso estos milisegundos darán un aumento de velocidad.
Si su conexión se usa para tráfico sin mucho volumen, entonces puede usar Transceptor y no habrá problemas ni demoras. En volúmenes pequeños, incluso si los informes dan un retraso en los SMS durante una fracción de segundo, en general, el ojo humano no lo notará.
Por un lado, todo parece simple y claro: gran volumen – use Transmisor + Receptor (TX + RX), pequeño volumen – Transceptor (TRX). Pero en el trabajo, nuevamente, no todo es tan simple.
Por ejemplo, nuestra plataforma soporta cualitativamente cualquiera de estos tipos de conexiones, tanto cuando se conecta al servidor del proveedor, como si el cliente quiere conectarse con nosotros. Pero cuando necesite conectarse a otras plataformas, debe comprender que no todas las plataformas admiten el tipo de conexión Transmisor + Receptor (TX + RX). Transceptor (TRX), a su vez, es compatible con cualquier plataforma SMPP.
Por lo tanto, es mejor aclarar de antemano cuál de los métodos se puede conectar.
Entonces resulta que aun conociendo toda la metodología para elegir un método de conexión, en la vida real esto es imposible debido a las limitaciones técnicas de otra plataforma.
También ocurre que la plataforma del proveedor no es capaz de soportar ese volumen de SMS por segundo y la conexión desaparece del lado del servidor. En este caso, debe volver a conectarse y continuar nuevamente. Por supuesto, este problema continuará mientras tenga un SMS en cola para este proveedor. Pero para solucionar este problema, se implementaron Sesiones en nuestra plataforma (copias de conexiones con los mismos detalles), si, por supuesto, su proveedor permite sesiones.
Además, para trabajar con una plataforma conocida, se implementó un método híbrido para conectar Transceptor + Receptor. Para aliviar levemente al transceptor de los informes, el receptor se hace cargo de una parte de ellos.
A menudo escuchamos de los desarrolladores de otras plataformas que todo funciona bien y rápido para nosotros a través de Transceiver. Y realmente funciona. Pero en «rápido» hay retrasos con los informes y la cantidad especificada de datos no siempre puede pasar a la ventana de red en ambas direcciones.
Pero a pesar de todas las palabras, estamos convencidos una y otra vez de que si la plataforma es universal, entonces puede funcionar con cualquier otra de manera rápida y eficiente.
Solo sepa, si crea solo un transmisor + receptor (TX + RX) para todas las conexiones, simplemente desperdiciará los recursos de su servidor de hardware.
Si tiene alguna pregunta, estaremos encantados de ayudarle en victoria.prisyazhnyuk@sempico.solutions.
Escrito por Denis Galan.
