SHIHUC

好记性不如烂笔头,还可以分享给别人看看! 专注基础算法,互联网架构,人工智能领域的技术实现和应用。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

MQTT研究之EMQ:【EMQX使用中的一些问题记录(4)】

Posted on 2019-11-29 20:03  shihuc  阅读(4270)  评论(0编辑  收藏  举报

最近比较忙,有些关于EMQ的使用问题,没有时间记录了,趁这个周末抽点时间,将最近遇到的,觉得比较有价值的一个问题,分享给大家吧。

 

这里是针对前面的一篇博客,做的一个深入研究,关于订阅系统总线判断设备上线还是下线的补充研究。基于报文内容进行分析连接的细分信息,有一定的帮助。

 

 

1. 正常的连接

应用服务能够订阅到来自$SYS/brokers/+/clients/+/connected主题的数据。如下:这里能看到设备连接到那个EMQX节点,且知道设备端的配置信息,例如用户名,是否cleansession,clientId等等。这里有一个能反应出设备正常连接的状态字段connack,值为0表示正常连接上了。

Qos : 0, Topic :$SYS/brokers/emqx@10.95.200.17/clients/res10/connected, ClientId: emqXmonitor
Sub : {"clean_start":true,"clientid":"res10","connack":0,"ipaddress":"10.95.177.137","keepalive":60,"proto_name":"MQTT","proto_ver":4,"ts":1573542651092,"username":"water"}

当连接断开时(前提是连接正常的连接进来了,即$SYS/brokers/+/clients/+/connected的主题上进来的数据,对应connack的值为0),订阅了$SYS/brokers/+/clients/+/disconnected主题的应用服务,会收到报文如下。这里会发现,报文内容显示了clientId,username以及断开的原因和具体时间点。这里重点要说的是reason字段。下面这个报文显示断开的原因是normal,即正常断开,我这里是基于MQTT.fx模拟的客户端,点击了disconnect按钮实现的。

Qos : 0, Topic :$SYS/brokers/emqx@10.95.200.17/clients/res10/disconnected, ClientId: emqXmonitor
Sub : {"clientid":"res10","username":"water","reason":"normal","ts":1573542664914}
Qos : 0, Topic :$SYS/brokers/emqx@10.95.200.17/clients/res10/connected, ClientId: emqXmonitor
Sub : {"clean_start":true,"clientid":"res10","connack":0,"ipaddress":"10.95.177.137","keepalive":60,"proto_name":"MQTT","proto_ver":4,"ts":1573542687466,"username":"shihuc"}

下面这个断开,就和上面那个disconnected的报文有点不同,主要是reason的内容不同,这里是closed,标识关闭。说明下,我这里是通过点击MQTT.fx软件右上角的红色X实现的。

Qos : 0, Topic :$SYS/brokers/emqx@10.95.200.17/clients/res10/disconnected, ClientId: emqXmonitor
Sub : {"clientid":"res10","username":"shihuc","reason":"closed","ts":1573542804049}

 

2. 不正常的连接

注意啦,注意啦,这里是connected主题上的报文,显示连接上来了,但是呢,看看connack字段的内容,不是0哟,说明这次连接不是正常的。现象也的确是没有连接上来,因为我的mysql mqtt_user表里面没有abc这个用户,MQTT.fx显示的连接失败的原因是未授权用户。

Qos : 0, Topic :$SYS/brokers/emqx@10.95.200.17/clients/res11/connected, ClientId: emqXmonitor
Sub : {"clean_start":true,"clientid":"res11","connack":135,"ipaddress":"10.95.177.137","keepalive":60,"proto_name":"MQTT","proto_ver":4,"ts":1573542986787,"username":"abc"}

下面这个connected消息,和上面的基本一样,下面这个是未授权用户(Not authorized to connect)对应的第二次connected报文。起初,按照我的理解,这里应该是disconnected报文,但是给MQTT官方的github上项目提的issue显示,只有正常连接上线的设备,才会给他下发disconnected消息。否则只有connected消息,通过connack的内容进行细化区分。为何这里会出现两次connected的消息呢?从paho的客户端是可以看得出信息的,首先会从默认的MQTT V4开始

Qos : 0, Topic :$SYS/brokers/emqx@10.95.200.17/clients/res11/connected, ClientId: emqXmonitor
Sub : {"clean_start":true,"clientid":"res11","connack":135,"ipaddress":"10.95.177.137","keepalive":60,"proto_name":"MQIsdp","proto_ver":3,"ts":1573542986802,"username":"abc"}

 

3. 连接的状态的协议说明

这里主要涉及的就是CONNACK这个消息了,参照协议,就不难理解上面报文中的connack的信息了。

我这里用的协议版本是MQTT的V3.1.1, 所以呢,将里面的重点内容摘抄出来,方便查看。一个结论,connack不是0的时候,就要注意是不是有什么问题了