前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >手把手教你入门AIoT(2)

手把手教你入门AIoT(2)

作者头像
刘盼
发布2019-03-15 17:18:07
6620
发布2019-03-15 17:18:07
举报
文章被收录于专栏:人人都是极客人人都是极客

Client 在可以发布和订阅消息之前,必须先连接到 Broker,下面我们来看一下 Client 连接到 Broker 的流程。本节课核心内容:

  • Client 连接到 Broker 的流程
  • CONNECT
  • CONNACK

Client 连接到 Broker 的流程

Client 建立到 Broker 的连接流程如下图所示:

CONNECT:

连接的建立由 Client 端发起,Client 端首先向 Broker 发送一个 CONNECT 数据包,CONNECT 数据包包含以下内容(这里我们略过 Fixed header)。

1.可变头(Variable header)

在 CONNECT 数据包可变头中,含有以下信息。

协议名称(Protocol Name):值固定为字符 “MQTT”。

协议版本(Protocol Level):对 MQTT 3.1.1 来说,值为 4。

用户名标识(User Name Flag):消息体中是否有用户名字段,1bit,0 或者 1。

密码标识(Password Flag):消息体中是否有密码字段,1bit,0 或者 1。

遗愿消息 Retain 标识(Will Retain):标识遗愿消息是否是 Retain 消息,1bit,0 或者 1。

遗愿消息 QOS 标识(Will QOS):标识遗愿消息的 QOS,2bit,0、1 或者 2。

遗愿标识(Will Flag):标识是否使用遗愿消息,1bit,0 或者 1。

会话清除标识(Clean Session):标识 Client 是否建立一个持久化的会话,1bit,0 或者 1,当 Clean Session 的标识设为 0 时,代表 Client 希望建立一个持久会话的连接,Broker 将存储该 Client 订阅的主题和未接受的消息,否则 Broker 不会存储这些数据,同时在建立连接时清除这个 Client 之前存在的持久化会话所保存的数据。

连接保活(Keep Alive): 设置一个单位为秒的时间间隔,Client 和 Broker 之间在这个时间间隔之内需要至少有一次消息交互,否则 Client 和 Broker 会认为它们之间的连接已经断开。

2.消息体(Payload)

CONNECT 数据包的消息体中包含以下数据。

客户端标识符(Client Identifier):Client Identifier 是用来标识 Client 身份的字段,在 MQTT 3.1.1 的版本中,这个字段的长度是 1 到 23 个字节,而且只能包含数字和 26 个字母(包括大小写),Broker 通过这个字段来区分不同的 Client。所以在连接的时候,Client 应该保证它的 Identifier 是唯一的,通常我们可以使用比如 UUID,唯一的设备硬件标识,或者 Android 设备的 DEVICE_ID 等作为 Client Identifier 的取值来源。

MQTT 协议中要求 Client 连接时必须带上 Client Identifier,但是也允许 Broker 在实现时 Client Identifier 为空,这时 Broker 会为 Client 分配一个内部唯一的 Identifier。如果你需要使用持久化会话,那就必须自己为 Client 设定一个唯一的 Identifier。

用户名(Username):如果可变头中的用户名标识设为 1,那么消息体中将包含用户名字段,Broker 可以使用用户名和密码来对接入的 Client 进行验证,只允许已授权的 Client 接入。注意不同的 Client 需要使用不同的 Client Identifier,但它们可以使用同样的用户名和密码进行连接。

密码(Password):如果可变头中的密码标识设为 1,那么消息体中将包含密码字段。

遗愿主题(Will Topic):如果可变头中的遗愿标识设为 1,那么消息体中将包含遗愿主题,当 Client 非正常地中断连接的时候,Broker 将向指定的遗愿主题中发布遗愿消息。我们会在后续的课程里面详细讨论。

遗愿消息(Will Message):如果可变头中的遗愿标识设为 1,那么消息体中将包含遗愿消息,当 Client 非正常地中断连接的时候,Broker 将向指定的遗愿主题中发布由该字段指定的内容。我们会在后续的课程里面详细讨论。

CONNACK:

当 Broker 收到 Client 的 CONNECT 数据包之后,将检查并校验 CONNECT 数据包的内容,之后回复 Client 一个 CONNACK 数据包。

CONNACK 数据包包含以下内容(这里我们略过 Fixed header)。

1.可变头(Variable header)

CONNACK 数据包的可变头中,含有以下信息。

会话存在标识(Session Present Flag):用于标识在 Broker 上,是否已存在该 Client(用 Client Identifier 区分)的持久性会话,1bit,0 或者 1。当 Client 在连接时设置 Clean Session=1,则 CONNACK 中的 Session Present Flag 始终为 0;当 Client 在连接时设置 Clean Session=0,那么就有两种情况——如果 Broker 上面保存了这个 Client 之前留下的持久性会话,那么 CONNACK 中的 Session Present Flag 值为 1;如果 Broker 没有保存该 Client 的任何会话数据,那么 CONNACK 中的 Session Present Flag 值为 0。Session Present Flag 这个特性是在 MQTT 3.1.1 版本中新加入的,之前的版本中并没有这个标识。

连接返回码(Connect Return code):用于标识 Client 是 Broker 的连接是否建立成功,连接返回码有以下一些值:

Return Code

连接状态

0

连接已建立

1

连接被拒绝,不允许的协议版本

2

连接被拒绝,Client Identifier 被拒绝

3

连接被拒绝,服务器不可用

4

连接被拒绝,错误的用户名或密码

5

连接被拒绝,未授权

这里重点讲一下 Return Code 4 和 5。Return Code 4 在 MQTT 协议中的含义是 Username 和 Password 的格式不正确,但是在大部分的 Broker 实现中,在使用错误的用户名密码时,得到的返回码也是 4。所以这里我们认为 4 就是代表错误的用户名或密码。Return Code 5 一般在 Broker 不使用用户名和密码而使用 IP 地址或者 Client Identifier 进行验证的时候使用,来标识 Client 没有通过验证。

2.消息体(Payload)

CONNACK 没有消息体。

当 Client 向 Broker 发送 CONNECT 数据包并获得 Return Code 为 0 的 CONNACK 包后,就代表连接建立成功,可以发布和接受消息了。

小结

本节课我们了解了 Client 连接到 Broker 的流程,接下来我们学习连接的关闭,以及 MQTT 连接建立与关闭的实例代码。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-02-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 人人都是极客 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档