[OASIS Issue Tracker] Commented: (MQTT-14) Tighten up language in Quality of Service levels and flows

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

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

Raphael Cohen commented on MQTT-14:
-----------------------------------

Well, this is very important. It is not just performance that's affected, but the asynchronous nature and advantages of MQTT itself. It affects separation of concerns.

A server, once it believes it has made a durable record of a received QoS 1 (or 2, for that matter), message, should acknowledge that fact. If it can't then deliver it immediately to some or all subscribers, then that's its responsibility. The broker (server) is exactly that - a middle man on behalf of sending and receiving clients - two different concerns, with two separate deliveries.

Otherwise, the protocol becomes nothing more than a glorified synchronous TCP concentrator or 'real time' chat. What's the point of then persisting? The complexities of how to deal with 'not connected' are terrible in this case. And it would potentially force broker designs to iterate over all known subscribers for all persistence operations. Horrid - especially if the map of subscriptions is volatile due to high rates of churn...

The broker should always puback as soon as a message has been received and successfully made durable.


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