Android with MQTT Part – 1 (Basics)

Android with MQTT

In this MQTT tutorial we will go with little theoretical introduction which will be enough to start coding usage of MQTT protocol with android in part 2.

1. MQTT Full Form

MQTT could be abbreviation of MQ Telemetry transport. It is often abbreviated as Message Queue Telemetry transport. But there is no queuing except in certain scenarios. And MQTT stands for just MQTT and nothing else. You can see here.


2. What is MQTT?

From the official mqtt-v5.0 specification (Committee Specification Draft 01 / Public Review Draft 01):

“MQTT is a Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed so as to be easy to implement.”

The excerpt is pretty self-explanatory.


3. Where MQTT is being used?

MQTT is widely used in machine-to-machine communication. It shows its power with devices involved in IoT (Internet of things). It is extremely useful in situation when devices should consume low bandwidth and require high latency as well. It is used in healthcare devices, mobile applications, home automation devices, etc.


4. MQTT standardization

MQTT was approved by membership as an OASIS standard in Oct 2014. The latest public review draft as of writing this tutorial is here and an Approved Errata 01 is here.


5. How does MQTT work?

MQTT works on publish / subscribe pattern. Imagine every connected device in this particular network are clients. But they can be differed as publisher and subscribers, where publisher and subscribers are totally anonymous from each other. That’s the beauty of MQTT – decoupling

Subscriber (any connected client) will subscribe to topics on which they are interested to receive messages. They will not be knowing who is sending messages.

Publisher (any connected client) will send their messages on given topics. Publisher will not be aware of who is receiving messages.

Broker is the single connecting point for subscriber and publisher. Broker filters & routes messages coming on topics to subscribers who have subscribed to that topic.

Topic is a UTF-8 string. It is case-sensitive. A topic can be a single word or it can be a hierarchy of words called as levels of topic, separated by slash.

There is no restriction like topic should be pre-configured. A subscriber can choose to subscribe any new topic whenever it wants. A publisher can send message on any new string. But this should be other than reserved topic like $SYS that most of the MQTT broker choose to implement for their own purpose means for broker information. Well that depends on broker whether to follow those general implementation guide line.


6. Wildcards

Wildcard is used in MQTT topics when a subscriber wants to subscribe multiple topics at once. Publisher can not publish messages using wildcard in topic. Publisher has to have specific topic to publish messages. One can not use wild card in topic names, they are reserved.

There are two wildcard characters and hence two wild cards.

Single level wildcard (+)

The name itself is self- explanatory. It gives access to the one full single level of topic.

e.g. if a client subscribes to “apartment / flat1 / + / humidity” then client will get messages from following levels as well automatically.

  • “apartment / flat1 / bedroom / humidity”
  • “apartment / flat1 / kitchen / humidity”
  • “apartment / flat1 / hall / humidity”

And will not get messages from:

  • “apartment / flat1 / bedroom / temperature”
  • “apartment / flat1 / kitchen / brightness”
  • “apartment / flat2 / bedroom / humidity”

Single level wildcards can be used more than once in a topic hierarchy.

Multi level wildcard (#)

Multi level wildcard gives access to any number of topic levels. This wildcard character must be placed at the end of the subscription topic string & hence can be used only once in a given topic string. This wild card works like a parent level.

e.g If a client subscribe to “apartment / flat1 / #” then client will get messages from following levels as well:

  • “apartment / flat1 / bedroom / humidity”
  • “apartment / flat1 / kitchen / brightness”
  • “apartment / flat1 / hall / temperature”
    (And more of same type)

And will not get messages from:

  • “apartment / flat2 / bedroom / humidity”
  • “apartment / flat3 / bedroom / humidity”

If the topic is only “#”, then client will get all messages from broker. But one should not do so for an ordinary client, as client may not be able to or need to process these much of messages. If there are specific scenarios like saving all messages to database then it should be done by some extension service to broker.

If possible and not necessary one should apply for specific topics instead of using wildcards to reduce receiving unnecessary messages.


7. QoS (Quality of service)

This factor affects the message delivery & persistence between client and broker and specifies certainty of delivery of messages.

There are 3 levels of QoS in MQTT:

QoS = 0 (At most once)

This level specifies that message is delivered at most once or may not deliver even once. In this level the acknowledgement of delivery is not sent back. This is the fastest transfer of message among all Q0S but message does not get stored and may lost if client is disconnected or in case of server failure (depends on broker implementation). Actually, the message gets deleted from the out bound queue once it is sent by sender. So, there is no possibility of duplication of message at receiver side. This QoS is also called as ‘fire & forget’.

QoS = 1 (At least once)

This level specifies that message is delivered at least once. So of course, there are chances to get delivered more than once. This is default mode. Here the message is sent once, and if acknowledgement is not received the message is sent after a defined interval again with DUP(duplicate) flag or if received acknowledgement then deleted. Message is stored locally on both sender and receiver side until it is processed and then deleted.

QoS = 2 (Exactly once)

This level specifies that message is delivered only & exactly once. This is the safe of all QoS levels. But it is also the slowest one. There are some additional two steps overhead involved in message transmission in this level.

First step is sender sends message, receiver receives it and sends back acknowledgement(PUBREC).

The second step is sender asks receiver to complete processing the message using PUBREL signal. Then the receiver sends the PUBCOMP as reply to sender. Then after sender will delete this stored message.


QoS can be different on sender & receiver side. That means a subscriber can subscribe to a topic with its own defined QoS rather than receiving message on QoS that publisher has published. Suppose, subscriber has demanded QoS level 1 and publisher publishes message with QoS level 2, then following changes will happen in the route.

Message reaches to broker from publisher with QoS level 2 but broker sends message to subscriber with QoS level 1. So, there may be chances of duplication of message at subscriber side though the original message was with QoS 2 which ensures no duplication.


8. Retained Message

Retained Message in MQTT is a message whose retained state flag is set to true. That means it will be the message on a particular topic to which if a new subscriber subscribes it will get the last retained message to that topic / a topic pattern. This is useful when a newbie subscriber subscribes to a topic and want to get update with the current/last situation on that topic irrespective of when the next message will be sent by publisher.


9. Clean Session

If Clean Session flag is set to true with a client before client connects to broker then once the client connects to broker, if any previous data regarding that client like subscriptions, messages present are deleted and a new session is started.

But if clean session flag is set to false, the broker will look for client id and if any data present regarding client the session is continued with that information. From here if QoS 1, QoS 2 messages there from its subscribed topics, and client not connected then messages will be stored for delivery to the client later when it connects with clean session flag set to false.


10. Will / Last will

Will or Last will is like all other MQTT messages that has topic, QoS, Payload etc. It is specified at the time of connecting to broker. If client A specifies last will message to broker, then broker will send this message to other interested clients on behalf of client A, if client A is disconnected due to any reason without sending DISCONNECT message. There can be situations like network failure or server error or if client fails to communicate within keep alive time.


11. Keep Alive Iterval

Keep Alive Interval is the time that broker is ensured that client is connected. If no message or ping request is sent by client within keep alive time interval the client is considered as disconnected and vice-versa for broker. This time is specified in seconds and client communicates it while connection establishments.

Leave a Reply

Your email address will not be published. Required fields are marked *