When working with new clients on the GATUM platform, we are faced with the question: you have several ways to connect “client-server”, but what do they mean and why are they needed?
To consider this topic, you first need to figure out what kind of connection methods exist:
- Transceiver (TRX) is a connection method in which both sending SMS to the server and receiving reports from the server can take place.
- Transmitter (TX) is a connection method in which only SMS can be sent to the server.
- Receiver (RX) – connection method in which only receiving reports from the server can take place.
In fact, there are only 3 connection methods, but which one to choose, which one is the best for the job?
Based on the description of the connection methods, you can see that the Transmitter and Receiver usually work in tandem and complement each other. Of course, they can be run separately, depending on the task. For example, if we do not need reports, then we can launch a Transmitter and only send SMS. And if we only need incoming SMS from the connection, then we can launch one Receiver.
If we are using exclusively a philosophical understanding of connection methods, then of course the Transceiver can do everything and it will be enough to use only it. But in setting up work processes, not everything is so simple.
To understand the difference, imagine a door or even a gate. When they are open, people in different quantities can pass through them. Yes, if 10-20 people pass there at the same time in one direction and about the same in the other, then they will not embarrass each other and walk in the right direction. Using these gates as an example, you can understand how the Transceiver technically works.
As you can imagine, these people are SMS (people who leave the gate) and delivery reports (people who enter the gate). But in the modern world, everyone wants to have one gate, or better a door, and thousands of people enter and leave every second.
So, if the Transmitter and Receiver work (in tandem), we will have two gates. In one gate, people will exclusively go out in formation, and in the second, they will enter. And nothing else. Nobody pushes or asks “I just ask”. Everything is in the order of the queue.
In both cases, there is the size of the throughput, that is, the number of people who can pass the gate per second of time.
Now let’s get back to our SMS. You have already imagined these different gates and have a rough idea of how it works. Accordingly, you should understand that when a large number of SMS starts to be sent per unit of time through the Transceiver, then for the first few seconds they will be sent exclusively, go out in one direction. But at some point, the server will start returning delivery reports, and then the “crush” begins. The reports will “interfere” with SMS, since everything goes in one stream. Anyone who says: “I have always sent it this way and have never seen any problems” may not read further, I cannot convince you.
But, if you are interested in how to optimize the process of sending traffic, then here’s what I will tell you. In case this connection will be used for a large amount of traffic every day, my recommendation is to use the Transmitter + Receiver (TX + RX) connection. This is correct only because neither SMS nor delivery reports will interfere with each other, and with a large volume of traffic, even these milliseconds will give an increase in speed.
If your connection is used for traffic without much volume, then you can use Transceiver and there will be no problems or delays. On small volumes, even if reports give a delay in SMS for some fraction of a second, in general, the human eye will not notice it.
On the one hand, everything seems simple and clear: large volume – use Transmitter + Receiver (TX + RX), small volume – Transceiver (TRX). But in work, again, not everything is so simple.
For example, our platform qualitatively supports any of these types of connections, both when connecting to the supplier’s server, and if the client wants to connect to us. But when you need to connect to other platforms, then you need to understand that not all platforms support the Transmitter + Receiver (TX + RX) connection type. Transceiver (TRX), in turn, supports any SMPP platform.
Therefore, it is better to clarify beforehand which of the methods can be connected.
So it turns out that even knowing the entire methodology for choosing a connection method, in real life this is impossible due to the technical limitations of another platform.
It also happens that the supplier’s platform is not able to withstand that volume of SMS per second and the connection disappears from the server side. In this case, you have to reconnect and continue again. Of course this problem will continue as long as you have an SMS queued for this provider. But to solve this problem, Sessions were implemented on our platform (copies of connections with the same details), if, of course, your provider allows sessions.
Also, to work with one well-known platform, a hybrid method of connecting Transceiver + Receiver was implemented. To slightly relieve the Transceiver of reports, some part of them is taken over by the Receiver.
We often hear from developers of other platforms that everything works fine and fast for us through Transceiver. And it really works. But under “fast” there are delays with reports, and the specified amount of data cannot always pass into the network window in both directions.
But despite all the words, we are convinced again and again that if the platform is universal, then it can work with any other quickly and efficiently.
Just know, if you create only a Transmitter + Receiver (TX + RX) for all connections, you will simply waste the resources of your hardware server.
If you have any questions, we will be happy to help you at victoria.prisyazhnyuk@sempico.solutions.
Written by Denis Galan.
