0%

MQT 学习

MQTT 学习笔记。

入门

MQTT入门篇

MQTT example

MQTT服务器Mosquitto安装及使用

libraries

[MQTT Essentials – A Lightweight IoT Protocol](../resources/MQTT Essentials – A Lightweight IoT Protocol.epub) — Good Book !!! 🐂

MQTT 是种基于订阅-发布机制的异步通信技术,核心是解耦

解耦(Decouple)是 [MQTT Essentials – A Lightweight IoT Protocol](resources/MQTT Essentials – A Lightweight IoT Protocol.epub) 内反复多次提到的一个词 。

发布/订阅模式(Publish-subscribe pattern)

与请求/回答这种同步模式不同,发布/定义模式解耦了发布消息的客户(发布者)与订阅消息的客户(订阅者)之间的关系,这意味着发布者和订阅者之间并不需要直接建立联系。打个比方,你打电话给朋友,一直要等到朋友接电话了才能够开始交流,是一个典型的同步请求/回答的场景;而给一个好友邮件列表发电子邮件就不一样,你发好电子邮件该干嘛干嘛,好友们到有空了去查看邮件就是了,是一个典型的异步发布/订阅的场景。

熟悉编程的同学一定非常熟悉这种设计模式了,因为它带来了这些好处:

  • 发布者与订阅者不必了解彼此,只要认识同一个消息代理即可。
  • 发布者和订阅者不需要交互,发布者无需等待订阅者确认而导致锁定。
  • 发布者和订阅者不需要同时在线,可以自由选择时间来消费消息。

主题(Topic)

MQTT是通过主题对消息进行分类的,本质上就是一个UTF-8的字符串,不过可以通过反斜杠表示多个层级关系。主题并不需要创建,直接使用就是了。

主题还可以通过通配符进行过滤。其中,+可以过滤一个层级,而*只能出现在主题最后表示过滤任意级别的层级。举个例子:

  • building-b/floor-5:代表B楼5层的设备。
  • +/floor-5:代表任何一个楼的5层的设备。
  • building-b/*:代表B楼所有的设备。

注意,MQTT允许使用通配符订阅主题,但是并不允许使用通配符广播。

遗言机制(Last will)

遗言机制可以让订阅者知道设备异常离线,最重要的是离线后要做什么操作,这也是遗言的现实意义。

https://segmentfault.com/a/1190000007266638

https://stackoverflow.com/questions/17270863/mqtt-what-is-the-purpose-or-usage-of-last-will-testament/17385293#17385293

I’m surely missing something about how the whole MQTT protocol works, as I can’t grasp the usage pattern of Last Will Testament messages: what’s their purpose?
One example I often see is about informing that a device has gone offline. It doesn’t make very much sense to me, since it’s obvious that if a device isn’t publishing any data it may be offline or there could be some network problems.

So, what are some practical usages of the LWT? What was it invented for?


LWT messages are not really concerned about detecting whether a client has gone offline or not (that task is handled by keepAlive messages). LWT messages are about what happens after the client has gone offline.

The analogy is that of a real last will: If a person dies, she can formulate a testament, in which she declares what actions should be taken after she has passed away. An executor will heed those wishes and execute them on her behalf. The analogy in the MQTT world is that a client can formulate a testament, in which it declares what message should be sent on it’s behalf by the broker, after it has gone offline.

A fictitious example:

I have a sensor, which sends crucial data, but very infrequently. It has formulated a last will statement in the form of [topic: ‘/node/gone-offline’, message: ‘:id’], with :id being a unique id for the sensor. I also have a emergency-subscriber for the topic ‘node/gone-offline’, which will send a SMS to my phone every time a message is published on that channel.

During normal operation, the sensor will keep the connection to the MQTT-broker open by sending periodic keepAlive messages interspersed with the actual sensor readings. If the sensor goes offline, the connection to the broker will time out, due to the lack of keepAlives.

This is where LWT comes in: If no LWT is specified, the broker doesn’t care and just closes the connection. In our case however, the broker will execute the sensor’s last will and publish the LWT-message ‘/node/gone-offline: :id’. The message will then be consumed to my emergency-subscriberand I will be notified of the sensor’s ID via SMS so that I can check up on what’s going on.

In short:

Instead of just closing the connection after a client has gone offline, LWT messages can be leveraged to define a message to be published by the broker on behalf of the client, since the client is offline and cannot publish anymore.

Furthermore, keepAlive messages are only sent and received by the broker and there’s the main difference with the Last Will: anyone can suscribe to this topic and be aware of the client going offline

建立连接

page 69

1
2
3
Client            Server
|--- CONNECT --->|
|<-- CONNACK ----|
坚持原创技术分享,您的支持将鼓励我继续创作!