[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-285) Subscribe options for retained messages
[ https://issues.oasis-open.org/browse/MQTT-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ken Borgendale updated MQTT-285:
--------------------------------
Proposal:
In the Subscription Options byte in SUBSCRIBE, define bit 3 as RetainAsPublished. If this bit is set, when a message is published due to this subscription, the RETAIN flag in the PUBLISH is set RETAIN equal to the value of the RETAIN in the messages as received. (Non normative) A common use of this is for bridging where it is important to know whether the sender intended this to be a retained message.
In the Subscription Options byte in SUBSCRIBE, define bits 4 and 5 with the values
0 = Send retained messages at subscribe
1 = Only send retained messages for a new subscription
2 = Do not send retained messages on subscribe
3 = malformed packet
(Non normative) A common use of this is for bridging where we do not want to send the retained messages across the bridge as we are also sending the original retain bits. This is also useful to control whether to send retained messages in the case of a re-subscribe which is done in the case of connecting to an existing session where we are uncertain of the state of the subscriptions.
was:
3.3.1.3 RETAIN
If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, the Server MUST store the Application Message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name [MQTT-3.3.1-5]. When a new subscription is established with the NoSendRetain flag set to 0, the last retained message, if any, on each matching topic name MUST be sent to the subscriber [MQTT-3.3.1-6]. When a new subscription is established with the NoSendRetain flag set to 1 a retained message MUST NOT be sent. If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic [MQTT-3.3.1-7]. See Section 4.1 for more information on storing state.
When sending a PUBLISH Packet to a Client the Server MUST set the RETAIN flag to 1 if a message is sent as a result of a new subscription being made by a Client with the RetainAsPublished flag set to 0[MQTT-3.3.1-8]. It MUST set the RETAIN flag to 0 when a PUBLISH Packet is sent to a Client because it matches an established subscription regardless of how the flag was set in the message it received if the subscription was created with the RetainAsPublished flag set to 0 [MQTT-3.3.1-9]. For any subscription which was created with the RetainAsPublished flag set to 1, the Server MUST set the RETAIN flag to the same value as the RETAIN flag in the message it received.
Non normative comment
Setting the RetainAsPublished and/or NoSendRetained flags to 1 is useful for cases such as a bridge Client which sends on messages to another Server. The NoSendRetained flag set to 1 can also be used for an application that only wants to receive change notifications.
3.8.3 Payload
The upper 3 bits of the Requested QoS byte are not used in the current version of the protocol. They are reserved for future use. The Server MUST treat a SUBSCRIBE packet as malformed and close the Network Connection if any of Reserved bits in the payload are non-zero, or QoS is not 0,1 or 2 [MQTT-3-8.3-4].
Bit 3 of the Requested QoS byte is defined as the NoSendRetain flag. If the value is 0, matching retained messages, if any, are sent when the subscription is established. If this value is 1, no matching retained messages are sent.
Bit 4 of the Requested QoS byte is defined as the RetainAsPublished flag. If the value is 0, the Server sets the RETAIN flag when a message is published to the Client based on whether the message came from the retained store. If the value is 1, the Server sets the RETAIN flag when a message is published to the Client equal to the RETAIN flag it received. See section 3.3.1.3 for details of the handling of the RETAIN flag.
I agree it makes sense to use two bits to represent whether to send the retained messages at SUBSCRIBE as there are three meaningful options.
I would still prefer to make RetainAsPublished a toggle of whether the RETAIN flag in the forwarded message indicates that the message is from a retained source or to keep the retain bit as published. I see a good use case for both of these, but there is not a good use case for knowing both. This would be another id/value pair which would need to be removed for processing a message in the bridge.
I put out the proposal in simple terms rather than in spec language. Most of the text will go into the Subscription Options section within SUBSCRUBE.
> Subscribe options for retained messages
> ---------------------------------------
>
> Key: MQTT-285
> URL: https://issues.oasis-open.org/browse/MQTT-285
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: New Feature
> Components: core
> Affects Versions: 5
> Reporter: Ken Borgendale
> Assignee: Ken Borgendale
>
> This issue came up when reviewing MQTT-235 (nolocal) as it affects the bridge use case along with others.
> The current setting of the retain flag on PUBLISH and the handling of retained messages on SUBSCRIBE is normally correct when the client really is a subscribing client, it is not correct behavior when the client is going to forward the message on in a bridge or filter use case.
> There are two issues here
> 1. In some case the subscriber does not want to get any messages which are retained at the time of the subscription.
> 2. If the subscriber is going to re-publish the message it needs to know if the messages was published with the retain flag, rather than that it came from a retained source
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]