Internet Protocol - MQTT message queue telemetry transmission protocol

Posted by WRa on Sat, 05 Mar 2022 07:44:29 +0100

catalogue

MQTT

MQTT (Message Queuing Telemetry Transport) is a "lightweight" communication protocol based on Publish / Subscribe mode. The protocol is built on TCP/IP L4 Layer and released by IBM in 1999. It is a Publish / Subscribe message protocol designed for remote devices with low hardware performance and scenarios with poor network conditions. Therefore, it needs a message middleware (Broker).

The biggest advantage of MQTT is that it can provide real-time and reliable message services for connecting remote devices with very little code and limited bandwidth. As an instant messaging protocol with low overhead and low bandwidth occupation, it is widely used in the Internet of things, small devices, mobile applications and so on.

Design principles of MQTT

  1. Streamline and do not add dispensable functions;
  2. Publish / subscribe (Pub/Sub) mode to facilitate the transmission of messages between sensors;
  3. Allow users to dynamically create topics with zero operation and maintenance cost;
  4. Reduce the transmission volume to the minimum to improve the transmission efficiency;
  5. Take into account factors such as low bandwidth, high delay and unstable network;
  6. Support continuous session control;
  7. Understand that the computing power of the client may be very low;
  8. Provide service quality management;
  9. Assuming that the data is unknown, the type and format of transmission data are not required to maintain flexibility.

Implementation principle of MQTT

In the communication process of MQTT protocol, there are three roles:

  1. Publisher (Publish)
  2. Agent (Broker)
  3. Subscriber (Subscribe)

Among them, both the publisher and subscriber of the message are MQTT Client, and only the message agent is MQTT Server. The message publisher can also be a subscriber.

MQTT Client can:

  • Establish a connection with the server.
  • Publish information that other clients may subscribe to;
  • Subscribe to messages published by other clients;
  • Unsubscribe or delete messages from other clients;
  • Disconnect from the server.

MQTT Server can:

  • Accept the network connection from the client;
  • Accept the application information published by the client;
  • Processing subscription and unsubscribe requests from clients;
  • The message that the subscribing application forwards to the client.

MQTT Message is divided into two parts:

  1. Topic: it can be understood as the type of message. The publisher publishes a "topic", and the subscriber chooses to Subscribe to several "topics". After the subscriber subscribes and the publisher publishes a message, it will receive the message content (Payload) of the topic;
  2. Payload: it can be understood as the content of the message, which refers to the specific content to be used by the subscriber.

When application data is transmitted through MQTT network, MQTT will associate the QoS related to it with Topic.

Key terms of MQTT

Subscription: contains Topic Filter and QoS. A subscription is associated with a Session. A Session can be associated with multiple subscriptions. Each subscription in each Session has a different Topic Filter.

Session: the connection established between the Client and the Server is a session, and there is a stateful interaction between the Client and the Server.

Topic Name: a label that matches the Subscription of the Server. The Server sends a message to each Client with a tag matching the Subscription.

Topic Filter: a wildcard filter for Topic Name, which is used in the subscription expression to represent multiple topics matched by the subscription.

Payload: the specific content received by the message subscriber.

Method of MQTT

MQTT protocol defines some methods (also known as actions) to represent the operation on the determined resources. This resource can represent pre-existing data or dynamically generated data, depending on the implementation of the server. Generally speaking, resources refer to files or output on the server.

The main methods are:

  • Connect: wait for a connection to the server to be established.
  • Disconnect: wait for the MQTT client to complete its work and disconnect the TCP/IP session from the server.
  • Subscribe: wait for the subscription to complete.
  • UnSubscribe: wait for the server to UnSubscribe from one or more Topics of the client.
  • Publish: the MQTT client sends a message request and returns to the application thread after sending.

MQTT message structure

An MQTT message consists of the following three parts:

  1. Fixed header: it exists in all MQTT messages and represents the message type and packet class identification of the message.
  2. Variable header: it exists in some MQTT messages. The message type determines whether the variable header exists and its specific content.
  3. Payload: it exists in some MQTT messages and represents the specific content received by the client.

Linux MQTT Server

  • Install mosquitto
yum install gcc-c++ cmake openssl-devel -y

wget http://mosquitto.org/files/source/mosquitto-1.6.8.tar.gz
tar -zxvf mosquitto-1.6.8.tar.gz
cd mosquitto-1.6.8
make && make install
ln -s /usr/local/lib/libmosquitto.so.1 /usr/lib/libmosquitto.so.1
ldconfig
  • to configure
$ vi /opt/mosquitto-1.6.8/mosquitto.conf
...
user root
  • Start MQTT Server
$ mosquitto -c /opt/mosquitto-1.6.8/mosquitto.conf -d

$  ps -aux | grep mosquitto
root      6603  0.0  0.0  22428  2768 ?        Ss   12:20   0:00 mosquitto -c /opt/mosquitto-1.6.8/mosquitto.conf -d

$  netstat -lpntu | grep mosquitto
tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      6603/mosquitto
tcp6       0      0 :::1883                 :::*                    LISTEN      6603/mosquitto
  • Start MQTT subscriber
$ mosquitto_sub -t topic

# mosquitto_ Description of sub command parameters.
# -c set 'clean session' to the invalid state, so that the subscription state can be maintained all the time. Even if the connection has been lost, if you connect again, you can still receive the messages sent during the disconnection.
# -d print debug information.
# -h specifies the domain name to be connected. The default is localhost.
# -i specify the clientId.
# -I specifies the clientId prefix.
# -k keepalive sends a PING message to notify the Broker that it is still connected at regular intervals. The default is 60 seconds.
# -q specifies what QoS message you want to receive. The default QoS is 0.
# -R does not display stale messages.
# -t specifies the Topic of the subscription.
# -v print messages.
# --Will payload specifies a message that is sent when the Client and the Broker accidentally disconnect. This parameter needs to be used with -- will topic.
# --Will QoS specifies the QoS value of will. This parameter needs to be used with -- will topic.
# --Will retain specifies that the will message is treated as a retain message (that is, after the message is broadcast, the message is retained). This parameter needs to be used with -- will topic.
# --Will Topic specifies the Topic that the user sends a will message.
  • Start MQTT publisher
mosquitto_pub -t topic -m "HELLO"

# mosquitto_ Description of pub command parameters:
# -d print debug information.
# -f take the content of the specified file as the content of the sending message.
# -h specifies the domain name to be connected. The default is localhost.
# -i specifies which clientId user to send the message to.
# -I specifies which clientId prefix to send messages to.
# -m message content.
# -n sends a null message.
# -p connection port number.
# -q specifies the value of QoS (0,1,2).
# -Tspecify t opic name
# -u specifies the Broker access user.
# -P specifies the Broker access password.
# -V specifies the MQTT protocol version.
# --Will payload specifies a message that is sent when the Client and the Broker accidentally disconnect. This parameter needs to be used with -- will topic.
# --Will QoS specifies the QoS value of will. This parameter needs to be used with -- will topic.
# --Will retain specifies that the will message is treated as a retain message (that is, after the message is broadcast, the message is retained). This parameter needs to be used with -- will topic.
# --Will Topic the Topic that the user sends the will message.

Android MQTT Client

Mushroom IoT:

  • Connect to MTTT Server

  • Subscribe to a Topic

  • Post messages to a Topic

Topics: computer networks