Major >>>
mqtt-comment from Paolo Patierno
“If a Client does not receive a PINGRESP Packet within a reasonable amount of
time after it has sent a PINGREQ, it SHOULD close the Network Connection to the
Server.”
How much is “reasonable” amount of time ?
In the actual spec 3.1 the clients has a timeout equals to keep alive period to wait PINGRESP message.
<<<
>>>
mqtt-comment from David Kemper
According to the current draft, starting at line 824:
“When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published message might match multiple filters. In this case the Server MUST deliver the message to the Client respecting the maximum QoS of all the matching subscriptions [MQTT-3.3.5-1]. In addition, the Server MAY deliver further copies of the message, one for each additional matching subscription and respecting the subscription’s QoS in each case.”
Granted, the scope of the OASIS TC prohibits more extensive protocol changes to address the ambiguity of [MQTT-3.3.5-1], the explicit requirement of [MQTT-3.3.5-1] is at least well-defined.
However, the following sentence “In addition, the Server MAY deliver further
copies of the message, one for each additional matching subscription and
respecting the subscription’s QoS in each case.” leads to further ambiguity.
Consider the case of four overlapping subscriptions, and a publish that
satisfies all. Let’s say one subscription is at QoS 0, one is at QoS 1, and the
third and fourth are at QoS 2. As I understand it:
- The MUST clause covers delivery at QoS 2.
- The Server MAY additionally deliver the message at QoS 0, QoS 1, and again at QoS 2
.
- For each additional delivery with QoS > 0, the packet has a unique Packet
Identifier. (It’s a unique Server->Client packet that must be ack’ed.)
- For each additional delivery with QoS > 0, the packet does NOT have the DUP flag set, unless this is during redelivery after reconnect. (DUP is not about the application message, but about the packet sent.)
I have read through the comments to
https://tools.oasis-open.org/issues/browse/MQTT-58 (How many messages are received for overlapping subscriptions?). There are some counter-proposals, and the opinion that “a server cannot be allowed to choose the behaviour here. We need to decide one way or the other.” However it is marked TC Approve proposal - TC call 10.10.2013. Those minutes do not illuminate the discussion.
- Can this be reopened to remove the MAY clause? (I realize we are late to the party, but have to ask as this is open for community feedback.)
- If no changes are made, how is it envisioned that the Client deal with this
ambiguity? (I’m hoping this goes beyond “don’t do this.”)
- If no changes are made, can you verify my understanding of the scenario
outlined above, and the assumptions it makes?
- Should the behavior be clarified in non-normative text?
<<<
>>>
mqtt-comment from David Kemper
According to the current draft:
“The character data in a UTF-8 encoded string MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC3629]. In particular this data MUST NOT include encodings of code points between U+D800 and U+DFFF. If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection [MQTT-1.4.0-1].”
“A UTF-8 encoded string MUST NOT include an encoding of the null character U+0000. If a receiver (Server or Client) receives a Control Packet containing U+0000 it MUST close the Network Connection [MQTT-1.4.0-2].”
This requires the server to scan the UTF-8 content of all strings in all
packets. Since the strings themselves are bounded by a length prefix, can this be “downgraded” to “SHOULD” and “SHOULD NOT” for lower-latency solutions?
<<<