OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-217) Deliver implementation guidance around overlapping subscriptions


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

Nicholas O'Leary commented on MQTT-217:
---------------------------------------

This was discussed at various points during the April F2F - although no conclusion was reach.

Ken has, in his comment above, also identified the face Shared Subs adds another dimension of legitimate reasons for when multiple copies of a message for overlapping subs would be desirable.

It seems increasingly unlikely that we will settle on a single behaviour here - too many things break whichever way we end up leaning. So I'm more interested in seeing what we can do to help applications cope with the multiple messages they receive. I do not accept that saying 'don't cause your subscriptions to overlap' is good enough. - especially with the intro of shared subs.

When I think about how an application can meaningfully de-duplicate the messages, without having to resort of application level measures, I keep coming back to being able to identify exactly which sub caused a particular message to arrive. This was raised as JIRA 253 - which was deferred from 3.1.1 as it was beyond the scope of the charter - but it has not been looked at further since. (https://issues.oasis-open.org/browse/MQTT-253). I think we need to look at this more closely. I'm not necessarily advocating exactly what the proposal in 253 describes, but the basic principle is there - return an ID in the suback for each topicfilter subscribed to, and then attach the appropriate ID to the publishes that are sent to the client. Our addition of an optional field/metadata framework gives us the place to put such information.

> Deliver implementation guidance around overlapping subscriptions
> ----------------------------------------------------------------
>
>                 Key: MQTT-217
>                 URL: https://issues.oasis-open.org/browse/MQTT-217
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 3.1.1
>            Reporter: Richard Coppen
>            Priority: Minor
>
> Following on from David Kemper's mqtt-comment on CSPRD02 the TC agreed to open this Jira to deliver implementation guidance around overlapping subscriptions.



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]