Comments 8
docbox.etsi.org/workshop/2008/2008_06_M2MWORKSHOP/ISMB_FORNO_M2MWORKSHOP.pdf
Та же pub\sub парадигма, броадкаст, мультикаст и уникаст (с небольшим прикрутками на стороне вебсокет сервера).
Но при использовании websocket очевидны приемущества:
— работа через Firewallы
— простое SSL (работает поверх HTTP)
— авторизация посредствам HTTP Basic / HTTP Headers
— в теории абсолютно любой протокол внутри (бинарный\текстовый)
?
В MQTT eсть QoS :) Чуть-чуть более компактный, что обычно довольно критично для IoT. TLS тоже штука не всегда доступная на IoT, да и не нужная особо, на крайний случай можно и payload на L7 зашифровать.
Шифруя на L7 есть риск наступить на множество граблей, которые уже были решены при разработке TLS.
Где я ошибаюсь в своем понимании мира?
Не следует путать QoS и приоритеты трафика на роутерах. Хоть IP QoS, как правило, так или иначе сводится к приоритетам — это всего лишь деталь реализации.
QoS — это требования к надёжности и срочности доставки сообщения. Надёжность достигается квитированием и повторными попытками передачи, а вовсе не роутерами и транспортным уровнем. Срочность влияет на порядок передачи сообщений. В принципе, её как раз было бы неплохо продублировать и на сетевом уровне — вот только без специального договора с провайдером никто в итоге не посмотрит на это поле, что делает затею бессмысленной. И да, судя по тому что я увидел, срочностю сообщений MQTT не управляет.
Кроме того MQTT хорошо подходит для распределенной реактивной разработки.
Протокол MQTT: концептуальное погружение