mqtt

In this post i provides some information about MQTT Servers/Brokers. And discuss about comparison and Limitation between different MQTT Servers/Brokers. What is MQTT Protocol ? Message Queuing Telemetry Transport Protocol (MQTT) MQTT is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport and useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via

方便测试用 MQTT Public Brokers field value address mqtt.flespi.io port 1883 (TCP), 80 (WebSocket), 8883 (SSL), 443 (Secure WebSockets) type flespi info requires signup/username, information page , REST API , MQTT 5.0 compliant field value address iot.eclipse.org port 1883 , 80 (WebSockets), 443 (WebSockets+SSL) type mosquitto info web page , Xively statistics , topics and HTTP bridge You may like also: What is MQTT? | IoT Data Protocol | IoT Wireless Protocol field value address test.mosquitto.org port 1883 , 8883 (SSL), 8884 (SSL), 80 (WebSockets) type mosquitto info web page , Xively statistics ,

Web MQTT Board – diagnostic oriented MQTT 5.0 client tool based on mqtt.js . Available in open source . MQTT over websockets (experimental) – from the mosquitto project. HiveMQ Websockets Client – a websocket based client for your browser which supports publishing & subscribing. mqtt-svg-dash – SVG “live” dashboard from MQTT. mqtt-panel – a web interface for MQTT. ThingStudio – ThingStudio allows you create real-time HTML5 user interfaces for MQTT devices by writing simple HTML templates. Moquette – an open source JAVA broker for MQTT protocol. IOTSIM.IO – SaaS MQTT lab. Mobile platforms MQTT

