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)
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)
Description
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)
In 2, the client received messages for a topic which it potentially thinks it has unsubscribed from. I can see that creating a lot of interesting head scratching when debugging a problem.
In 1, this stops a broker being able to immediately return a packet, and means it has to maintain a bit state, I suspect. It's also rather hard to define 'backlog', especially if one's internal design is a non blocking queue of some sort - no action can be taken based on an observation (a sort of Heisenberg-like thing, eg checking isEmpty then doing something. Think of the problem of incrementing a volatile int field in java).
3 would be my preference. It does not necessarily require a purge... It does fit nicely with the client's expectations.
However, we could leave the door open to 1 and 3. They're indistinguishable to the client.
Raphael Cohen (Inactive)
added a comment - Hmmm...
In 2, the client received messages for a topic which it potentially thinks it has unsubscribed from. I can see that creating a lot of interesting head scratching when debugging a problem.
In 1, this stops a broker being able to immediately return a packet, and means it has to maintain a bit state, I suspect. It's also rather hard to define 'backlog', especially if one's internal design is a non blocking queue of some sort - no action can be taken based on an observation (a sort of Heisenberg-like thing, eg checking isEmpty then doing something. Think of the problem of incrementing a volatile int field in java).
3 would be my preference. It does not necessarily require a purge... It does fit nicely with the client's expectations.
However, we could leave the door open to 1 and 3. They're indistinguishable to the client.
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.
Add that a client that receives a message for a topic to which it is not currently subscribed MAY choose to discard the message
=> there's an impact here on QoS 1/2 handling for naive clients, but so be it
Add some non-normative text explaining the rationale of the final sentence, to make it clear that this might be for a few messages / only for the immediate future (ie not forever).
Raphael Cohen (Inactive)
added a comment - OK, so to clarify I would:-
change 'process' to deliver
Add that a client that receives a message for a topic to which it is not currently subscribed MAY choose to discard the message
=> there's an impact here on QoS 1/2 handling for naive clients, but so be it
Add some non-normative text explaining the rationale of the final sentence, to make it clear that this might be for a few messages / only for the immediate future (ie not forever).
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.
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.
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.
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)
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.
Section 3.10.3 is updated
The Server sends an UNSUBACK Packet to the Client in response to an UNSUBSCRIBE Packet. The server:
• MUST stop adding any new messages for delivery to the client.
• MUST send an UNSUBACK packet. The UNSUBACK Packet MUST have the same Packet Identifier as the UNSUBSCRIBE Packet.
• MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the client.
• MAY continue to deliver any existing messages buffered for delivery to the client.
3.11 UNSUBACK - Unsubscribe acknowledgement is updated
The UNSUBACK Packet is sent by the Server to the Client to confirm receipt of an UNSUBSCRIBE Packet.
Rahul Gupta (Inactive)
added a comment - In WD-14
4.5 Message receipt is added
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.
Section 3.10.3 is updated
The Server sends an UNSUBACK Packet to the Client in response to an UNSUBSCRIBE Packet. The server:
• MUST stop adding any new messages for delivery to the client.
• MUST send an UNSUBACK packet. The UNSUBACK Packet MUST have the same Packet Identifier as the UNSUBSCRIBE Packet.
• MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the client.
• MAY continue to deliver any existing messages buffered for delivery to the client.
3.11 UNSUBACK - Unsubscribe acknowledgement is updated
The UNSUBACK Packet is sent by the Server to the Client to confirm receipt of an UNSUBSCRIBE Packet.
Major
Hmmm...
In 2, the client received messages for a topic which it potentially thinks it has unsubscribed from. I can see that creating a lot of interesting head scratching when debugging a problem.
In 1, this stops a broker being able to immediately return a packet, and means it has to maintain a bit state, I suspect. It's also rather hard to define 'backlog', especially if one's internal design is a non blocking queue of some sort - no action can be taken based on an observation (a sort of Heisenberg-like thing, eg checking isEmpty then doing something. Think of the problem of incrementing a volatile int field in java).
3 would be my preference. It does not necessarily require a purge... It does fit nicely with the client's expectations.
However, we could leave the door open to 1 and 3. They're indistinguishable to the client.