[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-412) Consolidated error handling.
Andrew Banks created MQTT-412: --------------------------------- Summary: 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]