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

  1. Publish subscribe message pattern, providing one-to-many message publishing. Achieve decoupling from the application
  2. Message transmission mechanism for masking payload content
  3. Provide network connections using TCP/IP
  4. Message transmission provides three kinds of Quality of Service (QoS)
    1. At most once, this level will occur message duplication or loss QoS = 0
    2. At most once, this level ensures that messages arrive, but messages may repeat QoS = 1
    3. Only once, make sure the message arrives only once, QoS = 2
  5. Data transfer is minimized, with fixed length headers of only 2 bytes
  6. Use the Last Will and Tesament features to notify interested parties of an abnormal client interruption mechanism.
    1. 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?

  1. 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