MQTT чихал на маршрутизацию. Для сверху вниз её надо прокладывать и
этим кто-то должен заниматься - недостаточно просто какого-то
протокола. Особенно актуально для случаев работы из-за NATа и/или
неадресуемых сетей/соединений. Там (за NAT) без выхода клиента
снизу и поллинга сервера (например, VPN, и как самое простое GRE)
для поддержания TCP-соединения активным (чаще 1 раз в 2 минуты)
толком никто ничего ещё не предлагал, ибо опять та же
маршрутизация. Соответственно на базовом уровне транспорта этот MQTT есть поллинг, причем все есть клиенты (в т.ч. в традиционном понимании мастер тоже есть клиент), и только сервер, который до недавнего <span>в документах </span>стыдливо называли брокером, имеет основную задачу - прием данных от клиентов или их отдачу клиентам. Грубо (что касается поллинга) некий аналог USB (кроме случая изохронного потока). В MQTT из маршрутизации по сути аж адрес/порт сервера (брокера) в настройках клиента. Модель обмена данными в MQTT в первом приближении сродни набору чат-комнат по интересам (<i>топики</i>), но чуть более развитая. Для случаев редкого выхода на связь при автономном питании (всякие счетчики энергоресурсов, датчики температуры/влажности и т.п.) - самое то. Простота использования часто тоже многое решает. Из как бы минусов - нет прямого задрачивания ведомого ведущим. С другой стороны если нужен пинг, то это вопрос только энергетики - даже wake-on-radio тоже жрёт. Аналогичный пример - обычный дискретный сигнал а-ля "сухой контакт" с его неопределенностями и дискретный сигнал NAMUR - для него во всех состояниях с высокой степенью вероятности контролируется ещё и состояние канала связи. Но если есть дополнительный сигнал о неисправности канала связи, то что делать? Например, для дискретного сигнала шлейфа сигнализации обрыв есть собственно сигнал вмешательства и оно аж сигнализирует, а если сигнал от счетчика газа - как считать при обрыве провода? Это вопрос системный/организационный. (Для счетчика в соответствующем стандарте написано, что <i>рекомендуется</i> делать). На протокол же валить неопределенности при проблемах/осутствии устойчивого канала/сеанса связи - IMNHO, в корне не верно.
ЗЫ. все гарантии связи заканчиваются словами из песТни - я оглянулся посмотреть, не оглянулась ли она, чтоб посмотреть, не оглянулся ли я...:)
Vit (15.02.2022 01:22, просмотров: 615) ответил LordN на что такого хитрого в MQTT что на него все надрачивают?