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] Commented: (MQTT-14) Tighten up language in Quality of Service levels and flows

    [ http://tools.oasis-open.org/issues/browse/MQTT-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33992#action_33992 ] 

Julien Niset commented on MQTT-14:

A related comment that might need clarification is the action of the server when a PUBLISH message arrives with the DUP flag set to 1 (with QoS = 1). 

The spec says in line 1834 : "When it receives a duplicate message from the client, the server republishes the message to the subscribers, and sends another PUBACK message."

However, as it is possible to subscribe to a topic with a lower QoS than the publication, there could be subscriptions with QoS = 0 that are no supposed to receive duplicate messages. If they do, it would contradict the "At most once" definition of QoS = 0.

From the subscriber with QoS = 0 point of view, one can consider this duplicate message as a new message (in particular as there is no messageID), but it is nonetheless a duplicate of the content of the message. 

> Tighten up language in Quality of Service levels and flows 
> -----------------------------------------------------------
>                 Key: MQTT-14
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-14
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Rahul Gupta
>            Assignee: Rahul Gupta
>            Priority: Minor
> It was today reported in MQTT google group. https://mail.google.com/mail/?shva=1#inbox/13ec114a841305d9
> ----------
> The spec explains (http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#qos-flows) that when a message is published to the server with qos 1 the server should persist it, deliver it to all subscribers, delete the message and then puback.
> Does this require the server to wait for puback from all subscribers which subscribed with qos1 before sending puback to the original publisher? What about disconnected qos1 subscribers, are they exempted?
> My concern is that the pub/puback takes a whole lot longer in this case, without any extra reliability benefits. Couldn't the server send puback as soon as the message is persisted? 
> ----------
> Language in specification needs to be tightened up

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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