Pull to refresh

Comments 33

Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.

Прошу не вводить в заблуждение:
QoS — и гарантировать доставку сообщения адресату.
— не гарантирует доставку сообщения. Он лишь расставляет приоритеты. Крайне полезная штука, при мало скоростном соединении.
Линк почитать про QoS


Согласен с автором QoS может делать выше указанное. Иной ресурс с описанием
Термин QoS не описывает конкретный протокол. В данном случае может одновременно использоваться QoS на сетевом уровне в виде ToS маркера в IP пакетах и на прикладном уровне внутри протокола mqtt. Будет QoS внутри QoS.
UFO just landed and posted this here
По поводу топиков: приведённые в примерах топики, а оторые начинаются со слэша — плохая практика. По стандарту первый слэш не нужен, в данном случае он приводит к созданию первого уровня с пустым именем.
/home/something — в данном случае home находится на втором уровне.
Правильнее писать
Home/something
Да, Вы правы. Эта путаница возникла из-за синтаксиса mosquitto, который требует первый слеш для отделения топика от порта. Начальный слеш при этом игнорируется и не передается в топик.


mqtt(s)://[username[:password]@]host[:port]/topic


Спасибо за внимательность.
И ещё маленький комментарий — топики чувствительны к регистру. HOME не равно home
Пароль от брокера действующий. Наверное его нужно поменять, чтобы вам мусора не наслали.
Так и задумано, что все команды из статьи можно повторить без изменения. Это тестовая учетная запись созданная специально для статьи.
Честно говоря не очень понятна ниша сего протокола, видимо нужно какое-то сравнение, с AMPQ например и т.п.
Ниша — IoT, это по сути легковесная версия AMQP.
Поддерживается во всяких штуках за $1 типа ESP8266 (точнее в ОС для них).
UFO just landed and posted this here
<Делать QoS поверх TCP/IP — это излишне (в статье не указано, но вообще-то, MQTT может работать поверх UDP, RS-232/485, WebSocket — частично QoS оправдан)
Расчёт на ненадёжное TCP — то есть, то нет, то косячит.
А с учётом ещё одной «фишки» — will-сообщений (типа «завещание на случай нежданной смерти»), вообще очень надёжная и предсказуемая система может получиться.
Что касается ресурсоёмкости, то впринципе самое ресурсоёмкое — шифрование трафика. Остальное для простых устройств не так уж и сложно и ресурсоёмко.
Т.е., если «открытым текстом», то вполне под силу и совсем лёгким железкам.
UFO just landed and posted this here

Что TCP работает через пень-колоду? Редко бывает? По редиоканалу? GSM?
А серверу мало понимать. Понимать должны устройства и программы, работающие совместно с устройством с ненадёжноф связью. И "умершее" устройство должно уметь гарантированно сообщить о своей смерти. Протокол эту проблему решает.
На 8 битной железке с 16кБ ОЗУ и 32 ПЗУ даже интерпретатор бейсика когда-то неплохо работал.
И кто Вас заставляет Json пихать? Хоть в бинарном виде сообщения отдавайте. Протокол и это позволяет. А хочется с 8 битной железкой работать, так и работайте на соответствующем уровне.
Странно ставить в вину протоколу, что 8 битная железка не умеет h264 на лету кодировать. :)
И да. этот протокол не для того, чтобы "в жёстком реальном времени глолову с ногами соединять", а в основном для того, чтобы обеспечить обмен данными между функционально самостоятельными устройствами.

UFO just landed and posted this here
Вы это всё ещё про mqtt рассуждаете?
Кстати, какой там максимальный размер сообщения и сколько их может одновременно храниться?
UFO just landed and posted this here

Все же у Mqtt и MODBUS разные ниши. Modbus rtu/ascii можно использовать в реальном времени, а mqtt, из-за завязки на tcp/ip уже нельзя.

Что такое реальное время? Profinet тоже TCP/IP. Modbus TCP?
MQTT ориентирован на децентрализованную систему независимых устройств, как по-моему. А Modbus для работы с одной главной управляющей машиной.

Ну, скажем, принимать и передавать данные каждые 20 мс без изменения порядка.

Самая простая, и довольно точная аналогия для описания MQTT — «чат для железок».
Впринципе, можно использовать и для обмена сообщениями между людьми. :)
А может кто-нибудь подсказать, как снифить траффик, проходящий от клиента к брокеру? Что-то вроде Charles или Fiddler, только для mqtt

Немного не то что Вы хотите, но как вариант можно использовать mqtt-spy. Подключиться к брокеру и подписаться на все топики (#).

Я не совсем понял — а если 2 подписчика qos 2 сообщения — каждый получит по 2? А если один подписался позднее? Хранит ли брокер сообщения так, чтобы при подписке новым subscriber я гарантирванно получал всю историю сообщений?

хранит только последнее сообщение помеченное retain

Самый большой недостаток в MQTT протоколе, на мой взгляд, это то что нельзя перебрать содержимое MQTT брокера, хотя бы получить список опубликованных топиков.
Можно публиковать сообщения с флагом retain, тогда при подключении вы получите последние сообщения опубликованные в топики.
А что можете сказать про существующие брокеры? С полгода назад ресёрчил данный вопрос, из более-менее встречающихся в интернете пишут про emqtt и его наследник (как я понял) emqx, либо же VerneMQ, про другие — крайне мало информации. Приходилось ли кому-нибудь сталкиваться с указанными брокерами? Или если используете другой брокер — расскажите, плз, какой.
в то время как в Modbus/TCP подключение инициирует сервер (master)

Позвольте уточнить. В Modbus/TCP действительно master инициирует соединение, но master это клиент. Сервер это slave. Если за NAT клиенты, то проброс портов не нужен.
Sign up to leave a comment.