[OASIS Issue Tracker] (MQTT-217) Deliver implementation guidance around overlapping subscriptions

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61862#comment-61862 ] 

Ken Borgendale commented on MQTT-217:
-------------------------------------

The problem here is that there are two implementations within the servers which lead to two separate appearances at the client level for overlapping subscriptions: This also affects what messages are received in cases where the subscriptions are modified.

1. There is a queue for each client. When a message arrives it is routed based on the set of subscriptions for a client and routed to that client using the highest QoS amoung any overlapping subscriptions. It might be necessary to re-evaluate the subscriptions before sending the message to the client. This results in one copy of a message sent to the client.

2. There is a queue for each subscription. When a message arrives it is routed based on the set of subscriptions (consumers) and routed to the queue of the subscription. If a client has overlapping subscriptions, it will get a copy of the message for each subscription. Changing a subscription only modifies the handling of that subscription and not any other subscription the client has.

There are servers which are implemented in each of these ways, and for good and valid historical reasons. 

Servers which deal with multiple protocols tend to use strategy #2 as that is the design of most other protocols. Most other protocols also identify the subscription within the packet sent to the client and specifically require that a message be routed to each of the subscriptions. This also allows multiple queue implementations so that QoS=0 only queues can have a very simple implementation.

The initial MQTT only servers implemented strategy #1 and did not do much about the case of a changed subscription.

When this was discussed in the MQTT 3.1.1 TC it was pointed out that the MQTT 3.1 spec was totally silent about what happened in the case of overlapping subscriptions, and what happened when the subscriptions changed after messages were already queued. It did not even talk about overlapping subscriptions with multiple QoS although the authors of the MQTT 3.1 spec held this to be implied.  We ended up by agreeing that the charter prohibited us from making an incompatible change to how SUBSCRIBE worked which would break a number of existing implementations. We therefore worded the spec with the highest amount of specification that this disagreement would allow. 

Shared subscriptions brings up another case of overlapping subscription issues. Most of those who have implemented shared subscriptions use a queue per subscription, and this is just a case of a queue with multiple consumers. The definition of shared subscriptions is a bit messier when using a queue per client and tends to lead to a mixture of the two strategies.

We can talk about this if we like, but changing this will require a major incompatible break in some of our existing products.

> Deliver implementation guidance around overlapping subscriptions
> ----------------------------------------------------------------
>
>                 Key: MQTT-217
>                 URL: https://issues.oasis-open.org/browse/MQTT-217
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 3.1.1
>            Reporter: Richard Coppen
>            Priority: Minor
>
> Following on from David Kemper's mqtt-comment on CSPRD02 the TC agreed to open this Jira to deliver implementation guidance around overlapping subscriptions.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)