GATUM
By Sempico Solutions

Способы подключения “клиент-сервер” в протоколе SMPP v3.4: самый оптимальный.

При работе с новыми клиентами на платформе GATUM мы сталкиваемся с вопросом: у вас есть несколько способов подключения “клиент-сервер”, но что они означают и зачем они нужны? 

Для рассмотрения данной темы, сперва необходимо разобраться — какие именно существуют способы подключений:

  • Transceiver (TRX) — способ подключения, в котором может происходить и отправка СМС на сервер и получение отчетов от сервера.
  • Transmitter (TX) — способ подключения, в котором может происходить только отправка СМС на сервер.
  • Receiver (RX) —  способ подключения, в котором может происходить только получение отчетов от сервера.

По сути, существует всего 3 способа подключения, но какой именно выбрать, какой из них оптимальнее подходит для работы?

Исходя из описания методов подключения, можно увидеть, что Transmitter и Receiver обычно работают в тандеме и дополняют друг друга. Конечно их можно запускать по отдельности, в зависимости от задачи. К примеру, если нам не нужны отчеты, то можно запустить Transmitter и только отправлять СМС.  А если нам нужны из подключения только входящие СМС — то можно запустить один Receiver.

Если использовать исключительно философское понимание способов подключения, то конечно Transceiver умеет все и достаточно будет использовать только его.  Но в настройке процессов работы не все так просто.

Для того, чтобы понять в чем разница, представьте дверь или даже ворота. Когда они открыты — то в них могут проходить люди в разных количествах. Да, если там будет проходить одновременно 10-20 человек в одну сторону и примерно столько же в другую, то они не стесняя друг друга смогут разминуться и пройти в нужном направлении. На примере этих ворот можно понять, как технически работает Transceiver.

Как вы понимаете — эти люди есть СМС (люди, которые выходят из ворот) и отчеты о доставке (люди, которые входят в ворота). Но в современном мире всем хочется, чтобы в одни ворота, а лучше дверь, и входили и выходили тысячи людей каждую секунду.

Так вот в случае работы Transmitter и Receiver (в тандеме) — у нас будет двое ворот. В одни ворота люди будут исключительно выходить строем, а во вторые — заходить. И никак иначе. Никто не толкается и не просится “Я только спросить”. Все в порядке очереди.

В том и другом случае есть размер пропускной способности, т.е. кол-во людей, которые ворота могут пропустить в секунду времени.

трансмиттер-ресивер-трансивер
Иллюстрация подключений.

Теперь вернемся к нашим СМС. Вы уже представили эти разные ворота и примерно поняли, как это работает. Соответственно, вы должны понимать, что когда начинается отправка большого кол-ва СМС в единицу времени через Transceiver, то первые несколько секунд они будут исключительно отправляться, выходить в одном направлении. Но в какой-то момент сервер начнет возврат отчетов о доставке и тут уже начинается “толкучка“. Отчеты будут “мешать” СМС, так как все идет в одном потоке. Все, кто скажут: “Я всегда так слал и никогда проблем не видел”, могут дальше и не читать, я Вас не смогу переубедить.

Но, если Вам интересно — как оптимизировать процесс отправки трафика, то вот что я скажу. В случае, если данное подключение будет использоваться для большого кол-ва трафика каждый день — моя рекомендация использовать подключение Transmitter + Receiver (TX + RX). Это правильно лишь потому, что ни СМС, ни отчеты о доставке не будут друг другу мешать, а на большом объеме трафика даже эти миллисекунды дадут прирост в скорости.

Если же у вас подключение используется для трафика без особых объемов, то можно использовать Transceiver и не будет ни проблем, ни задержек. На малых объемах, даже если отчеты на какую то долю секунды дают задержку СМС, в общем итоге — человеческий взгляд этого не заметит.

С одной стороны, все кажется просто и ясно: большой объем — используй Transmitter + Receiver (TX + RX), маленький объем — Transceiver (TRX). Но в работе, опять же,  не все так просто.

К примеру, наша платформа поддерживает качественно любой из этих типов подключений, как при подключении к серверу поставщика, так и если клиент хочет подключиться к нам. Но когда Вам потребуется подключиться к другим платформам, то тут уже необходимо понимать, что не все платформы поддерживают тип подключения Transmitter + Receiver (TX + RX). Transceiver (TRX), в свою очередь, поддерживает любая SMPP платформа.

подключения-клиент-сервер-которые-поддерживает-платформа-gatum
Подключения, которые поддерживает платформа GATUM.

Поэтому предварительно лучше уточнить, каким из способов можно подключаться.

Вот и получается, что даже зная всю методику выбора способа коннекта — в жизни это бывает невозможно из-за технических ограничений другой платформы.

Также бывает, что платформа поставщика не в состоянии выдержать тот объем СМС в секунду и коннект отпадает со стороны сервера. В таком случае приходится переподключаться и снова продолжать. Конечно такая проблема будет продолжаться, пока у вас есть в очереди СМС на этого поставщика. Но для решения данной проблемы на нашей платформе были реализованы Сессии (копии подключений с такими же реквизитами), если конечно, ваш поставщик разрешает сессии.

Также для работы с одной известной платформой был реализован гибридный метод подключение Transceiver + Receiver. Чтобы немножко разгрузить Transceiver от отчетов, какую то их часть забирает на себя Receiver.

Мы часто слышим от разработчиков других платформ, что у нас через Transceiver все отлично и быстро работает. И это действительно работает. Но под “быстро” скрываются задержки с отчетами, а в сетевое окно не всегда может пройти заданное кол-во данных в обе стороны. 

Но несмотря на все слова, мы снова и снова убеждаемся, что если платформа универсальна, то она сможет сработаться с любой другой быстро и качественно.

Просто знайте, если создавать только Transmitter + Receiver (TX + RX) для всех подключений, вы просто бессмысленно будете тратить ресурсы своего железного сервера.

Если у Вас остались вопросы — то будем рады Вам помочь по адресу victoria.prisyazhnyuk@sempico.solutions.

Автор Денис Галан.

Share the Post: