Сокеты и стек протоколов TCP/IP

Рис. 1. Пример протоколов стека TCP/IP в соответствии с моделью OSI

В распределенных системах управления обмен данными является одним из ключевых моментов работы системы. Контроллер CPM723-01 позволяет отправлять и получать данные по промышленному протоколу Modbus TCP на базе протокола TCP/IP с использованием двух портов Ethernet и по протоколу Modbus RTU/ACSII на базе последовательных сетей RS-485/ RS-232 с помощью коммуникационных модулей NIM741/NIM742. Кроме того, система исполнения контроллера CPM723-01 поддерживает механизм сетевого обмена данными между контроллерами, принадлежащими одной подсети, средствами специального протокола прикладного уровня CODESYS V3.

Иногда возникает необходимость использовать протоколы низкого уровня, которые позволяют обмениваться большим количеством сообщений с помощью стека TCP/IP. Также, на базе них можно создавать протоколы более высокого уровня модели OSI (рис. 1).

Взаимодействие между устройствами в рамках стека TCP/IP осуществляется с помощью связки IP адреса и порта.

Для заданияIP адресав настоящее время чаще всего используется протокол IPv4. Для него IP-адрес записывается в виде 32-битной формы, представляемой в символьной форме mmm.nnn.ppp.qqq: адрес, разбитый на четыре поля, разделённых точками, по одному байту в поле, например, 192.168.102.101. Номер порта задается в диапазоне от 0 до 65535.

Пара адрес и порт образует сокет (с английского socket – «гнездо»). Сокет – является программным интерфейсом, который обеспечивает обмен данными между устройствами на низком уровне (рис. 2).


Общение по сокетам
Рис. 2. Общение с помощью сокетов.


Протокол TCP/IP основывается на соединениях, устанавливаемых между двумя компьютерами, обычно называемых клиентом и сервером. Поэтому, различают сокет клиента и сокет сервера. Для организации общения клиент должен знать IP адрес и номер порта сервера, по которым он подключается к удаленному устройству. в рамках стека протоколов TCP/IP различают два типа сокетов TCP и UDP. Также, TCP сокеты называют потоковыми, а UDP – датаграммными.

Протокол TCP/IP основывается на соединениях, устанавливаемых между двумя компьютерами, обычно называемых клиентом и сервером. Поэтому, различают сокет клиента и сокет сервера. Для организации общения клиент должен знать IP-адрес и номер порта сервера, по которым он подключается к удаленному устройству. в рамках стека протоколов TCP/IP различают два типа сокетов TCP и UDP. Также, TCP сокеты называют потоковыми, а UDP – датаграммными.

Наверх

TCP сокеты

TCP сокеты используют TCP-соединения, в которых на транспортном уровне (рис. 1) обеспечивается надёжная доставка данных. TCP протокол отвечает за установление и поддержание соединения, сегментацию, доставку и буферизацию данных, упорядочивание и избавление от дублированных TCP-сегментов данных, контроль ошибок и скорости передачи. Схема работы простого TCP сокета представлена на рисунке 3.

Для удобства в качестве функций, указанных на диаграмме, используются функции, из системной библиотеки SysSocket 3.х.x.x, которая позволяет создавать сокеты на устройствах, поддерживающих платформу CODESYS V3 в том числе на контроллере CPM723-01 модульной линейки Fastwel I/O.

Cерверный TCP сокет

Рассмотрим работу серверного сокета (рис. 3). Будем считать, что существует отдельная программа, исполняемая в контроллере, которая организует обмен данными с помощью сокетов.


Рис. 3. Работа простого TCP сокета

Инициализация сокета

При старте программы происходит инициализация сервера. С помощью функции SysSockCreate() создается системный идентификатор (handle) сокета. Данная функция в качестве входных параметров принимает аргументы, задающие тип и протокол сокета. Для использования TCP протокола функция SysSockCreate() должна принимать следующие входные аргументы:

hServerSocket:= SysSockCreate(SOCKET_AF_INET, SOCKET_STREAM, SOCKET_IPPROTO_TCP,ADR(result)); // hServerSocket – системный идентификатор сокета RTS_IEC_HANDLE, создаваемый SysSockCreate;
// SOCKET_AF_INET задает сетевой протокол IPv4;
// SOCKET_STREAM определяет тип создаваемого сокета, в данном случае потоковый режим (TCP);
// SOCKET_IPPROTO_TCP определяет протокол сокета, в данном случае TCP;
// ADR(result) – указатель на системный идентификатор (handle) результата функции
// result имеет тип структуры RTS_IEC_RESULT, и содержит коды ошибок, возникающих
// при работе с сокетами (рис. 5).


Далее сокет сервера привязывается к определенному IP-адресу и порту с помощью функции SysSockBind(). Для привязки к определенному IP-адресу функция SysSockBind() ссылается на структуру SOCKADDRESS, в которой хранятся заданный адрес сокета для привязки.

result:= SysSockBind(hServerSocket, ADR(serverAddress), SIZEOF(serverAddress)); // Дескриптор серверного сокета hServerSocket связывается с адресом сокета serverAddress,
// описываемой структурой SOCKADDRESS


После успешной привязки к адресу функция SysSockListen() включает прослушивание входящих соединений (ожидание подключений клиентов к серверу). Функцией SysSockListen() также определяется максимальное количество подключений к серверу. Например, если максимальное количество подключений равно 3, и если 3 клиента уже подключились к серверу, то 4-тому будет отказано в подключении.

result:= SysSockListen(hServerSocket, maxConnections);
// где hServerSocket – системный идентификатор серверного сокета;
// maxConnections - максимальное количество входящий соединений;


Обмен данными

После того как сервер включает режим прослушивания, он переходит в рабочий режим и ждет входящие соединения от клиентов. Как только клиент подключается к сокету сервера, с помощью функции SysSockAccept() создается системный идентификатор клиентского сокета hclientSocket и соединение считается открытым:

hclientSocket:= SysSockAccept(hServerSocket, ADR(clientAddress), ADR(adressSize),ADR(result)); // hclientSocket - системный идентификатор клиентского сокета;
// clientAddress – структура SOCKADDRESS, где хранится адрес клиента;
// ADR(adressSize) – указатель на размер структуры SOCKADDRESS.


Серверный сокет принимает сообщения с помощью функции SysSockRecv():

bytesRead:= SysSockRecv(hClientSocket, ADR(recvBuffer), SIZEOF(recvBuffer), 0, ADR(result)); // bytesRead – количество полученных байт сообщения. В случае ошибки возвращается 0;
// hClientSocket – системный идентификатор клиентского сокета;
// ADR(recvBuffer) указатель на переменную, в которую сохраняется принимаемое сообщение;
// SIZEOF(recvBuffer) – размер принимаемого сообщения;
// Вместо 0 могут быть установлены дополнительные опции для приема сообщений
// (подробнее в описании функции в библиотеке SysSocket);
// ADR(result) – указатель на идентификатор результата.


Затем отправляет данные с помощью функции SysSockSend():

bytesSend:= SysSockSend(hClientSocket, ADR(sendBuffer), SIZEOF(sendBuffer), 0, ADR(result)); // bytesSend – количество отправленных байт. В случае ошибки возвращается 0;
// hClientSocket – системный идентификатор клиентского сокета;
// ADR(sendBuffer) указатель на переменную, которая содержит отправляемое сообщение;
// SIZEOF(sendBuffer) – размер принимаемого сообщения;
// Вместо 0 могут быть установлены опции приема сообщений;
// ADR(result) – указатель на идентификатор результата.


Обработка новых подключений

После успешных приема и передачи данных может быть реализовано несколько вариантов поведения программы:

  • 1. Программа может закрыть клиентское соединение. В таком случае, в следующих циклах программы сервер будет ожидать подключения с новым клиентом. Такой режим работы не является эффективным, так как контроллеру придется во время каждого цикла закрывать клиентское соединение и подключать нового (или того же самого что и в предыдущем цикле) клиента.

  • 2. Программа может не закрывать клиентский сокет, а сохранить установленное соединение. В таком случае, один раз установив соединение, клиент будет постоянно отправлять и получать данные от сервера. Такой режим работы более эффективный, но может возникнуть ситуация, когда все клиентские соединения будут заняты, и новый клиент не сможет подключиться к серверу. Решить данную ситуацию можно различными способами. Один из вариантов – следить за последним временем активности клиентских сокетов, и отключать самое старое соединение в случае, если в очереди обнаружился новый клиент (рис. 4).
Рис. 4. Обработка подключения нового клиента

Закрытие соединения

В рабочем режиме работы серверный сокет всегда остается открытым. Закрытие серверного сокета может происходить при внешнем событии, или при возникновении критических ошибок. Ошибки при создании и работе сокетов отображаются в системном идентификаторе result, который имеет тип структуры RTS_IEC_RESULT. Обозначение кодов ошибок описано в системной библиотеке CmpErrors Interfaces в глобальных константах Errors (рис. 5).
Для закрытии сокетного соединения используется фукнция SysSockClose():

SysSockClose(hServerSocket); // где hServerSocket – системный идентификатор серверного сокета


Рис. 5. Расшифровка кодов ошибок работы сокетов

Клиентский TCP сокет

Схема работы клиентского сокета отображена на рисунке 3 справа.

Инициализация клиента

Функция SysSockCreate() создает системный идентификатор сокета. Также, как и для сервера, для клиента необходимо создать потоковый сокет:

hClientSocket:=SysSockCreate(SOCKET_AF_INET, SOCKET_STREAM, SOCKET_IPPROTO_TCP,ADR(result)); // hClientSocket – системный идентификатор клиентского сокета;
// SOCKET_AF_INET задает сетевой протокол IPv4;
// SOCKET_STREAM определяет тип сокета, в данном случае потоковый сокет (TCP);
// SOCKET_IPPROTO_TCP определяет протокол сокета, в данном случае TCP;
// ADR(result) – указатель на системный идентификатор (handle) результата функции.


Зная IP-адрес и порт сервера, клиент с помощью SysSockConnect() подключается к серверному сокету:

result:=SysSockConnect(hClientSocket, ADR(clientAddress), SIZEOF(clientAddress)); // hClientSocket – системный идентификатор клиентского сокета;
// ADR(clientAddress) – указатель на структуру SOCKADDRESS с адресом сокета сервера;
// SIZEOF(clientAddress) – размер структуры адреса сокета.


Обмен данными

Обмен данными между клиентом и с помощью функций SysSockSend() и SysSockRecv():

bytesSend:= SysSockSend(hClientSocket, ADR(sendMessage), SIZEOF(sendMessage), 0,ADR(result));

bytesRecv:=SysSockRecv(hClientSocket, ADR(recvMessage), SIZEOF(recvMessage), 0, ADR(result)); // hClientSocket – системный идентификатор клиентского сокета;
// ADR(sendMessage/recvMessage) - указатель на отправляемое/полученное сообщение;
// SIZEOF(sendMessage/recvMessage), размер отправленного/полученного сообщения;
// ADR(result) – указатель на системный идентификатор (handle) результата функции.


Закрытие соединения

После обмена данными сокет может быть закрыт с помощью с помощью SysSockClose():

SysSockClose(hClientSocket); // где hClientSocket – системный идентификатор серверного сокета.

Однако, с точки зрения циклического обмена данными реального времени, каждый раз закрывать и открывать сокет заново неэффективно. Поэтому после успешной установки соединения обмен данными осуществляется в бесконечном цикле.

Особенности сокетов TCP

Использование TCP сокетов позволяет приложениям клиента и сервера обмениваться данными почти прозрачно, не заботясь о поддержании сетевого соединения, доставке пакетов по сети, порядке передачи пакетов и буферизации. TCP сокеты гарантируют доставку сообщений и правильный порядок пакетов, а также пересылают пакеты повторно, если подтверждение о передаче не приходит в течение определенного промежутка времени. Таким образом, использовать TCP сокеты уместно там, где необходима гарантированная доставка данных сетевыми средствами.

Несмотря на многие преимущества, TCP сокеты имеют и негативные стороны. Например, необходимость поддержания TCP-соединения уменьшает пропускную способность обмена данными в распределенных системах. Также, в системах обмена данными реального времени повторная передача потерянных пакетов может привести к тому, что система получит данные, которые утратили свою актуальность.

Наверх

UDP сокеты

Все перечисленные недостатки TCP сокетов связаны с особенностью TCP-протокола. Если в системе присутствие данных факторов крайне нежелательно, а гарантированность доставки сообщений не является критичным требованием, то в качестве альтернативы TCP сокетов могут использоваться UDP (датаграммные) сокеты.

