Кибернетика, автоматика, протоколы

базовом уровне транспорта этот MQTT есть поллинг, причем все есть клиенты (в т.ч. в традиционном понимании мастер тоже есть клиент), и только сервер, который до недавнего <span>в документах </span>стыдливо называли брокером, имеет основную задачу - прием данных от клиентов или их отдачу клиентам. Грубо (что касается поллинга) некий аналог USB (кроме случая изохронного потока). В MQTT из маршрутизации по сути аж адрес/порт сервера (брокера) в настройках клиента. Модель обмена данными в MQTT в первом приближении сродни набору чат-комнат по интересам (<i>топики</i>), но чуть более развитая. Для случаев редкого выхода на связь при автономном питании (всякие счетчики энергоресурсов, датчики температуры/влажности и т.п.) - самое то. Простота использования часто тоже многое решает. Из как бы минусов - нет прямого задрачивания ведомого ведущим. С другой стороны если нужен пинг, то это вопрос только энергетики - даже wake-on-radio тоже жрёт. Аналогичный пример - обычный дискретный сигнал а-ля "сухой контакт" с его неопределенностями и дискретный сигнал NAMUR - для него во всех состояниях с высокой степенью вероятности контролируется ещё и состояние канала связи. Но если есть дополнительный сигнал о неисправности канала связи, то что делать? Например, для дискретного сигнала шлейфа сигнализации обрыв есть собственно сигнал вмешательства и оно аж сигнализирует, а если сигнал от счетчика газа - как считать при обрыве провода? Это вопрос системный/организационный. (Для счетчика в соответствующем стандарте написано, что <i>рекомендуется</i> делать). На протокол же валить неопределенности при проблемах/осутствии устойчивого канала/сеанса связи - IMNHO, в корне не верно.

ЗЫ. все гарантии связи заканчиваются словами из песТни - я оглянулся посмотреть, не оглянулась ли она, чтоб посмотреть, не оглянулся ли я...:)