[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]