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=60873#comment-60873 ] 

Ed Briggs commented on MQTT-236:
--------------------------------

I've been studying this proposal carefully with the goal of fully specifying and checking the protocol FSMs. I have two questions in this regard.

1.)     This proposal adds a novel capability that checks whether there were any subscribers to a topic when a PUBLISH at QoS 1 or QoS 2 arrived and returns that status to the sender in the PUBLISH ACK: 

Publish Ack response codes QoS = 1;  0x01 - Message Accepted - No matching subscribers
Publish Ack Response code QoS = 2;  0x01 - Message Accepted - No matching subscribers

I'm curious how this new capability would be used, and what  the receiver of such an Ack response code should do. 

2.)   Also, I didn't see a distinction between client and server behavior.  Clients can receive PUBLISH messages, but do not implement subscriptions and subscribers..  Presumably, these ACKs response codes may only be sent by a server to a client.  Is that the intent?   

Thank you



> 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: 3.1.1
>            Reporter: Andrew Banks
>            Priority: Critical
>
> 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]