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] Updated: (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:all-tabpanel ]

Rahul Gupta updated MQTT-14:
----------------------------

    Proposal: 
Proposal for QoS1
-------------------------

The receiver is not required to complete delivery of the Application Message before sending the PUBACK. In the case of the Server it MUST make sure that it can honour the QoS requirements of the onward delivery. 

Proposal for QoS2
--------------------------

The receiver is not required to complete delivery of the Application Message before sending the PUBREC or PUBCOMP. In the case of the Server it MUST make sure that it can honour the QoS requirements of the onward delivery. 

  was:
Few suggestions made -
---------------------------------
The wording in the spec needs to be clarified here as you're not the first to ask this.

When the server receives a qos1 message, it must:
 1. persist it
 2. identify the subscribers and begin delivery
 3. return puback

At the point delivery is completed to all of the subscribes the message can then be deleted.

What 'begin delivery' means will depend on the implementation. That may mean the PUBLISH packet is written to the TCP socket of each subscriber or it might simply mean the message is queued up for delivery internally.

-----------------

This is a edit issue, and editors will work to see if the verbose in this section could be tightened up. 


> 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]