[OASIS Issue Tracker] (MQTT-234) Shared Subscriptions

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

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

Jonathan Levell commented on MQTT-234:
--------------------------------------

Peter: I'm interested that you are happy to allow mixed cleansession=false/true clients (in 3.1.1 speak) but insist on same maxqos. 

At least in the implementation I'm most familiar with the mixture of cleansession=false and true is more problematic (but implementable) because buffering messages for durable sessions requires persistent storage and non-durable sessions only in-memory storage, so as clients connect and disconnect the requirement for "persistent storage" varies.

As each connected client could have their own view of the maxqos, I don't foresee an issue in mixing the maxQos above and beyond the "persistent"-ness discussed above.

In terms of redelivery to other clients, Peter's notes from the face-to-face meeting says: "QoS 1. I think it makes sense to allow a server to redeliver a unacked QoS 1 message to another member of the shared subscription if it detects that it has lost connection to the original intended recipient."    Is the client that disconnects is cleansession=false, we currently don't do the kind of per message cleanup that would allow redelivery of that message to a different client - the first client would be given the message when it reconnected (this could be changed). Only when serverside-state for a client is removed (e.g. replaced by a cleansession=true client) would qos=1 messages reserved for that client be redelivered to other clients which different clientids.

I support the idea that qos=2 messages would not be redelivered to other clients once delivery has commenced to a client.

> Shared Subscriptions
> --------------------
>
>                 Key: MQTT-234
>                 URL: https://issues.oasis-open.org/browse/MQTT-234
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 5
>            Reporter: Andrew Banks
>            Priority: Critical
>
> Shared Subscriptions
> --------------------
> Shared subscriptions allow a set of clients to share the consumption of messages
> produced in response to a subscription. The set of subscribers is created by the use
> of a common share name. Shared subscriptions provide a facility similar to point to 
> point messaging in that the processing of messages is not limited to the availability 
> or capacity of a single consumer, the share name is analogous to the queue name in 
> that it names the list of messages to be processed.
> I suggest that a shared subscription be defined by the topic filter syntax:
>   $share:shareName:topicFilter
> - This specialised topic filter takes the place of the normal topic filter in the 
>   subscribe packet. 
> - The "$share:" prefix uses a reserved $ name and will therefore not cause a conflict
>   with other topic filters.
> - shareName is a string which labels the shared subscription and must not contain any 
>   ":" characters.
> - TopicFilter follows the existing topic filter rules.
> - Subscribing clients will be a member of the share only if both the shareName and
>   topicFilter are identical. So, a different shareName with the same topicFiler 
>   will create a different share. Similarly a shareName followed by a different topic
>   filter will create separate share.
> - Servers may decline to support shared subscriptions by not accepting subscribe
>   packets containing topic filters starting with the "$share:" prefix. However, if 
>   they do accept the "$share:" prefix they must follow this definition.
> - The subscribing clients may make both non durable and durable subscriptions by 
>   setting clean session true or false. The shared subscription ceases to exist if    
>   the number of clients subscribed to it reaches zero. If the shared subscription
>   ceases to exist the messages queued for processing are deleted by the server as 
>   with an non shared subscription.
> - A good server implementation will avoid allocating messages to subscribers with 
>   durable subscriptions while the client is disconnected. Instead the messages will be 
>   allocated when a suitable client connects. 
> - A Qos=1 message should be reallocated to another client sharing the same subscription
>   if the network connection to the client is lost before the PUBACK is received.
>   Qos=0 and Qos=2 messages must not be reallocated. 



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