UDP сокеты устроены проще, чем TCP. В качестве транспортного уровня используется протокол UDP, который не требует установления соединения и подтверждения приема. Информация пересылается в предположении, что принимающая сторона ее ожидает. Датаграммные сокеты не контролирует ничего, кроме целостности полученных датаграмм. Несмотря на это, UDP сокеты нашли свое применение в системах, где на первом месте стоит именно актуальность данных и их быстрая доставка, а не гарантия доставки каждого сообщения.

Например, сервер в ответ на запросы клиента передает по сети текущие (мгновенные) значения некоторого параметра контролируемого технологического процесса, а клиент формирует управляющий сигнал на основе принятых значений. Если темп опроса сервера клиентом много больше требуемого времени реакции алгоритма управления на изменение значения контролируемого параметра, то потеря одного-двух сообщений от сервера несущественно повлияет на качество формирования управляющего сигнала. В случае использования TCP соединения потерянное сообщение будет автоматически передано повторно, что может привести к получению клиентом неактуального значения контролируемого параметра и к формированию неправильного управляющего сигнала.

Серверный UDP сокет

На рисунке 6 показана схема работы простого UDP сокета.

Инициализация сервера

Также, как в случае TCP сокетов, системный идентификатор UDP сокета создается с помощью функции SysSockCreate():

hServerSocket:=SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, SOCKET_IPPROTO_UDP, ADR(result));
// hServerSocket - системный идентификатор сокета сервера;
// SOCKET_AF_INET - семейство, соответствующее сетевому протоколу IPv4;
// SOCKET_DGRAM - тип создаваемого сокета (датаграммный сокет для UDP);
// ADR(result)- указатель на идентификатор результата (RTS_IEC_RESULT).


После создания сокет сервера привязывается к определенному IP-адресу и порту с помощью функции SysSockBind(). В отличие от TCP, UDP сокет не включает прослушивание входящих соединений, а сразу подготавливается к получению данных по сети:

result:= SysSockBind(hServerSocket, ADR(serverAddress), SIZEOF(serverAddress));
// Дескриптор серверного сокета hServerSocket связывается с адресом сокета;
// serverAddress, заданным структурой SOCKADDRESS.


Обмен данными

Для получения данных по UDP сокетам используется функция SysSockRecvFrom() (в отличие от SysSockRecv() для TCP сокетов). Ее главная особенность в том, что она не просто принимает данные от клиента, но и записывает адрес и порт клиента в специальную структуру для хранения адреса SOCKADDRESS, чтобы в дальнейшем сервер знал, куда отправлять ответное сообщение:

bytesRead:=SysSockRecvFrom(hServerSocket, ADR(recvBuffer), SIZEOF(recvBuffer), 0, ADR(clientAddress), SIZEOF(clientAddress),ADR(result));
 // hServerSocket - системный идентификатор сокета сервера;
// bytesRead – количество полученных байт. В случае ошибки возвращается 0;
// hServerSocket – системный идентификатор клиентского сокета,;
// ADR(recvBuffer) указатель на переменную, в которую запишется получаемое сообщение;
// SIZEOF(recvBuffer) – размер принимаемого сообщения;
// Вместо 0 могут быть установлены опции приема сообщений;
// ADR(clientAddress) – указатель на структуру SOCKADDRESS, в которую запишется адрес клиента;
// ADR(result) – указатель на идентификатор результата.




Рис. 6. Схема работы простого UDP сокета.

Ответное сообщение отправляется с помощью SysSockSendTo(), которая аналогична SysSockSend() для TCP протокола, но в качестве аргумента принимает ссылку на адрес структуры SOCKADDRESS, где хранится записанный ранее адрес клиента:

bytesSend:= SysSockSendTo(hServerSocket, ADR(sendBuffer), SIZEOF(sendBuffer), 0, ADR(clientAddress), SIZEOF(clientAddress),ADR(result));
// ADR(sendBuffer) и SIZEOF(sendBuffer) – указатель на отправляемое сообщение
// и размер отправляемого сообщения
// ADR(clientAddress) – указатель на структуру, в которой записан адрес сокета клиента


Закрытие соединения

После отправки данных, сокет сервера снова переходит к функции SysSockRecvFrom() и остается незакрытым.

Но в случае необходимости серверный сокет можно закрыть аналогично TCP сокету:

SysSockClose(hServerSocket);


Клиентский UDP сокет

