Talk about the MQTT
For the full version, visit: Talking ABOUT MQTT
Message Queuing Telemetry Transport (MQTT) is a communication protocol designed to implement lightweight communication on lightweight devices. Therefore, MQTT is a Queuing Telemetry Transport (MQTT) protocol. It’s not as big as HTTP.
When we talk about MQTT, we will talk about a term IoT, which is the abbreviation of Internet of Things, generally translated as the Internet of Things. But for me, the understanding of the Internet of Things still stays in the network connection lights, door locks, cameras, and so on. It naturally excludes the most common mobile phones, computers. In fact, all physical devices connected to the network can be called crop networking. And we now use more and more computer mobile phone wifi, 4G connection, network instability is common, MQTT arises at the historic moment.
The design specification
- streamline
- Publish subscribe -> Facilitates messaging
- Dynamically create topics -> Zero o&M cost
- Low transmission -> high transmission efficiency
- Consider low bandwidth, high latency, and unstable networks
- Support continuous session control
- Consider low computing power clients
- Provide quality of service management
- Transfer data types and formats are not mandatory -> Remain flexible
features
- Publish subscribe message pattern, providing one-to-many message publishing. Achieve decoupling from the application
- Message transmission mechanism for masking payload content
- Provide network connections using TCP/IP
- Message transmission provides three kinds of Quality of Service (QoS)
- At most once, this level will occur message duplication or loss QoS = 0
- At most once, this level ensures that messages arrive, but messages may repeat QoS = 1
- Only once, make sure the message arrives only once, QoS = 2
- Data transfer is minimized, with fixed length headers of only 2 bytes
- Use the Last Will and Tesament features to notify interested parties of an abnormal client interruption mechanism.
- Last Will Mechanism used to notify other devices in the same topic that the device that sent the Last Will is disconnected.
Some key points of MQTT
During communication, MQTT has three identities: Publish, Broker, and Subscribe
Outside the chain picture archiving failure, the source station might be hotlinking prevention mechanism, proposed to directly upload picture preserved (img – 9 qx993cv – 1626351560548) (/ Users/admin/Library/Application Support/typora-user-images/image-20210714212442847.png)]
The publisher and subscriber are acted as the client, and the proxy is the server
Outside the chain picture archiving failure, the source station might be hotlinking prevention mechanism, proposed to directly upload picture preserved (img – CdnNGy2T – 1626351560551) (/ Users/admin/Library/Application Support/typora-user-images/image-20210714212656899.png)]
What’s so good about the publish-subscribe model all this talk?
- Spatial decoupling: Publishers and subscribers do not need to know each other.
- Time decoupling: Publishers and subscribers need not be running at the same time.
- Synchronization decoupling: The operations of two components do not need to be interrupted when published or received.
The publish/subscribe model eliminates direct communication between message publishers and message subscribers. Control which subscriber receives which message through a broker.
Is MQTT a message queue? What’s the difference between it and a message queue?
- The message queue
Clean Session
The Clean Session identifier is used to tell the broker server whether a persistent session is established.
If it is a persistent session (i.e. CleanSession = false), the broker stores all of the client’s subscriptions, as well as all lost messages at QoS level 1 or 2.
If non-persistent session CleanSession = true, the broker will not store any information from the client and will recognize any information from the last persistent session.
Username/Password
MQTT can send a user name and password to authenticate and authorize the client.
Will Message
The Last Will Message is part of last Will and Testament (LWT). When a client is abnormally disconnected, this message is sent to other clients. When a client connects, it can provide last will information to the broker in the form of MQTT messages and topics in CONNECT messages. If the client is abnormally disconnected, the Broker server will send LWT messages on behalf of the client.
KeepAlive
Keep Alive is the interval of seconds that a client assigns to the broker when establishing a connection. This interval defines the maximum time that the broker and client can tolerate without sending any messages. The client promises to send a general PING request message to the broker. The broker responds with a PING response, which is an important way to keep the client and broker alive
CONNACK response from the Broker
Outside the chain picture archiving failure, the source station might be hotlinking prevention mechanism, proposed to directly upload picture preserved nz58mws (img – 3-1626351560553) (/ Users/admin/Library/Application Support/typora-user-images/image-20210715144819580.png)]
When the broker receives a CONNECT message, it is obligated to reply to a CONNACK message
The CONNACK message contains two parts
- The session Present Flag Indicates The current session flag
- A Connect return code Connection return status code
Session Present flag
This identity tells the client whether the broker has kept a persistent session available from the previous interaction. When the client sets Clean Session to true, this value is always unavailable, i.e., false, because there will never be a Session available. If Clean Session is set to false
Two things can happen here:
True if the session information corresponding to the clientId is available and the broker has stored the session information
Otherwise, false is returned if the broker does not have any session information for the clientId
Connect return code
The connect return code is used to inform the client whether the connection is available
Return Code | Return Code Response |
---|---|
0 | Connection Accepted Indicates that a Connection is accepted |
1 | Unacceptable protocol version: Connection refused, unacceptable protocol version |
2 | Connection refused, identifier Rejected |
3 | Connection refused, server Unavailable |
4 | Connection refused, bad User name or Password Indicates the wrong user name or password |
5 | Connection refused, not authorized |