MQTT Broker Mosquitto(二)数据结构

本文主要介绍一下Mosquitto中用到的比较重要的数据结构,为之后的流程处理讲解奠定基础。为了清晰,结构体展示时只保留重要成员。一、mosquitto_dbstruct mosquitto_db{ /*主题树的根结点*/ struct _mosquitto_subhier subs; /*id:context映射的Hash表首节点,通过该成员去遍历Hash表*/ stru

- 阅读全文 -

MQTT Broker Mosquitto(一)简介

写这个系列文章其实出发点有很多。一方面是很早之前看到了一个开源物联网云平台项目,叫做iotgo,有兴趣的同学可以去搜索后了解一下。iotgo使用的是node.js语言编写,是一个物理网设备管理的平台。我抽出了十一假期研究了一下它的源码:它使用angular做前端,前端通过websocket实时从后台获取设备信息,所有的设备通过socket与平台通讯。但是这个框架我还是觉得很别扭,可能在我看来一个网

- 阅读全文 -

MQTT协议(九)——固定报文头

MQTT协议的固定报文头由两个部分组成,第一部分是报文的控制类型与标识,占据1个字节;第二部分是报文的剩余长度,占据1~4个字节。一、控制报文类型与标识控制标识共占一个字节,位于MQTT报文的第1个字节。其中高4位是控制报文类型,低4位是控制标识,如下。控制报文类型共有表格中这些取值。控制标识共有下面表格中这些取值。二、 报文的剩余长度报文的剩余长度用来表示剩下的报文占据字节大小,不含控制报文类型

- 阅读全文 -

MQTT协议(八)——心跳检测

心跳检测是客户端发送给服务端的。协议中关于心跳检测的作用是这样叙述的1.在没有任何其它控制报文从客户端发给服务的时,告知服务端客户端还活着。2.请求服务端发送 响应确认它还活着。3.使用网络以确认网络连接没有断开。一、场景示意图二、协议简述心跳报文较为简单,客户端向服务端发送PING REQ报文,服务端需在合适的时间内回复PING RESP报文。否则客户端将会关闭服务端的连接,当然服务端也将关闭服

- 阅读全文 -

MQTT协议(七)——QoS2发布

QoS2的发布共需要四条报文,以确保接收者收到且仅收到一次消息。一、场景示意图二、协议简述PUBLISH报文可以参加MQTT协议(五)——QoS0发布。PUBLISH REC,PUBLISH REL,PUBLISH COMP报文的结构基本一致。固定报文头。第一个字节是控制报文标识符,紧接着的字节为报文的剩余长度,这个剩余长度是不包含固定报文头的;报文标识符。共两个字节MSB、LSB。所以1中的报文

- 阅读全文 -

MQTT协议(六)——QoS1发布

与QoS0类似,可以是客户端向服务端发布,也可以是服务端向客户端发布消息。但是在QoS1的服务质量中,接收者需要对发布者的消息进行回应。一、场景示意图二、协议简述PUBLISH报文这里不再赘述,参见 MQTT协议(五)——QoS0发布。在QoS1的服务质量下,接收者在收到PUBLISH报文之后需要回应PUBLISH ACK报文。如果由于网络等其它原因发送者没有收到PUBLISH ACK报文,发送者

- 阅读全文 -

MQTT协议(五)——QoS0发布

发布可以使客户端发送给服务端,也可以是服务端发送给客户端。当一个客户端A想发布一条消息时,它应该先把这条消息发布给服务端,然后由服务端作为代理将该条消息发布给所有订阅消息主题的客户端们。一、场景示意图二、协议简述在QoS0的发布中,接收者无须对接收到的发布报文进行回应。这样可以节省时间开销,但是如果网络连接不稳定等状况下很有可能导致发布的消息丢失,所以QoS0也被称为至多一次。固定报文头。第一个字

- 阅读全文 -