OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Using QoS level of subscriptions to control MQTT-enabled gateway deliveries.


Hello MQTT experts,

We have an application that leans heavily on MQTT 3.1.1 protocol. We have a gateway (in MQTT terms, a broker) that communicates with a RESTful application service that is taking care of storing data and synchronizing it between endpoints. The gateway translates that application service API into MQTT protocol, in order to enable constrained devices to talk to our application via standard MQTT clients. The application is generally state driven, as opposed to be message flow driven, as we find states to be a more convenient development paradigm.

We are discussing a design where for certain topics (for example: topic/a) we enable devices to subscribe to such topics with QoS 0 or 1.
- With QoS 0, we expect real-time interaction, and do not attempt delivery of missed messages while devices were offline. All published messages from gateway to subscribers are QoS=0.
- With QoS 1, we also deliver missed messages to devices after they re-appear online. All published messages from gateway to subscribers are QoS=1.

Furthermore, for certain topics, expect QoS 1 behavior to be different, in a way that devices subscribing to the same topic with different QoS may have a different view on the message lifetime, importance and potentially format. Essentially we are parameterizing message delivery on the same topic through subscriptions with different QoS. Specific example: client A pushes 10 state updates to topic/a to convey it's state, however for application only the last one matters. When a subscribed client B comes online, the MQTT gateway wants to be smart, and squashes pending deliveries, skipping first 9 updates and publishes only latest state.

We thought such behavior of losing some of QoS 1 messages is questionable, even though neither client A nor client B violate the reliable PUBLISH / PUBACK delivery as per protocol specification. Instead, it is the gateway that makes a decision about some of the updates being redundant for this particular topic and discarding them.

Alternative is to design a completely different topic structure, for example the clients subscribe to:
topic/a/behavior_a
topic/a/behavior_b

The downside of this approach is that we drive our topic structure through behavior instead of data model and application semantics, as we'd eventually expect the same data belong to topic/a. We perceive that such "asymmetric" protocol is less consistent.

We would like to consult about experts' view on a legitimate MQTT way to design our topic structure, in order to accommodate the reliable/unreliable delivery behavior of our application service. What is the degree of freedom that the broker has for evicting or transforming pending messages with reliable delivery?

Best regards,
Miao


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]