SUBACK
Subscription Acknowledgement
The SUBACK message is sent from the broker to the client to confirm receipt
of a SUBSCRIBE message. It contains a list
of "granted" Quality of Service levels. Each of
these is the QoS at which the broker's administrators have permitted
the client to subscribe to a particular Topic Name. The order of granted
QoS levels in the list is the same as the Topic Name list in the corresponding
SUBSCRIBE
message.
Fixed Header
See the Fixed Header section for more information,
| bit |
7
|
6
|
5
|
4
|
3
|
2
|
1
|
0
|
| byte 1 |
Message Type (9)
|
DUP flag
|
QoS level
|
RETAIN
|
| |
1
|
0
|
0
|
1
|
x
|
x
|
x
|
x
|
| byte 2 |
Remaining Length
|
QoS level
The QoS level is not used for the SUBACK message.
DUP flag
The DUP flag is not used for the SUBACK message.
RETAIN flag
The RETAIN flag is not used.
Remaining Length
The Remaining Length is the length of the Variable Header.
This may be a multi-byte field. See the Fixed
Header section for more details.
Variable Header
The Variable Header portion of the SUBACK message contains the Message
Identifier of the SUBSCRIBE message that is
being acknowledged.
See the Variable Header section for
more information.
| bit |
7
|
6
|
5
|
4
|
3
|
2
|
1
|
0
|
| byte 1 |
Message Identifier MSB
|
| byte 2 |
Message Identifier LSB
|
Payload
The Payload of the SUBACK message contains a vector of "Granted" Quality
of Service levels, each corresponding to a Topic Name in the SUBSCRIBE
message to which this is the reply. Each of these is the QoS at which
the broker's administrators have permitted the client to subscribe to a
particular Topic Name.
The order of QoS levels in the SUBACK is the same as the order of Topic
Name and Requested QoS pairs in the SUBSCRIBE message. The Message ID in
the Variable Header makes it easy to match SUBACKs with SUBSCRIBEs back
at the client.
The Granted Quality of Service field is encoded in a byte as follows:
| bit |
7
|
6
|
5
|
4
|
3
|
2
|
1
|
0
|
| |
reserved
|
reserved
|
reserved
|
reserved
|
reserved
|
reserved
|
QoS level
|
| |
x
|
x
|
x
|
x
|
x
|
x
|
|
|
The upper 6 bits of this byte are currently unused in this version
of the protocol. They are, however reserved for future use.
Example:
| Granted QoS |
0 |
| Granted QoS |
2 |
The format of the Payload in this case would be:
| |
Description |
7 |
6
|
5
|
4
|
3
|
2
|
1
|
0
|
| Requested QoS |
| byte 1 |
Granted QoS (0) |
x |
x
|
x
|
x
|
x
|
x
|
0
|
0
|
| Granted QoS |
| byte 2 |
Granted QoS (2) |
x |
x
|
x
|
x
|
x
|
x
|
1
|
0
|
Discussion
-
ASC on SUBACK
-
Note that this response gives no indication as to the validity of the subscription
request - the topics may not exist (they may not have been published to
as yet), or the client may not be authorised to subscribe to particular
topics. It would be possible to return a list of return codes, indicating
success/non-existent topic/not authorised, but it is not considered necessary
for inclusion in this version of the protocol.
-
ASC on QoS
-
If there are ever likely to be multiple in-flight SUBSCRIBE messages, we
might want to add Message Identifier and DUP bit processing to SUBSCRIBE/SUBACK
to make it a true QoS 1 message. I do not foresee any need for this, though.
-
ASC comment
-
That time has come: Version 2 of the protocol makes SUBSCRIBE a QoS1 message.
BACK to index
Last Modified: 19-Oct-99