[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 -- email@example.com
<firstname.lastname@example.org> wrote on 12/05/2017 10:18:56 AM:
> From: David Katz <David.Katz@bmw-carit.de>
> To: "email@example.com" <firstname.lastname@example.org>
> Date: 12/05/2017 10:19 AM
> Subject: [mqtt-comment] Shared Subscriptions
> Sent by: <email@example.com>
> 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?
> David Katz
> BMW Car IT GmbH
> David Katz
> Moosacher Straße 86
> 80809 München