目录 前言 自签 CA 并签发证书 创建证书 单向认证测试 双向认证测试 自签二级 CA 并签发证书 创建证书 单向认证测试 双向认证测试 前言 EMQ X 内置对 TLS/DTLS 的支持，包括支持单双向认证、X.509 证书等多种身份认证和 LB Proxy Protocol V1/2 等。你可以为 EMQ X 支持的所有协议启用 TLS/DTLS，也可以将 EMQ X 提供的 HTTP API 配置为使用 TLS。本文以自签证书的方式介绍如何在 EMQ X 中为 MQTT 启用 TLS。 自签 CA 并签发证书 创建证书 1.准备 $ docker pull centos:centos7 $ docker run -it --name centos7 centos:centos7 /bin/sh $ yum install openssl $ yum install vim $ mkdir /opt/ssl $ cd /opt/ssl/ $ cp /etc/pki/tls/openssl.cnf ./ $ rm -rf /etc/pki/CA/*.old ## 生成证书索引库数据库文件 $ touch /etc/pki/CA/index.txt ## 指定第一个颁发证书的序列号 $ echo 01 > /etc/pki/CA/serial $ rm -rf certs

EMQ X Enterprise Rule Engine Rule Engine (以下简称规则引擎) 用于配置 EMQ X 消息流与设备事件的处理、响应规则。作为 2019 年度 EMQ X 新增重量级功能，规则引擎不仅提供了清晰、灵活的"配置式"的业务集成方案，用于简化业务开发流程，提升用户易用性，降低业务系统与 EMQ X 的耦合度；也为 EMQ X 的私有功能定制提供了一个更优秀的基础架构，提升开发交付速度。 规则引擎开源版本提供了基础处理能力，已集成在 EMQ X v3.1.0 中发布。功能更灵活完备、可用性定制性更强的规则引擎正在紧密开发测试，计划集成在下一 EMQ X 商业版中发布。 规则引擎典型应用场景举例： 动作监听：智慧家庭智能门锁开发中，门锁会因为网络、电源故障、人为破坏等原因离线导致功能异常，使用规则引擎配置监听离线事件向应用服务推送该故障信息，可以在接入层实现第一时间的故障检测的能力； 数据筛选：车辆网的卡车车队管理，车辆传感器采集并上报了大量运行数据，应用平台仅关注车速大于 40 km/h 时的数据，此场景下可以使用规则引擎对消息进行条件过滤，向业务消息队列写入满足条件的数据； 消息路由：智能计费应用中，终端设备通过不同主题区分业务类型，可通过配置规则引擎将计费业务的消息接入计费消息队列并在消息抵达设备端后发送确认通知到业务系统

MQTT 5.0 协议相比 MQTT 3.1.1 增加了很多属性，这些属性分布于报文的可变头部 ( Variable Header ) 和有效载荷 ( Payload ) 中。 MQTT 5.0 协议中携带有效载荷的报文有 CONNECT 报文，PUBLISH 报文，SUBSCRIBE 报文，SUBACK 报文，UNSUBSCRIBE 报文和 UNSUBACK 报文。 PUBLISH 报文的有效载荷负责存储消息内容，与 MQTT 3.1.1 协议相同。 CONNECT 报文 CONNECT 报文的可变头部新增的属性有: 在 CONNECT 报文的 Payload 中，部分字段发生了变化，遗嘱消息（Will Message）变成了遗嘱载荷（Will Payload）。Payload 中新增了遗嘱属性（Will Properties），用于定义遗嘱消息的行为。 新增的遗嘱属性有: CONNACK 报文 CONNACK 报文没有 Payload，在可变头部中包含的属性有： PUBLISH 报文 PUBLISH 报文可变头部的属性有： PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK 报文 PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK 都具备以下三个属性： SUBSCRIBE 报文

MQTT 与 Kafka 是完全不同的两个东西， MQTT 是协议，是一个技术标准，由 OASIS 技术委员会的成员（其成员多数为 IBM 和微软的顶级工程师）制订。而 Kafka 是已经实现的开源流处理平台，最早由 LinkedIn 开发，于2011年开源后交给 Apache Incubator 孵化后成为了 Apache 软件基金会的顶级项目。 两者之前唯一存在的联系恐怕就是它们都和发布/订阅范式有关了吧。MQTT 是基于发布/订阅范式的消息协议，而 Apache Kafka 的生产、消费的流程也是属于发布/订阅范式的。那么如果我们基于 MQTT 协议去实现一个消息 broker ，是否这个 MQTT broker是否能和 Kafka 作用等价呢？ 答案当然是否定的！ Kafka 虽然也是基于发布订阅范式的消息系统，但它同时也被称为“分布式提交日志”或者“分布式流平台”，它的最主要的作用还是实现分布式持久化保存数据的目的 。Kafka 的数据单元就是消息，可以把它当作数据库里的一行“数据”或者一条“记录”来理解，Kafka 通过主题来进行分类，Kafka 的生产者发布消息到某一特定主题上，由消费者去消费特定主题的消息，其实生产者和消费者就可以理解成发布者和订阅者，主题就好比数据库中的表，每个主题包含多个分区，分区可以分布在不同的服务器上

MQTT 的全称为 Message Queue Telemetry Transport（消息队列遥测传输协议），是在 1999 年，由 IBM 的 Andy Stanford-Clark 和 Arcom 的 Arlen Nipper 为了一个通过卫星网络连接输油管道的项目开发的。为了满足低电量消耗和低网络带宽的需求，MQTT 协议在设计之初就包含了以下一些特点： 实现简单 提供数据传输的 QoS 轻量、占用带宽低 可传输任意类型的数据 可保持的会话（session） 之后 IBM 一直将 MQTT 作为一个内部协议在其产品中使用，直到 2010 年，IBM 公开发布了 MQTT 3.1 版本。在 2014 年，MQTT 协议正式成为了 OASIS（结构化信息标准促进组织）的标准协议。简单地来说MQTT协议具有以下特性： 基于 TCP 协议的应用层协议； 采用 C/S 架构； 使用订阅/发布模式，将消息的发送方和接受方解耦； 提供 3 种消息的 QoS（Quality of Service）: 至多一次，最少一次，只有一次； 收发消息都是异步的，发送方不需要等待接收方应答。 下文将从以下四个方面对MQTT的基础概念进行介绍： MQTT 协议的通信模型 MQTT Client MQTT Broker MQTT协议数据包 1. MQTT 协议的通信模型 MQTT 的通信是通过发布