Re: [mqtt-comment] Shared Subscriptions

["Ken Borgendale" <kwb@us.ibm.com>]

We are currently outside of a public comment period.

The MQTTv5.0 specification for shared subscriptions specifically does not define how the server decides which client to send a message to, only that it must send it to one of them. This text extends this as to what this means at the time of a client connection failure, and describes the differences in the this logic between QoS 1 and QoS 2.


Ken Borgendale -- kwb@us.ibm.com

<mqtt-comment@lists.oasis-open.org> wrote on 12/05/2017 10:18:56 AM:

> From: David Katz <David.Katz@bmw-carit.de>
> To: "mqtt-comment@lists.oasis-open.org" <mqtt-comment@lists.oasis-open.org>
> Date: 12/05/2017 10:19 AM
> Subject: [mqtt-comment] Shared Subscriptions
> Sent by: <mqtt-comment@lists.oasis-open.org>
>
> Hi all,
>  
> 4.8.2 Shared Subscriptions
> Scenario: backend servers are to respond to messages published to a given topic. In
> order to scale the backend applications, servers are added dynamically to the backend
> application cluster and subscribe to the MQTT server using Shared Subscriptions. To
> ensure that no messages are lost between broker and application cluster, QoS 1 and
> persistent sessions are being used.
> Question:  The specification at lines 3146-3151 "...  Server MAY wait for the Client to
> reconnect and retransmit the message to that Client.... the Server SHOULD send the
> Application Message to another Client.... It MAY attempt to send the message to another
> Client as soon as it loses its connection..." suggests that the Server is free to choose
> how to handle queueing and failover. If the server does not resend the message to
> another client, the message will however likely be lost. Shouldn't the correct behaviour
> be required by the spec?
>  
> Cheers,
> David Katz
>  
> BMW Car IT GmbH
> David Katz
> Moosacher Straße 86
> 80809 München
>