Advantech IIoT corporate blog
Industrial Programming
Comments 32
0
Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.

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


Согласен с автором QoS может делать выше указанное. Иной ресурс с описанием
+1
Термин QoS не описывает конкретный протокол. В данном случае может одновременно использоваться QoS на сетевом уровне в виде ToS маркера в IP пакетах и на прикладном уровне внутри протокола mqtt. Будет QoS внутри QoS.
0

Мне всегда было интересно, а как вообще пакет может быть не доставлен, если MQTT работает поверх TCP, который гарантирует доставку? Разве что если устройство-получатель вообще сдохлотполностью или отключилось, а при установлении связи с ним брокер будет пытаться отправить посылку ещё раз...

0
По поводу топиков: приведённые в примерах топики, а оторые начинаются со слэша — плохая практика. По стандарту первый слэш не нужен, в данном случае он приводит к созданию первого уровня с пустым именем.
/home/something — в данном случае home находится на втором уровне.
Правильнее писать
Home/something
0
Да, Вы правы. Эта путаница возникла из-за синтаксиса mosquitto, который требует первый слеш для отделения топика от порта. Начальный слеш при этом игнорируется и не передается в топик.


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


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

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

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

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

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

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

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

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

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

Позвольте уточнить. В Modbus/TCP действительно master инициирует соединение, но master это клиент. Сервер это slave. Если за NAT клиенты, то проброс портов не нужен.
Only those users with full accounts are able to leave comments. , please.