Клиент UDP работает аналогично клиентскому сокету TCP за исключением использования функций SysSockSendTo() и SysSockRecvFrom() для отправки и получения сообщений.

Инициализация клиента

Функция SysSockCreate() создает системный идентификатор сокета. Также, как и для сервера, для клиента необходимо создать потоковый сокет:

hClientSocket:=SysSockCreate(SOCKET_AF_INET, SOCKET_DGRAM, SOCKET_IPPROTO_UDP, ADR(result));
// hClientSocket – системный идентификатор клиентского сокета;
// SOCKET_AF_INET – семейство, соответствующее сетевому протоколу IPv4;
// SOCKET_DGRAM - тип создаваемого сокета (датаграммный сокет для UDP);
// SOCKET_IPPROTO_UDP – протокол сокета (UDP);
// ADR(result)- указатель на идентификатор результата (RTS_IEC_RESULT);


Обмен данными

В отличие от TCP сокетов, при использовании UDP протокола клиентский сокет не устанавливает соединения с сервером, а сразу после создания клиентского сокета переходит к обмену данными с помощью функций SysSockSendTo() и SysSockRecvFrom():

bytesSend:=SysSockSendTo(hClientSocket, ADR(sendMessage), SIZEOF(sendMessage), 0, ADR(clientAddress),SIZEOF(clientAddress),ADR(result));

bytesRecv:=SysSockRecvFrom(hClientSocket, ADR(recvMessage), 256, 0, ADR(clientAddress), SIZEOF(clientAddress), ADR(result));
// hClientSocket - системный идентификатор сокета сервера;
// bytesRead, bytesRecv – количество полученных и отправленных байт;
// В случае ошибки возвращается 0;
// ADR(clientAddress) – указатель на структуру SOCKADDRESS, в которую запишется адрес клиента;
// ADR(result) – указатель на идентификатор результата


Закрытие соединения

После обмена данными сокет может быть закрыт с помощью с помощью SysSockClose():

SysSockClose(hClientSocket);
// где hClientSocket – системный идентификатор серверного сокета


Однако, с точки зрения циклического обмена данными реального времени, каждый раз закрывать и открывать сокет заново неэффективно. Поэтому после успешной установки соединения обмен данными осуществляется в бесконечном цикле.

Наверх

Дополнительные настройки сокетов

На рисунке 3 и 6 показана работа простых серверного и клиентского сокетов. Но на деле, такая простая схема имеет некоторые ограничения и недостатки.

Блокирующий режим

По умолчанию, некоторые функции библиотеки SysSocket являются блокирующими. Это значит, что вызов функции не возвращает управление коду, до тех пор, пока он не выполнится. Блокирующими функциями являются SysSockAccept(), SysSockSend(), SysSockRecv(), SysSockSendTo(), SysSockRecvFrom() и так далее.

Например, сервер включает прослушивание входящих соединений с помощью неблокирующей функции SysSockListen(), сразу после которой идет вызов SysSockAccept(). И до тех пор, пока в очереди установленных соединений не появится хотя бы одно подключение, программа не будет исполняться дальше. Такой режим работы также называется синхронным.

Естественно, такое поведение программы не является безопасным, и при циклическом вызове программы в ПЛК может сработать сторожевой таймер или произойти выход в безопасный режим – контроллер будет считать, что программа зависла.

Для того чтобы использовать функции в неблокирующем режиме, необходимо после создания сокета SysSockCreate() вызвать функцию SysSockIoctl() с входным аргументом SOCKET_FIONBIO, которая является командой перевода сокета в неблокирующий режим. При неблокирующим (асинхронном) режиме функция возвращает управление программе вне зависимости от того, закончена операция приема/передачи или нет:

result:=SysSockIoctl(hSocket, SOCKET_FIONBIO, ADR(mode));
// hSocket – системный идентификатор сокета клиента или сервера;
// ADR(mode) – указатель на переменную, включающую опцию (значение переменной 16#1).


Также, дополнительные настройки работы сокета можно сделать с помощью функции SysSockSetOptions(). Например, включить возможность повторного использования порта:

