blocks|key|98841|text|很快我就自己找到了答案。持久会话是答案。我一直在寻找持久订阅，但最初并不成功……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|98842|下面是关于我的案例的最后一篇很棒的文章：http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages|offset|length|98843|所以，是的，持久订阅被称为持久会话，是的，这是可能的。|98844|entityMap|0|LINK|mutability|MUTABLE|url|http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages^0|0|K|2D|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Very quickly I found an answer by myself. Persistent Session is the anwer. I was looking for persistent subscription and wasn't initially successful...

Here is finally great article about my case:
<a href="http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages" rel="nofollow noreferrer">http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages</a>

So yes, persistent subscriptions is called persistent sessions and yes it is possible.

blocks|key|98857|text|在客户端连接到代理期间，CleanSession标志使代理能够对QoS+1或QoS+2的丢失消息进行排队(存储QoS+0消息取决于实现)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|98858|MQTT3.1.1标准Section+3.1.2.4规定：|98859|98860|如果CleanSession设置为0，则服务器必须根据当前会话的状态(由客户端标识符标识)恢复与客户端的通信。如果没有与客户端标识符相关联的会话，则服务器必须创建一个新会话。客户端和服务器断开连接后，客户端和服务器必须存储会话MQTT-3.1.2-4在将CleanSession设置为0的会话断开连接后，服务器必须进一步存储与客户端在断开连接时具有的任何订阅相匹配的QoS+1和QoS+2消息，作为会话状态MQTT-3.1.2-5的一部分。它还可以存储满足相同条件的QoS+0消息|blockquote|98861|98862|98863|持久会话的问题是，它可能会将大量消息排入队列，因此在重新连接时，客户端会被丢失的消息轰炸。如果您需要了解完整的读数序列，这可能是可取的；如果客户端运行在低功耗、电池供电的嵌入式设备上，则非常不可取。|98864|为了解决这个问题，MQTT提供了另一个特性:发布消息中的retained标志。|98865|MQTT+3.1.1标准第3.3.1.3节规定：|98866|98867|如果保留标志设置为1，则在由客户端发送到服务器的PUBLISH数据包中，服务器必须存储应用程序消息及其QoS，以便可以将其传递给其订阅与其主题名称MQTT-3.3.1-5匹配的将来的订阅者。当建立新的订阅时，必须将每个匹配主题名称上最后保留的消息发送到订阅者MQTT-3.3.1-6。如果服务器接收到保留标志设置为1的QoS+0消息，它必须丢弃先前为该主题保留的任何消息。它应该将新的QoS+0消息存储为该主题的新保留消息，但可以在任何时候选择丢弃它-如果发生这种情况，将没有该主题的保留消息|98868|98869|98870|这确保了在重新连接时，客户端仅接收到有关给定主题的最新消息。|98871|entityMap^0|C|C|0|B|F|0|0|0|0|0|0|S|8|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|18|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|19|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1C|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1D|8|@$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1G|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1H|8|@]|D|@]|E|$]]|$1|U|3|V|5|K|7|1I|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1J|8|@]|D|@]|E|$]]|$1|X|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1L|8|@]|D|@]|E|$]]|$1|10|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]]|11|$]]

During client connecting to the broker, the <code>CleanSession</code> flag enables the broker to queue up missed messages of QoS 1 or QoS 2 (storing QoS 0 messages is implementation-dependent).

The MQTT 3.1.1 Standard <code>Section 3.1.2.4</code> specifies that:

<blockquote>
 If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4]. After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state [MQTT-3.1.2-5]. It MAY also store QoS 0 messages that meet the same criteria
</blockquote>

The problem with a persistent session is that it may queue up large numbers of messages, so upon re-connection the client is bombarded with missed messages. This may be desirable if you require to know the full sequence of readings, or highly undesirable if the client is running on a low-power, battery-fed embedded device.

To address this, MQTT provides another feature: <code>retained</code> flag in publication messages.

The MQTT 3.1.1 Standard Section 3.3.1.3 specifies that:

<blockquote>
 If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, the Server MUST store the Application Message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name [MQTT-3.3.1-5]. When a new subscription is established, the last retained message, if any, on each matching topic name MUST be sent to the subscriber [MQTT-3.3.1-6]. If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic
</blockquote>

This ensures that upon re-connection the client receives only the latest message on a given topic.

I work on my first IOT POC, the device will usually generate sensor data once per hour/day. I planned to have architecture like this:
- 1 shared topic for sensor data input (device to backend direction)
- Each device will subscribe initially to its own specific topic aka /device/{id}/notification

Now, after sensor data submitted to shared topic, I plan to put device into deep sleep (device can only be waked-up by wifi packet or timer), in this state TCP connection to broker is lost.

Question: After device is back waked-up and TCP connection to MQTT broker is re-established, will the device receive all messages which were generated by server during out-of-service period, or these messages won't be available?

Does MQTT brokers support persistent subscriptions?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我在我的第一个IOT POC上工作，该设备通常每小时/天生成一次传感器数据。我计划这样的架构：-1传感器数据输入的共享主题(设备到后端方向)-每个设备最初将订阅自己的特定主题，也就是/设备/{id}/notification现在，在传感器数据提交到共享主题后，我计划让设备进入深度睡眠(设备只能通过wifi数据包或定时器...

问MQTT代理是否支持持久订阅？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问MQTT代理是否支持持久订阅？EN