[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=62315#comment-62315 ] 

Ken Borgendale commented on MQTT-234:
-------------------------------------

In the Bellevue meeting we discussed several alternative representations of shared subs, and a number of the issues around the semantics.  We decided that as this is a topic filter, the charter out-of-scope statement about not defining parts of the topic space does not apply.  While we got some consensus on the semantics (such as overlapping subscriptions) we were left with multiple possible representations of the topic filter.
    $share/group/topicfilter
    group/topicfilter with a bit in the QoS flags of SUBSCRIBE (and added to UNSUBSCRIBE)
    $$:group:topicfilter  with the separator character to be defined

I would like to propose the following:
    $$share/group/topicfilter
We would then define topic filters (or topic names) starting with $$ to be reserved for definition by MQTT in either normative or non-normative text (such as best practices).  The leaves any other topic filter or topic name starting with $ for assignment by the providers. 

Using the slash as the separator means that the group name cannot contain a slash, but uses a separator which already has a defined meaning within a topic filter (as a separator) and thus does not reserve any additional characters. 

This is very similar to Andy Banks original proposal.  We do need to fill in some of the semantic details

For semantics, we should
1. Prohibit specifying nolocal on a shared subscription
2. Prohibit subscription overlay between shared and non-shared subscriptions in a session
3. Only send retained messages to the first subscriber of a shared subscription.  Any subscribers which join a shared subscription will not get retained message at the time of the subscribe.

While there are cases where nolocal or subscription overlap could be useful in some contrived cases, they would more likely just be hiding errors.

> 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: 3.1.1
>            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)