Re: [mqtt-comment] Shared Subscriptions

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  --    

<> wrote on 12/05/2017 10:18:56 AM:

> From: David Katz <>
> To: "" <>
> Date: 12/05/2017 10:19 AM
> Subject: [mqtt-comment] Shared Subscriptions
> Sent by: <>
> 
> 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
>