Suggested clarification about usage of "loop" for publishing

[igorbga]

Hi, thanks for such a handy tool.

We are using the library to publish some MQTT messages. Some of them are QOS 0, some are QOS 2.

We had no issue with QOS 0 simply by following the example in the main README. But for QOS 2 we struggled to make it work until we noticed that we needed to execute "loop" in order for the whole messages of the protocol are processed, not just the direct publication.

So our code ended being something like this:

            $this->mqttClient->publish($mqttInfo->getTopic(), $message, $qualityOfService);
            if (MqttClient::QOS_EXACTLY_ONCE === $qualityOfService) {
                $this->mqttClient->loop(true, true, $this->maxBrokerWaitTimeInSeconds);
            }

In our tests we saw that for QOS 1 we didn't need the "loop" call, and that makes sense as the broker will just receive the message and sent it to subscribers even if we don't process the "PUBACK" message that it is sending us back.

But I suspect that not doing so in fact avoids MqttClient from ensuring that the message was really delivered to the Broker "at least once" and in fact a QOS 1 message will just behave as QOS 0, just a fire and forget. Am I correct on this ?

In the other hand I guess that as the second parameter of our "loop" call ensures leaving the method as soon as there are no messages pending in the conversation, wouldn't it be advisable to just always call loop even for QOS 0 messages ? That's something that we can test easily so we will just check by ourselves.

The point is that I didn't find any clarification about those points in the main README.md which, AFAIK, is the only documentation for the library.

I wouldn't mind doing the modification of the README myself in a PR once those concerns are clarified but I guess just clarifying it directly in the README will be much practical.

Once more, thanks for such a handy tool.

[Namoshek]

In our tests we saw that for QOS 1 we didn't need the "loop" call, and that makes sense as the broker will just receive the message and sent it to subscribers even if we don't process the "PUBACK" message that it is sending us back.

That is a very dangerous assumption. I've noticed brokers dropping entire message queues if the socket is closed immediately after sending a message (and before the message was processed by the broker). You should definitely await the acknowledgement, becuase there will be a retransmission by the loop() method if no acknowledgement is received in time. Of course that's only true if your loop timeout is not lower than the resend timeout.

But I suspect that not doing so in fact avoids MqttClient from ensuring that the message was really delivered to the Broker "at least once" and in fact a QOS 1 message will just behave as QOS 0, just a fire and forget. Am I correct on this ?

Yes, but it can have an even lower delivery guarantee than QoS 0 if the broker drops the message in case it is unable to send an acknowledgement (see above). However, this is such a specific detail that relates to different broker implementations that there is not really a general answer.

In the other hand I guess that as the second parameter of our "loop" call ensures leaving the method as soon as there are no messages pending in the conversation, wouldn't it be advisable to just always call loop even for QOS 0 messages ? That's something that we can test easily so we will just check by ourselves.

It shouldn't be necessary and since you do not have the ability to leave the loop until all acknowlegements have been received (since there is none), you'll waste time waiting for the timeout. There might, however, be edge cases where sending QoS 0 messages and disconnecting immediately after causes the messages to get lost in transmission (same as above, but also other scenarios). But that's basically what "QoS 0 as fire and forget" describes - no guarantees.

I wouldn't mind doing the modification of the README myself in a PR once those concerns are clarified but I guess just clarifying it directly in the README will be much practical.

That would be highly appreciated. You are right that not all details are documented yet. Partially because "it was clear to me" and isn't really specific to this library, but that does of course not mean it is clear to other users of the library. So please feel free to suggest an addition as you see fit!

[igorbga]

It shouldn't be necessary and since you do not have the ability to leave the loop until all acknowlegements have been received (since there is none), you'll waste time waiting for the timeout.

A ok, I thought that as QOS 0 does not expect any acknowledgement the loop would just leave inmediately.

I'll prepare the PR thanks.