For better understanding of MQTT protocol, it can be useful to study the message flow between clients and server for each of following stages:

• Client connection to the broker
• Client subscription to a topic and client receiving a message from a subscription
• How a client publishes a message to a topic for all possible QoS Levels
• Keeping connection alive between client and server
• Closing connection
• Receiving will message from unexpectedly client disconnection

A client connects to the broker sending a CONNECT message and the broker responds with a CONNACK message. When the client is connected, it starts a session and it can subscribe to one or more topic for receiving messages. The CONNECT message has the “clean session” flag that the client can set or not to avoid that all subscriptions will be lost when it will disconnect from the broker. If “clean session” is true, the subscriptions are valid only inside the session, so that if a client disconnects from the broker without it unsubscribes from all topics, the broker will unsubscribe it (clean session) and the client won’t be subscribed on these topic on the next connection.

Figure 3.5 : CONNECT message with “clean session” set

If “clean session” is false, the broker doesn’t unsubscribe the client on disconnection so that it will be automatically subscribed on all topics of the previous session.

Figure 3.6 : CONNECT message with “clean session” unset

Client subscription is very simple because the client sends a SUBSCRIBE message with the topic it want to subscribe and receive a SUBACK message from the broker. From this moment, the client receives all messages published on that topic until it unsubscribe sending a UNSUBSCRIBE message to the broker and receiving a UNSUBACK message.

Figure 3.7 : SUBSCRIBE and UNSUBSCRIBE message for a topic

A client can publish a message using one of three different QoS levels. In the simple case, QoS Level 0 (At most once), the message is sent and “if” it arrives to the broker, it will deliver this message to the subscribers. The client doesn’t wait for an acknowledge from broker and delete message immediately. It isn’t guaranteed that the message arrives to destinations.

Figure 3.8 : PUBLISH message with QoS Level 0 (At most once)

Using QoS Level 1 (At least once), the client publishes the message storing it locally until it receives acknoweldge from broker that has sent the message to the subscribers. If the client doesn’t receive the acknoweledge message, it resends the message (so it arrives to destination ”at least once”).

Figure 3.9 : PUBLISH message with QoS Level 1 (At least once)

The last possibility is to publish a message with QoS Level 2 (Exactly once). In this case there is a lot of traffic between publisher and broker to avoid message lost and message duplication to destination.

Figure 3.10 : PUBLISH message with QoS Level 2 (Exactly once)

When the clients doesn’t send any message on the network, it is necessary keeping alive the connection using a ping message to avoid that broker closes the connection itself.

Figure 3.11 : Ping message to keep alive connection

The simpler message in MQTT protocol is the disconnect message that the client sends to the broker when it wants to close connection. In this case, the broker hasn’t to send a response message to the client; if it doesn’t receive the message, it will close the connection due to timeout.

Figure 3.12 : Disconnection of the client

An interesting feature offered by MQTT protocol is the ”will” message. When a client connects to the broker, it can send a ”will” message and relative topic  as payload of connect message. The broker will send this message to all interested subscriber when it detects that the publisher disconnects unexpectedly without sending the disconnect message.

Figure 3.13 : ”Will” message feature