[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-412) Consolidated error handling.
[ https://issues.oasis-open.org/browse/MQTT-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Banks updated MQTT-412:
------------------------------
Proposal:
Replace the individual descriptions with a reference to section 4.13.
So, for example 3.3.1.2 QoS changes from ...
A PUBLISH Packet MUST NOT have both QoS bits set to 1.
If a Server or Client receives a PUBLISH packet which has both QoS
bits set to 1 it is a Malformed Packet. The receiver SHOULD send
a DISCONNECT packet with Return Code of 0x81 (Malformed Packet)
and MUST close the Network Connection.
to ...
A PUBLISH Packet MUST NOT have both QoS bits set to 1.
If a Server or Client receives a PUBLISH packet which has both QoS
bits set to 1 it is a Malformed Packet. Use DISCONNECT Return Code 0x81
(Malformed Packet) as described in section 4.13 Handling errors.
Section 4.13 becomes.
4.13 Handling errors
4.13.1 Malformed Packet and Protocol Errors
Definitions of Malformed Packet and Protocol Errors are contained in
section 1.2 Terminology, some but not all, of these error cases are noted
throughout the specification. The rigour with which a Client or Server
checks an MQTT Control Packet it has received will be a compromise between:
- The size of the Client or Server implementation.
- The capabilities that the implementation supports.
- The degree to which the receiver trusts the sender to send correct
MQTT Control Packets.
- The consequences of continuing to process a packet that is incorrect.
If the sender is compliant with this specification it will not send
Malformed Packets or cause Protocol Errors. However, if a Client sends
MQTT Control Packets before it receives CONNACK,
it might cause a Protocol Error because it made an incorrect
assumption about the Server capabilities. See section 3.1.4 Response.
The return codes used for Malformed Packet and Protocol Errors are:
129 0x81 Malformed Packet CONNACK, DISCONNECT
130 0x82 Protocol Error CONNACK, DISCONNECT
147 0x93 Receive Maximum exceeded DISCONNECT
149 0x95 Packet too large CONNACK, DISCONNECT
154 0x9A Retain not supported DISCONNECT
155 0x9B QoS not supported DISCONNECT
158 0x9E Shared Subscription not supported SUBACK, DISCONNECT
161 0xA1 Subscription Identifiers not supported SUBACK, DISCONNECT
162 0xA2 Wildcard Subscription not supported SUBACK, DISCONNECT
Where a return code is mentioned in the specification,
if the Client receives a Malformed Packet
or detects a Protocol Error, it SHOULD close the Network Connection
on which it received that MQTT Control Packet.
If it closes the Network Connection,
it SHOULD send a DISCONNECT packet containing that return code
before closing it
Where a return code is mentioned in the spacification,
if the Server receives a Malformed Packet
or detects a Protocol Error, it MUST close the Network Connection
on which it received that MQTT Control Packet.
In the case of an error in a CONNECT packet
it MAY send a CONNACK packet containing that return code,
before closing the Network Connection.
For any other packet it SHOULD send a DISCONNECT packet with one of the return codes above
before closing the Network Connection.
If either the Server or Client omits to check some feature of an
MQTT Control Packet, it might fail to detect an error, consequently it
and might allow data to be damaged.
If the Client or Server encounters a Malformed Packet or Protocol Error
an error it SHOULD send a DISCONNECT packet containing return code
0x81 Malformed Packet or 0x82 Protocol Error
and then close the Network Connection.
There are no consequences for other Sessions.
4.13.2 Other errors
Errors other than Malformed Packet and Protocol Errors cannot be anticipated
by the sender. The receiver may have constraints which it has not
communicated to the sender. A receiving Client or Server might encounter a
transient error, such as a shortage of memory, that prevents successful processing
of an individual MQTT Control Packet.
Acknowledgment packets PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK
allow a Return Code of 128 or greater to indicate that the received packet,
identified by a Packet Identifier, was in error.
There are no consequences for other Sessions or other Packets flowing
on the same session.
The CONNACK and DISCONNECT packets allow a Return Code of 128 or greater to indicate
that the Network Connection will be closed. Some of these return codes are sent for reasons
other than in response to an inbound packet. Sending of one of these return codes
does not have consequence for any other Session.
was:
Replace the individual descriptions with a reference to section 4.13.
So, for example 3.3.1.2 QoS changes from ...
A PUBLISH Packet MUST NOT have both QoS bits set to 1.
If a Server or Client receives a PUBLISH packet which has both QoS
bits set to 1 it is a Malformed Packet. The receiver SHOULD send
a DISCONNECT packet with Return Code of 0x81 (Malformed Packet)
and MUST close the Network Connection.
to ...
A PUBLISH Packet MUST NOT have both QoS bits set to 1.
If a Server or Client receives a PUBLISH packet which has both QoS
bits set to 1 it is a Malformed Packet. Use DISCONNECT Return Code 0x81
(Malformed Packet) as described in section 4.13 Handling errors.
Section 4.13 becomes.
4.13 Handling errors
4.13.1 Malformed Packet and Protocol Errors
Definitions of Malformed Packet and Protocol Errors are contained in
section 1.2 Terminology, some but not all, of these error cases are noted
throughout the specification. The rigour with which a Client or Server
checks an MQTT Control Packet it has received will be a compromise between:
- The size of the Client or Server implementation.
- The capabilities that the implementation supports.
- The degree to which the receiver trusts the sender to send correct
MQTT Control Packets.
- The consequences of continuing to process a packet that is incorrect.
If the sender is compliant with this specification it will not cause
Malformed Packets and Protocol Errors. However, if a Client sends
MQTT Control Packets before it receives CONNACK,
it might cause a Protocol Error because it made an incorrect
assumption about the Server capabilities. See section 3.1.4 Response.
The return codes used for Malformed Packet and Protocol Errors are:
129 0x81 Malformed Packet CONNACK, DISCONNECT
130 0x82 Protocol Error CONNACK, DISCONNECT
147 0x93 Receive Maximum exceeded DISCONNECT
149 0x95 Packet too large CONNACK, DISCONNECT
154 0x9A Retain not supported DISCONNECT
155 0x9B QoS not supported DISCONNECT
158 0x9E Shared Subscription not supported SUBACK, DISCONNECT
161 0xA1 Subscription Identifiers not supported SUBACK, DISCONNECT
162 0xA2 Wildcard Subscription not supported SUBACK, DISCONNECT
If either the Server or Client receives a Malformed Packet
or detects a Protocol Error, it SHOULD close the Network Connection
on which it received that MQTT Control Packet.
If MAY send a CONNACK or DISCONNECT Packet with one of the return codes above
before closing the Network Connection.
If either the Server or Client omits to check some feature of an
MQTT Control Packet, it might fail to detect an error, consequently it
and might allow data to be damaged.
4.13.2 Other errors
Errors other than Malformed Packet and Protocol Errors cannot be anticipated
by the sender. The receiver may have constraints which it has not
communicated to the sender. A receiving Client or Server might encounter a
transient error, such as a shortage of memory, that prevents successful processing
of an individual MQTT Control Packet.
Acknowledgment packets PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK
allow a Return Code of 128 or greater to indicate that the received packet,
identified by a Packet Identifier, was in error.
There are no consequences for other Sessions or other Packets flowing
on the same session.
The CONNACK and DISCONNECT packets allow a Return Code of 128 or greater to indicate
that the Network Connection will be closed. Some of these return codes are sent for reasons
other than in response to an inbound packet. Sending of one of these return codes
does not have consequence for any other Session.
> Consolidated error handling.
> ----------------------------
>
> Key: MQTT-412
> URL: https://issues.oasis-open.org/browse/MQTT-412
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Components: core
> Affects Versions: 5
> Reporter: Andrew Banks
> Assignee: Andrew Banks
> Fix For: wd11
>
>
> The V5 specification defines Malformed Packet and
> Protocol Error in the terminology section.
> Malformed packets are mentioned explicitly about 15 times
> and protocol errors about 50 times throughout the specification.
> Sometimes Section 4.13 is referred to and sometimes the handling of the error
> is described in line. There are more occasions where the server is required
> to check and handle a malformed packet or protocol error than when the client is.
> In some places eg. 3.4.1 Fixed Header (PUBACK) there is no explicit
> mention of any error checking.
> Some types of protocol error have their own return code eg.
> 147 0x93 Receive Maximum exceeded DISCONNECT
> 149 0x95 Packet too large CONNACK, DISCONNECT
> Others use the generic return codes
> eg: 3.3.5 Actions (PUBLISH)
> a) If the packet has a zero length Topic Name field it is a
> Protocol Error and the receiver SHOULD send a DISCONNECT packet
> with a Return Code of 0x82 (Protocol Error)
> and then MUST close the Network Connection.
> Section 4.13 Handling errors describes how Malformed Packet,
> Protocol Error and other errors are handled.
> - It is desirable to have all error situations described individually
> and have the handling of these error described in each case. This removes
> ambiguity.
> - If any error is not described explicitly then there is an implication
> that it must not be handled.
>
> - If a lightweight implementation wants to avoid doing rigorous error
> checking and omits to do it, then it does not comply with the specification.
> - It is desirable to permit implementations to handle errors not explicitly
> called out in the specification.
> - It is desirable to permit implementations to disregard protocol errors
> and malformed packets that cause them no problem.
--
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]