Mqtt.js: Connection is broken query

[jonhardman]

Hi,

I am looking at understanding the capability of mqtt.js a little more when a clients connection to a broker is broken.

I've read through the documentation and I am still a little unsure what happens to outgoing messages when the client fails to connect, are messages automatically queued as default or do I need to set something explicitly to enable this queuing. I can see that QoS: 0 is default, and therefore should queue QoS zero messages?

Is there a limit to what can be queued, is it stored in memory or written to disk?

Is there a way to log what has been written to the queue and when it is removed from the queue when the connection is re-established?

Thank you in advance!

Jon

[4rzael]

About QoSes

Here is how QoS works:

• QoS 0 : received at most once : The packet is sent, and that's it. There is no validation about whether it has been received.
• QoS 1 : received at least once : The packet is sent and stored as long as the client has not received a confirmation from the server. MQTT ensures that it _will_ be received, but there can be duplicates.
• QoS 2 : received exactly once : Same as QoS 1 but there is no duplicates.

About data consumption, obviously, QoS 2 > QoS 1 > QoS 0, if that's a concern to you.

About message storing

In MQTT.js, there is two "storing" process : Message queuing and Stores.

Message Queue

IIRC, this is not part of the MQTT spec, but, with MQTT.js, whenever you send a message, even with QoS 0 (when the option property queueQoSZero is not set to false in the Client constructor), it will be queued, waiting for the client to be connected to be sent.

Stores

Some messages need to be stored in order to ensure QoS specifications. In order to do so, they use a 'Store'

As explained before, messages are only stored for QoS 1 and 2

About Stores

A default class Store (lib/store.js) is used if no Store is specified. It works in memory.

However, you can set a different one when calling the Client constructor by adding a outgoingStore property to the option object. This way, you can implement one that uses disk storage.

(If you do so, you should also change the incomingStore)

You should take a look at the Store documentation

About logging

As you can see in the Client.publish documentation, you can give a callback to the publish method, that will be fired when the message is correctly sent (So it will wait for the server confirmation if using QoS 1 or 2).

I don't see any other way to do so, but if you have specific use cases that don't fit this way, explains them.

I hope it helped you. If you still have questions, feel free to ask. If you don't, let us know so we can close this issue.

Thanks,

4rzael

[mcollina]

Great job @4rzael!

Why don't you add a little FAQ doc to the README with the above description about QoS and storage?

[jonhardman]

Thanks @4rzael this is a great summary and the info I was looking for. I could imagine others appreciating this info so a FAQ would be handy :-)