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

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

Andrew Banks created MQTT-234:
---------------------------------

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


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)