MQTT Protocol Note Subscriptions

Objective

Memory is not very good when, can only look at the previous article/notes to review again, but could not find the MQTT protocol about the subscription part of the description, very hard to find from Evernote, so the entire MQTT protocol notes, it is more complete.

SUBSCRIBE

In general, after the client has successfully established a TCP connection, the client sends a connect message, and after the server-side authorization is allowed to establish a connack message connected to each other, the clients send a SUBSCRIBE message to subscribe to the list of topic topics of interest (at least one topic). A complete demonstration is as follows:

	Description	7	6	5	4	3	2	1	0
Fixed header/fixing head
BYTE 1		Message Type (8)				DUP Flag	QoS level		RETAIN
		1	0	0	0	0	0	1	X
BYTE 2	Remaining Length
Variable Header/variable head
Message Identifier
BYTE 1	Message ID MSB (0)	0	0	0	0	0	0	0	0
BYTE 2	Message ID LSB (10)	0	0	0	0	1	0	1	0
playload/message body
Topic Name
BYTE 1	Length MSB (0)	0	0	0	0	0	0	0	0
BYTE 2	Length LSB (3)	0	0	0	0	0	0	1	1
BYTE 3	' A ' (0x61)	0	1	1	0	0	0	0	1
BYTE 4	'/' (0x2F)	0	0	1	0	1	1	1	1
BYTE 5	' B ' (0x62)	0	1	1	0	0	0	1	0
Requested QoS
BYTE 6	Requested QoS (1)	X	X	X	X	X	X	0	1
Topic Name
BYTE 7	Length MSB (0)	0	0	0	0	0	0	0	0
BYTE 8	Length LSB (3)	0	0	0	0	0	0	1	1
BYTE 9	' C ' (0x63)	0	1	1	0	0	0	1	1
BYTE 10	'/' (0x2F)	0	0	1	0	1	1	1	1
BYTE 11	' d ' (0x64)	0	1	1	0	0	1	0	0
Requested QoS
BYTE 12	Requested QoS (2)	X	X	X	X	X	X	1	0

Fixed Head

Qos level, according to the actual situation can be adjusted to 0/1/2 and so on. A general setting of 0 indicates a maximum of one time. The client can set the Oos level value. DUP flag, a value of 0, indicates the first time it was sent.

Variable Head

Because the above model QoS level value is 1, the client is required to pass the message id,16 bit, the unsigned short type.

Message body

The subject name of the subscription is encoded with the modified version UTF-8, followed by the corresponding QoS value. The following sequence may be more vivid:

Topic Name	"A/b"
Requested QoS	1
Topic Name	"C/D"
Requested QoS	2

The subscriber's topic name supports wildcard characters # and +:

1. #支持一个主题内任意级别话题
2. + Match only one topic-level wildcard character

eg

finance/stock/#finance/sotkc/ibm/+

are valid, more specific rules, see the Protocol Additions section.

When the server receives processing, it can be read sequentially:

String topicName = readUTF();int qosVal = read();

The server can send messages with no QoS greater than the client setting Oos, especially when the server does not provide a good persistence mechanism.

SUBACK

The server returns a confirmation message for the message that issued the subscribe.

 	description	7	5	4		2	1
Fixed header/fixing head
BYTE 1		Message Type (9)				DUP Flag	QoS Flags		RETAIN
		1	0	0	1	X	X	X	X
BYTE 2		Remaining Length
Variable Header/variable head
Message Identifier
BYTE 1	Message ID MSB (0)	0	0	0	0	0	0	0	0
BYTE 2	Message ID LSB (10)	0	0	0	0	1	0	1	0
playload/message body
BYTE 1	Granted QoS (0)	X	X	X	X	X	X	0	0
BYTE 1	Granted QoS (2)	X	X	X	X	X	X	1	0

Variable Head

Message Identifier, the server needs to be attached and the client needs to process.

Message body

QoS, the list of QoS levels granted to the server on a case-by-case basis, and the subscribe subscriptions sent by the client topic the name in exactly the same order.

The client subscribes to several topic, and the server side gives the QoS specific values for each topic.

Unsubscribe

The server needs to support the client unsubscribe function, unsubscribe message format and subscribe message format is similar, in addition to different message types, the message body does not have QoS bytes, the other no difference.

	Description	7	6	5	4	3	2	1	0
Fixed header/fixing head
BYTE 1		Message Type (10)				DUP Flag	QoS level		RETAIN
		1	0	1	0	0	0	1	X
BYTE 2	Remaining Length
Variable Header/variable head
Message Identifier
BYTE 1	Message ID MSB (0)	0	0	0	0	0	0	0	0
BYTE 2	Message ID LSB (10)	0	0	0	0	1	0	1	0
playload/message body
Topic Name
BYTE 1	Length MSB (0)	0	0	0	0	0	0	0	0
BYTE 2	Length LSB (3)	0	0	0	0	0	0	1	1
BYTE 3	' A ' (0x61)	0	1	1	0	0	0	0	1
BYTE 4	'/' (0x2F)	0	0	1	0	1	1	1	1
BYTE 5	' B ' (0x62)	0	1	1	0	0	0	1	0
Topic Name
BYTE 6	Length MSB (0)	0	0	0	0	0	0	0	0
BYTE 7	Length LSB (3)	0	0	0	0	0	0	1	1
BYTE 8	' C ' (0x63)	0	1	1	0	0	0	1	1
BYTE 9	'/' (0x2F)	0	0	1	0	1	1	1	1
BYTE 10	' d ' (0x64)	0	1	1	0	0	1	0	0

The presence of a variable header's message ID is still determined by the fixed header's QoS level (1).

In general, the client post unsubscribe, the server side needs to return the unsubscribe confirmation.

Mqtt does not say whether to allow clients to unsubscribe from all topic.

Unsuback

The unsubscribe message Unsuback returned by the server is simple and has no message body.

	Description	7	6	5	4	3	2	1	0
Fixed header/fixing head
BYTE 1		Message Type (9)				DUP Flag	QoS Flags		RETAIN
		1	0	1	1	X	X	X	X
BYTE 2		Remaining Length (2)
		0	0	0	0	0	0	1	0
Variable Header/variable head
Message Identifier
BYTE 1	Message ID MSB (0)	0	0	0	0	0	0	0	0
BYTE 2	Message ID LSB (10)	0	0	0	0	1	0	1	0

Summary

Subscription section, a total of four messages, respectively, one by one corresponding.

Command	Response	Notes	Recommended
SUBSCRIBE	SUBACK	The protocol does not involve the maximum number of running subscriptions topic, hidden pitfalls	Up to 10 recommendations
Unsubscribe	Unsuback	Is it possible to unsubscribe from all subscriptions, unknown	It is recommended to keep at least one topic

MQTT Protocol Note Subscriptions