A basic understanding diagram of MQTT:
Basic flow chart:
MQTT is a link protocol that specifies how to organize data bytes and transmit them over a TCP/IP network. But in reality, developers don’t need to link to the specific details of this linking protocol. All we need to know is that each message has a command and data payload. This command defines the message type (such as CONNECT message or SUB SCRIBE message). All MQTT libraries and tools provide basic methods to handle these messages directly and automatically fill in some necessary fields (in the corresponding bytes of the packet), such as message and client ID.
First, the client sends a CONNECT message to connect to the proxy. The CONNECT message requires the establishment of a link from the client to the proxy server.
Basic parameters of CONNECT command
- cleanSession: This flag specifies whether the connection is persistent. A persistent session stores all subscriptions and potentially lost messages (depending on QoS) in the broker (server).
- username: Username to connect to the proxy server. (Yes, the proxy server is not for anyone to connect to, you can connect to it if you want)
- password: Password for connecting to the proxy server. (Yes, the proxy server is not for anyone to connect to, you can connect to it if you want)
- lasWillTopic: The link is interrupted unexpectedly, and the proxy server will send a last will message to a certain topic.
- lastWillQos: QoS of last will message.
- lastWillMessage: the last will message itself.
- KeepAlive: This is the time interval required for the client to keep the link alive by pinging the server.
When the client sends a CONNECT command to the proxy server, the server will call the CONNACK command to inform the service link status.
Basic parameters of CONNACK command
- sessionPresent: This parameter indicates whether the link already has a persistent session. That is, the subscribed topic is connected and missing messages will be accepted.
- returnCode: 0 indicates success. otherwise fails.
After the client and server establish a connection, the client can subscribe to certain topics from the server. (Send one or more SUBSCRIBE messages).
Indicates that when the server receives this topic data pushed by other terminals, the server will send it to it by default.
SUBSCRIBE parameter list
- QoS: quality of services. Generally there are 3 enumeration values.
- 0: Indicates unreliable service. The message is only pushed once. If the current client is online or not received due to network reasons, it will not be received.
- 1: The message is delivered at least once. If it fails once, pass it the second time, the Nth time. Duplicate data may occur.
- 2: The message is delivered exactly once. The two parties use a 4-way handshake to ensure that the message can be accurately transmitted from the server to the client, and only once.
Although QoS parameters are specified on the client, they specify the mode in which the server delivers data. Therefore, QOS is used to constrain the server, not the client itself.
- topic: The topic to which the client wants to subscribe.
A topic can have multiple levels, separated by slash characters. For example, “dw/demo” and “/ibm/bluemix/qmqt” are both valid topics.
When the client successfully subscribes to a topic from the server, the server will return a SUBACK message containing one or more returnCode parameters.
SUBACK message parameters
- returnCode: Value 0-2, indicating successful subscription and returning the QOS of this subscription message. Value 128: Subscription failed.
Since the client can subscribe to a topic from the server, it can also unsubscribe.
The opposite command of the SUBSCRIBE subscription command is the UNSUBSCRIBE unsubscribe command.
This command is very simple. There is only one topic parameter.
- topic: This parameter is the topic that the client unsubscribes from.
The above is about subscription. Subscription requires messages to be sent from the server. But the server itself basically does not generate data, so where does the data come from?
Execute the PUBLISH command through another client to send data to the proxy server. And finally pass the data through the proxy server to the clients subscribed to this service.
PUBLISH message parameters
- topicName: Related topics for publishing messages.
- qos: The quality level of message delivery. (constraint server)
- retainFlag: This flag indicates whether the server retains this message as the last known message for this topic.
- payload: the actual data in the message. It can be a text string or a binary large object data (image)
Resuma
- MQTT is a lightweight protocol used for data transmission between terminal devices with weak computing power and poor network environment.
- MQQ is based on a publish/subscribe basic model.
- Each terminal can subscribe to certain topics from the server and publish certain topics to the proxy server.
- When the server receives data sent from certain terminals, it will push the data to terminals that subscribe to this service.