Re: [mosquitto-dev] libmosquitto outgoing queue request for comment

[Roger Light <roger@xxxxxxxxxx>]

Hi Greg,

I think Abilio's suggestion has merit, and your email helps show why.
We already discussed some intermediate approaches on private email and
initially disagreed over what form they should take - allowing a
configurable limit is the most obvious choice, but what set of QoS 0,
1, 2 should be queued? If we hit the queue limit do we drop the head
or the tail of the queue, as you also allude to. We didn't consider
the idea of grouping queue limits per topic as well though, for
example.

My feeling is that the queueing behaviour is going to be specific to
an application - giving the option of setting a callback to handle
this allows every application to handle this behaviour as they wish,
without unnecessary complication in the library. On the other hand if
we start off with a few options on how to control queueing I can
anticipate receiving requests for adding just-one-more option to cover
all of the different cases.

In case it isn't clear, the library already queues QoS 1 and 2
messages when the client is offline. It doesn't queue QoS 0 messages.

Disk persistence for the library is something that ought to be
addressed, but is a separate topic.

Regards,

Roger

On Fri, 2 Apr 2021 at 13:31, Greg Troxel <gdt@xxxxxxxxxx> wrote:
>
>
> My quick reaction is that this is jumping to a very complicated approach
> and skipping over intermediate ones that are likely to be sufficient for
> most cases.
>
> I'm really unclear on when people decide to use qos 0/1/2 and why,
> because there are dreadfully few protocol specs published (at least that
> I have seen) that define the actual protocol used for communication over
> MQTT.
>
> Overall, I would lean to having queuing be optional, with configurable
>
>   limit on # of queued messages (default 128?)
>
>   configurable if a publish on a topic will replace the previous
>   stored-and-not-yet-sent message on that same topic
>
>
> Here, the big question is if there's a desire for every message to be
> delivered, perhaps because it has json with a time and a value, or if
> only the latest is useful, because it's just a value.   That then leads
> to questions about choice of qos and persisting mesages to stable
> storage so that they can survive not only broker disconnect but also
> local reboot or power loss, and by the time you are done then perhaps
> you should instead construct a reliable transfer protocol that uses MQTT
> like UDP.
>
> So to evaluate your proposal I'd like pointers to protocol specs of
> "send this data via MQTT".  (It is both a plus and a minus of MQTT that
> you can sort of get away with not defining that.)
>
>
>
>
>
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mosquitto-dev