Does MQTT brokers support persistent subscriptions?

Question

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?

Answer 1

During client connecting to the broker, the CleanSession 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 Section 3.1.2.4 specifies that:

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

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: retained flag in publication messages.

The MQTT 3.1.1 Standard Section 3.3.1.3 specifies that:

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

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

Answer 2

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: http://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages

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