明珠的个人博客

今天晚上健身的时候，月色很美，风也温柔。突然就想到了信仰的问题，当然，这是个十分宽泛的话题，所以，我只分享下自己的看法：就是觉得一直没想通是什么使我如此坚定不移，现在我可以很坚定地回应自己：没有为什么，没有自己的原因，一切皆在于神！耶和华是我的牧者，他使我的灵魂苏醒，为自己的名引导我走义路

继续，这是8/20周末的，迟来
另附随想：
工作闲暇之余，能够有时间去练字、喝茶、听曲、学习，属实人生乐事

继续

练字开课，实在是看不下去自己的字体了…
楷书，今天第一天，笔画练习

先分享一段话，不一定大家或者我都认可，但是看了后感觉很有感触，所以拿出来分享下：

at the beggining of a relationship, everything is thrilling and it’s new, and you feel as a couple nothing can hurt you, and then you gradually start to realize that actually, anything can hurt you…

地点报备：工作地点从徐州贾汪换到了徐州铜山万达附近

一切安好

博学，审问，慎思，明辨，笃行

博学，审问，慎思，明辨，笃行

博学，审问，慎思，明辨，笃行

用户密码认证

MQTT客户端连接服务端的基本过程是：客户端通过CONNECT报文，向服务端发起连接请求。CONNECT报文所包含的具体信息内容如下：

到目前为止，我们已经将CONNECT报文中的信息大部分讲解完毕，目前只剩下上图中红色方框所标注的username(用户名)和password（密码）。这里的用户名和密码是用于客户端连接服务端时进行认证需要的。

有些MQTT服务端需要客户端在连接时提供用户名和密码。只有客户端正确提供了用户名和密码后，才能连接服务端。否则服务端将会拒绝客户端连接，那么客户端也就无法发布和订阅消息了。

请注意，username(用户名)和password（密码）是可选的CONNECT信息。也就是说，有些服务端

心跳机制

在医院里，医生利用心跳来判断患者是否还有生命体征。对于MQTT服务器来说，它要判断一台MQTT客户端是否依然保持连接可以检查这台客户端是不是经常发送消息给服务端。如果经常收到客户端的消息，那么没问题，这个客户端肯定在线。

但是有些客户端并不经常发送消息给服务端。对于这种客户端，服务端可以使用类似心跳检测的方法，来判断客户端是否在线。

不过客户端设备没有心脏，自然不会跳动。可是我们可以为它们配上一个类似心脏的机制，这个心脏机制就是让客户端在没有向服务端发送信息时，可以定时向服务端发送一条消息。这条用于心跳机制的消息也被称作心跳请求（PINGREQ）。心跳请求的作用正是用于告知服务端，当前客户端依然在线。服务端在收到客户端的心跳请求后，会回复一条消息。这条回复消息被称作心跳响应（PINGRESP）。

由于心跳请求是客户端定时发送的，一旦服务端发现

很喜欢一段话：
“任何事和人，时间终究会给我们答案，在细水长流的日子里，不说永远，只说珍惜”

“保留消息”是十分重要的MQTT概念。通过“保留消息”这一名称不难判断，“保留消息”是一种被保留下来的消息。但是这个“保留消息”为何要被保留？而保留消息又是有什么特殊的用途？

保留消息的作用

要讲明“保留消息”这一概念，我们先看一个场景。假设我们正在利用MQTT协议开发一套智能家居物联网系统。在该系统中有一台专门用于检测和发布室温信息的MQTT客户端，它每到整点时就会测量当前室温并且向MQTT服务端发布室温测量结果。

假设在该智能家具物联网系统中，还有一台环境信息显示客户端。这台客户端的作用就是把当前的室温显示在屏幕上以便我们实时了解室内温度。换句话说，这台环境信息显示客户端一启动就会订阅室温主题，这样室温检测客户端一发布消息，显示客户端就能获取到最新的温度消息并显示在屏幕上了。

假设某天上午7：00，我们的室温检测客户端将最新的室温消息发布到了服务端，那么订阅了室温消息的显示客户端也就马上获取到室温消息并且显示在屏幕上。

然而在7：10的时候，家里的小狗不小心把显示客户端的电源碰掉了，显示客户端没有电也就自动关机了。我们发现这一问题后，马上把显示客户端重新通电，客户端通电启动后会立刻订阅室温主题。

但这时候问题出现了，

重点：

• QoS = 0 – 最多发一次
• QoS = 1 – 最少发一次
• QoS = 2 – 保证收一次

Qos服务质量简介

一个物联网系统中有些信息非常重要，我们需要确保这类重要信息可以准确无误的发送和接收，而有些信息则相对不那么重要，这类信息如果在传输中丢失不会影响系统的运行。

MQTT服务质量(Quality of Service 缩写 QoS)正是用于告知物联网系统，哪些信息是重要信息需要准确无误的传输，而哪些信息不那么重要，即使丢失也没有问题。

MQTT协议有三种服务质量级别：

QoS = 0 – 最多发一次
QoS = 1 – 最少发一次
QoS = 2 – 保证收一次

以上三种不同的服务质量级别意味着不同的MQTT传输流程。对于较为重要的MQTT消息，我们通常会选择QoS>0的服务级别（即QoS 为1或2）。

另外这里提到的“发”与“收”有两种可能。一种是客户端发布消息时，将消息发送给服务端。一种是客户端订阅了某一主题消息后，服务端将消息发送给客户端。因此发布消息和接收消息的可能是服务端也可能是客户端。

为了避免造成混淆，后面的描述中将使用“发送端”来描述发送MQTT消息的设备，而使用“接收端”来描述接收MQTT消息的设备。

接下来我们仔细看一下这三种服务质量级别的具体含义。

QoS = 0 – 最多发一次

0是服务质量QoS的最低级别。当QoS为0级时，MQTT协议并不保证所有信息都能得以传输。也就是说，QoS=0的情况下，

重点：

• 1. 主题基本形式
• 2. 主题分级
• 3. 主题通配符
• 4. 主题应用注意事项
• 5. 测试验证
• 6. 主题订阅程序示例

主题基本形式

主题的最基本形式就是一个字符串。以下是几个主题示例：

• myTopic
• motorSpeed
• MotorSpeed
• current time

注意：

1. 主题是区分大小写的。如上列表中的主题 motor_speed和Motor_speed是两个完全不同的主题。
2. 主题可以使用空格 如以上列表中的current time，虽然有空格分隔current和time这两个词，但这实际是一个MQTT主题。不过，虽然我们可以使用空格，但是！！！强烈建议不要在主题中使用空格。我们在开发时一不小心，可能就会漏掉空格，这将造成不必要的麻烦。
3. 大部分MQTT服务端是不支持中文主题的，所以我们应使用英文字符或ASCII字符来作为MQTT主题。

主题分级

MQTT主题可以是一个简单的字符串，比如motor_speed，myTopic。这些都是单一级别的主题。

为了更好的对主题进行管理和分类，我们可以对主题进行分级处理。MQTT主题各个级别之间可以使用”/”来分隔。如下例所示：

Tyler-1/motor/1/speed

在以上示例中一共有四级主题，分别是第1级 Tyler-1、第2级motor、第三级1、第4级speed。主题的每一级至少需要一个字符，比如以上示例中，数字1即是一级主题。

我们再来看几个分级主题的示例：