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-236) Consolidate Acks, enable negative acknowledgements.


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

Ken Borgendale commented on MQTT-236:
-------------------------------------

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.





> Consolidate Acks, enable negative acknowledgements.
> ---------------------------------------------------
>
>                 Key: MQTT-236
>                 URL: https://issues.oasis-open.org/browse/MQTT-236
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 5
>            Reporter: Andrew Banks
>            Assignee: Andrew Banks
>            Priority: Critical
>             Fix For: 5
>
>
> Consolidate Acks, enable negative acknowledgements.
> ---------------------------------------------------
> Connack, SubAck, UnsubAck, PubAck, PubRec, PubRel, PubComp, PingResp
> are all flavours of an Ack. Currently there are no negative Acks.
> I suggest consolidating all of the acks into a single packet type eg the current Connack
> and using bits 3-0 of the fixed header to indicate the ack'd packet type. 
> Connect Ack     : 0010 0001 RL, SP, RC   
> Publish Ack     : 0010 0011 RL, ID, RC  (Ack Qos=0,1)
> Publish Ack     : 0010 0100 RL, ID, RC  (Ack Qos=2)
> Publish Ack     : 0010 0101 RL, ID      (Rel Qos=2)
> Publish Ack     : 0010 0110 RL, ID, RC  (Comp Qos=2)
> Subscribe Ack   : 0010 1000 RL, ID, RC(,RC)(,RC)... (Per topic)
> UnSubscribe Ack : 0010 1010 RL, ID, RC(,RC)(,RC)... (Per topic)
> Ping Ack        : 0010 1011 RL
> RL=RamainingLength, SP=SessionPresent, RC=ResponseCode ID=PacketIdentifier
> This would free up the remaining  SubAck, UnsubAck, PubAck, PubRec, PubRel, PubComp, 
> PingResp packet types for other uses.
> Connect Ack response codes
> --------------------------
> 0	0x00 Connection Accepted.
> 1-127   Reserved for future use.
> 128	0x80 Connection Refused, Malformed Packet, eg user name indicated but not present. Followed by network disconnection.
> 129	0x81 Connection Refused, reason unspecified. Followed by network disconnection.
> 130	0x82 Connection Refused, the Client is not authorized to connect. Followed by network disconnection.
> 131     0x83 Connection Refused, implementation specific, eg. server capacity reached.
>                                  Followed by network disconnection.
> 132	0x84 Connection Refused, unacceptable protocol version. The Server does not support
>                                  the level of the MQTT protocol requested by the Client.
>                                  Followed by network disconnection.
> 133	0x85 Connection Refused, identifier rejected. The Client identifier is correct UTF-8
>                                  but not allowed by the Server. Followed by network disconnection.
> 134	0x86 Connection Refused, Server unavailable. The Network Connection has been made but the 
>                                  MQTT service is unavailable. Followed by network disconnection.
> 135	0x87 Connection Refused, bad user name or password. The data in the user name or 
>                                  password is malformed. Followed by network disconnection.
> 136-255	Reserved for future use.
> Publish Ack response codes, Ack Qos=0,1
> ---------------------------------------
> A packet identifier of zero indicates an ack for a Qos=0 message, 
> rc=0,1 is not allowed for Qos=0 messages, instead no Ack should be sent.
> 0	0x00 Message Accepted, Publication of Qos=1 message proceeds, not allowed for Qos=0.
> 1	0x01 Message Accepted, No matching subscribers. Not allowed for Qos=0.
> 2-127   Reserved for future use.
> 128	0x80 Message Refused, Malformed Packet, eg invalid topic name. Followed by network disconnection.
> 129	0x81 Message Refused, reason unspecified.
> 130	0x82 Message Refused, publication not authorized.
> 131     0x83 Message Refused, implementation specific, eg. client quota reached.
> 132-255	Reserved for future use.
> Publish Ack response codes, Ack Qos=2
> -------------------------------------
> 0	0x00 Message Accepted, Publication of Qos=2 message proceeds.
> 1	0x01 Message Accepted, No matching subscribers. Should be used in preference to 0x00 
>                                If the server cannot determine whether there are any subscribers, eg because it is 
>                                in a cluster, then use response code 0x00.
>                                No PubRel,PubComp expected.
> 2-127	Reserved for future use.
> 128	0x80 Message Refused, Malformed Packet, eg packet identifier=0. Followed by network disconnection.
> 129	0x81 Message Refused, reason unspecified.  No PubRel,PubComp expected.
> 130	0x82 Message Refused, publication not authorized.  No PubRel,PubComp expected.
> 131     0x83 Message Refused, implementation specific, eg. client quota reached.  No PubRel,PubComp expected.
> 132-255	Reserved for future use.
> Publish Ack response codes, Rel Qos=2
> -------------------------------------
> There are no Publish Ack Rel Qos=2 response codes, should we add a 0x00 byte as a placeholder?
> Publish Ack response codes, Comp Qos=2
> --------------------------------------
> 0	0x00 Message Released, Publication of Qos=2 message completed.
> 1	0x01 Message Released, No matching subscribers.  Should be used in preference to 0x00 
>                                If the server cannot determine whether there are any subscribers, eg because it is 
>                                in a cluster, then use response code 0x00.
> 2	0x02 Message Released, No message existed eg. expired.
> 3-127	Reserved for future use.
> 128	0x80 Message Release Refused, Malformed Packet, eg packet identifier=0. Followed by network disconnection.
> 129	0x81 Message Release Refused, reason unspecified.
> 130	0x82 Message Release Completed without publication, publication not authorized.
> 131     0x83 Message Release Refused, implementation specific, eg. client quota reached.
> 132-255	Reserved for future use.
> Subscribe Ack response codes
> ----------------------------
> 0	0x00 Subscribe Success - Maximum QoS 0.
> 1	0x01 Subscribe Success - Maximum QoS 1.
> 2	0x02 Subscribe Success - Maximum QoS 2.
> 3-127	Reserved for future use.
> 128	0x80 Subscribe Refused, Malformed Packet, eg packet identifier=0. Followed by network disconnection.
> 129	0x81 Subscribe Refused, reason unspecified.
> 130	0x82 Subscribe Refused, not authorized.
> 131     0x83 Subscribe Refused, implementation specific, eg. client quota reached.
> 132-255	Reserved for future use.
> UnSubscribe Ack response codes
> ------------------------------
> 0	0x00 UnSubscribe Success.
> 1	0x01 UnSubscribe Success, No subscription existed.
> 2-127	Reserved for future use.
> 128	0x80 UnSubscribe Refused, Malformed Packet, eg. packet identifier=0. Followed by network disconnection.
> 129	0x81 UnSubscribe Refused, reason unspecified.
> 130	0x82 UnSubscribe Refused, not authorized.
> 131     0x83 UnSubscribe Refused, implementation specific, eg. client quota reached.
> 122-255	Reserved for future use.
> Ping Resp response codes
> -------------------------
> There are no Ping Resp response codes, should we add a 0x00 byte as a placeholder?



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