[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (MQTT-74) What should happen to messages pending delivery once the client sends unsubscribe?
[ http://tools.oasis-open.org/issues/browse/MQTT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Coppen updated MQTT-74:
-------------------------------
Proposal:
Add new sub-section in Section 4 "Message receipt"
Under normal circumstances clients receive messages in response to subscriptions they have created. A client could also receive messages that do not match any of its explicit subscriptions. This can happen if the server automatically assigned a subscription to the client or while an UNSUBSCRIBE operation is in progress. The client MUST acknowledge any Publish Packet it receives according to the applicable QoS rules regardless of whether it elects to process the application message.
In WD13 line 1097 Unsubscribe response add:
The server MUST stop adding any new messages for delivery to the client.
The server MUST send an UNSUBACK packet.
The server MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the client.
The server MAY continue to deliver any existing messages buffered for delivery to the client.
In section 3.1.1 (Line 1108 WD13) - description of UNSUBACK
remove the words 'and processing of' (as per input input spec)
was:
In WD13 line 1097 Unsubscribe response add:
The MUST stop adding any new messages for delivery to the client then send an UNSUBACK packet.
The server MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the client.
The server MAY continue to deliver any existing messages buffered for delivery to the client, however clients do not need to present these messages to the application layer.
> What should happen to messages pending delivery once the client sends unsubscribe?
> ----------------------------------------------------------------------------------
>
> Key: MQTT-74
> URL: http://tools.oasis-open.org/issues/browse/MQTT-74
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.1.1
> Reporter: Richard Coppen
> Fix For: 3.1.1
>
>
> A client might be too busy to process any more work, so sends UNSUBSCRIBE to turn the flow off.
> Alternatively, the client may be unaware that a backlog of messages exists and sends UNSUBSCRIBE.
> There are at lesat three possible options:
> 1. The server delays sending the UNSUBACK until the backlog is cleared
> 2. Send the UNSUBACK and then send the messages
> 3. Send the UNSUBACK and then purge the messages
> The client's last defense should it not want the messages is to disconnect and reconnect with cleanSession set to (1)
--
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]