[OASIS Issue Tracker] (MQTT-311) Common method for handling limits violations.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Andrew Banks created MQTT-311:
---------------------------------

             Summary: Common method for handling limits violations.
                 Key: MQTT-311
                 URL: https://issues.oasis-open.org/browse/MQTT-311
             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
          Issue Type: Improvement
    Affects Versions: 5
            Reporter: Andrew Banks


I'd like to propose a common error handling methodology for 
violation of the limits set out in:

MQTT-301 Metadata: CONNACK Retained messages supported
MQTT-300 Metadata: CONNACK Maximum QoS
MQTT-299 Metadata: CONNECT and CONNAC Maximum message length.


Any violation of these limits should result in the  flow of a CONNACK
or DISCONNECT packet by the receiver with a return code indicating
a protocol violation or a more explicit return code followed by network disconnection.


This is along the same lines of the approach set out in 
MQTT-310 Treat invalid topic alias as a protocol error.

The rationale is as follows.

Continuing the protocol is going to result in  data loss of some form.
This especially problematic if a following packet relies on the delivery
of an earlier one. This is the case for both the middleware and the application.

It is better that the sender applies the limits rather than 
ignoring them and relying on the behaviour of the receiver.
Defining the behaviour where some packet processing has failed will
make the protocol more complex and variants of the behaviour might emerge. Applications would start to rely on the variants.

Where the client writes ahead before it receives CONNACK, it knows that it is taking a risk.
It can mitigate the risk by not using Will messages, not publishing retained messages, 
using only short payloads and Qos=0.

The sender is able to react to the limit. For example a client implementation can inform its 
app that a packet is too big rather than sending it. Similarly a server
could disconnect its client rather than sending a packet that is larger than the client
wants to receive. This is preferable to having the application writer
model all of the possibilities of what might happen to his messages
if limits are violated. Especially where the violation happens later after a chain of sub sub steps. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)