OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-308) Further Ack return codes.


    [ https://issues.oasis-open.org/browse/MQTT-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63677#comment-63677 ] 

Andrew Banks commented on MQTT-308:
-----------------------------------

There is currently a silent error case, where the client makes the TCP connection but does not send the whole of the CONNECT packet promptly. Should we have a CONNACK  return code for this case?  The problem is that it could be that, if we have not seen the client's credentials, it could be a denial of service.

> Further Ack return codes.	
> --------------------------
>
>                 Key: MQTT-308
>                 URL: https://issues.oasis-open.org/browse/MQTT-308
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 5
>            Reporter: Andrew Banks
>            Assignee: Ed Briggs
>
> Follow on issue for MQTT-236 Consolidate Acks, enable negative acknowledgements.	
> Ed Briggs added a comment - 20/Sep/16 12:16 PM
> The following return codes are missing from WD04. I am adding the missing entries here as this JIRA has not been closed. 
> CONNACK 
> 139 0x8B Message too large (big strings, metadata etc.) 
> 140 0x8C Banned. You are banned from connecting. Please contact the administrator.
> 141 0x8D Exceeded Reconnect Rate Limit. Please try again, later. 
> PUBACK 
> 130 0x82 Message Refused, publication not authorized. 
> 131 0x83 Message Refused, implementation specific, e.g. client quota reached. 
> 132 0x84 Not Authorized 
> 133 0x85 Invalid topic name 
> 134 0x86 Packet Identifier in use (possible session state issue) 
> 135 0x87 QoS Level not supported 
> 136 0x88 Retain not supported 
> 137 0x89 Message too large. (probably needs and admin fix) 
> 138 0x8A Message rate too high (wait and retry might work) 
> 139 0x8B Server Quota Exceeded (might be temporary) 
> 140 0x8C Receiver capacity reached 
> 141 0x8D Invalid meta data tag 
> 142 0x8E Invalid reply topic 
> 143 0x8F Message Rate too High. 
> PUBREC 
> ----------- 
> 129 0x81 Message Refused, reason unspecified. 
> 130 0x82 Message Refused, publication not authorized. 
> 131 0x83 Message Refused, implementation specific, eg. client quota reached. 
> 132 0x84 Not Authorized 
> 133 0x85 Invalid topic name 
> 134 0x86 Packet Identifier in use (possible session state issue) 
> 135 0x87 QoS Level not supported 
> 136 0x88 Retain not supported 
> 137 0x89 Message too large. (probably needs and admin fix) 
> 138 0x8A Message rate too high (wait and retry might work) 
> 139 0x8B Server Quota Exceeded (might be temporary) 
> 140 0x8C Receiver capacity reached 
> 141 0x8D Invalid metadata tag 
> 142 0x8E Invalid reply topic 
> 143 0x8F Message Rate Too High 
> SUBACK 
> --------------- 
> 134 0x86 Client Quota Exceeded 
> DISCONNECT 
> ------------------ 
> Message too large should not be a DISCONNECT reason (IMO). There are return codes for PUBACK and PUBREC to handle this. By using these, the 'nak' implicitly acknowledges the oversize message so that it will not be retransmitted, and other messages (of appropriate size) can be delivered. By using Disconnect, we create a problem - If persistent sessions and QoS > 0 are used, an endless re-connect/retry cycle will occur and no forward progress can be made.
> Ken Borgendale added a comment - 20/Sep/16 2:04 PM
> A number of possible return codes were not included in the draft of MQTT-236 as they pertained to function in JIRAs which are not yet approved. In general we should add the return codes when we define the function they pertain to. For instance for "message too large" we need to define what a message is (application message?, packet?). The same is true for things like "QoS not supported" and "Retain not supported". When we define the basic concepts of optional part of the implementation we should define these return codes. 
> PUBACK, PUBREC: 
> - The "Not authorized", "Unspecified error", and "implementation specific error" do show in the list. 
> - The "invalid topic name", "Packet ID in use", Invalid metadata and invalid replyto are all protocol errors and should cause the connection to close (and therefore are on disconnect). It does not really work to send a PUBACK saying a packetID is already in use for instance (which one does the ACK apply to?). We could have a return code for "the topic name is valid but not acceptable to this sever or client". This would be breaking out the "implementation specific error" and we would want to define some semantics for it. 
> - I agree we probably want some return codes for capacity limits, but this should probably be a separate JIRA discussion 
> SUBACK 
> - Same discussion about capacity limits. It seems we should either describe the semantics of these limits in the spec, or say servers should use the "implementation specific error". 
> DISCONNECT: 
> The "message too large" probably should have been left out until we discuss the concept of max message size. For QoS=0 there is no place other than DISCONNECT to return this error. A client which gets a disconnect with a return code of "message too large" should not reconnect and retry the publish. However, it seems better if this size limit is declared in CONNNECT and CONNACK. 
> In any case, we should have a discussion at the face to face in Hursley and go thru the set of return codes. 



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