result:= SysSockSetOption(hSocket, SOCKET_SOL, SOCKET_SO_REUSEADDR, ADR(mode), SIZEOF(mode));
// hSocket – системный идентификатор сокета клиента или сервера;
// SOCKET_SOL – уровень протокола, соответствующий уровню сокетов;
// SOCKET_SO_REUSEADDR – опция, позволяющая связать сокет с локальным адресом,
// который уже используется на другом открытом сокете;
// ADR(mode) – указатель на переменную, включающую опцию (значение переменной 16#1)


Подключение несколько клиентов

Серверный сокет, работающий согласно схемам на рисунках 3 и 6, подходит для обмена данными в режиме точка-точка, когда существует одно входящее клиентское соединение. В случае если к серверу будет подключаться несколько клиентов, может возникнуть путаница с принимаемыми и отправляемыми сообщениями, а также может возникнуть очередь на ожидание подключения.

Для того чтобы эффективно работать с несколькими клиентами, используется функция SysSockSelect(). Данный метод проверяет состояние нескольких идентификаторов сокетов одновременно. Сокеты можно проверять на готовность к чтению, записи или на наличие исключительных ситуаций, то есть ошибок.

Если хотя бы один сокет клиента готов, например, к отправке данных, SysSockSelect() сообщит об этом программе и соединение с данным клиентом будет установлено. Схема работы серверного сокета с использованием SysSockSelect() показана на рисунке 5.

Функция SysSockSelect() является блокирующей, она возвращает управление, если хотя бы один из проверяемых сокетов готов к выполнению соответствующей операции. Но в качестве настройки в функции можно указать интервал времени, по прошествии которого она вернет управление в любом случае.


Рис. 7. Схема работы сокетов с использованием функции SysSockSelect()

result:= SysSockSelect(maxConnections+1, ADR(readSet), ADR(writeSet), ADR(exceptSet), ADR(timeSelect), ADR(socketReady));
// maxConnections+1 – количество проверяемых дескрипторов. В качестве аргумента
// устанавливается максимальное количество соединений + 1;
// ADR(readSet), ADR(writeSet), ADR(exceptSet) - указатель на набор дескрипторов;
// (SOCKET_FD_SET), которые следует проверять на готовность к чтению, записи и
// наличию исключительных ситуаций;
// SysSockSelect() – является блокирующей функцией, она возвращает управление, если
// хотя бы один из проверяемых сокетов готов к выполнению соответствующей операции;
// ADR(timeSelect) - указатель на интервал времени timeSelect, по прошествии которого
// функция вернет управление в любом случае;
// timeSelect имеет стуктуру SOCKET_TIMEVAL и задает максимальное время, которое
// функция SysSockSelect будет ожидать для получения ответа;
// ADR(socketReady) – указатель на количество сокетов, готовых к работе, которое
// возвращает функция SysSockSelect.


Наверх

Программа сокетов для CPM723

В проектах TCP_UDP_Sockets.project и 2xPLCs_Sockets.project, входящих в комплект поставки программного обеспечения Fastwel I/O, реализованы программы TCP сокетов и UDP сокетов на языках ST и CFC стандарта МЭК 61131-3.

Структура проекта TCP_UDP_Sockets.project указана на рисунке 8. В данном проекте реализовано два проекта для UDP и TCP сокетов, для работы в рамках одного контроллера CPM723-01. В первом проекте CPM723_LOCAL_CFC работа сокетов реализована с помощью функциональных блоков, вызываемых в программах (язык CFC). Во втором проекте CPM723_LOCAL_ST работа сокетов реализована в программах (язык ST).


Рис. 8. Структура проекта TCP_UDP_Sockets.project

В проекте 2xPLCs_Sockets.project реализован пример для двух контроллеров CPM723-01, обменивающихся данными по протоколу TCP. На первом контроллере ClientsTCP реализованы TCP сокеты клиентов, на втором контроллере ServerTCP – TCP сокет сервера. Структура проекта указана на рисунке 9.


Рис. 8. Структура проекта TCP_UDP_Sockets.project

Наверх

Заключение

Сокеты отвечают за обмен данными между различными устройствами и процессами. На базе обмена данными по сокетам можно создавать протоколы стека TCP/IP более высокого уровня.

TCP сокеты необходимо там, где требуется надежная доставка сообщений, а скорость передачи данных не критична. UDP сокеты лучше всего использовать там, где нужна эффективность на быстрых сетях с короткими соединениями и данные реального времени, а гарантированность доставки сообщений не нужна.

Наверх