[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:
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.
was:
In WD13 line 1097 Unsubscribe response add:
Stop adding any new messages for delivery to the client then send an UNSUBACK packet.
The server MUST complete the delivery of any int QoS 1 or QoS 2 messages which it has started to send to the client.
The server MAY continue to process any existing messages queued for delivery to the client.
> 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]