MQTT Basic| RealtimeData |Swift — 1

MQTT (originally an initialism of MQ Telemetry Transport[a]) is a lightweight, publish-subscribe, machine to machine network protocol for message queue/message queuing service. It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth, such as in the Internet of Things (IoT). It must run over a transport protocol that provides ordered, lossless, bi-directional connections — typically, TCP/IP.[1] It is an open OASIS standard and an ISO recommendation (ISO/IEC 20922).

Let’s understand key terms from above definition before driving into real applications:-

Lightweight:-

• The protocol overhead of MQTT is extremely small.
• The smallest packet has only 2 bytes overhead.
• The payload-to-overhead ratio is typically extremely good.
• It’s also a binary protocol which reduces the overhead on the wire a lot.
• It is lightweight since it consumes very less bandwidth and battery loss is less
• It ensures smooth data transfer with low bandwidth and reduces the load on the CPU and RAM.

Publish-subscribe:-

• MQTT is a publish and subscribe protocol.
• You can subscribe on some topics and publish on others. You’ll receive messages on topics you subscribe to and those who subscribe to the topics you publish will receive those messages.
• The word “topic” refers to an UTF-8 string that the broker uses to filter messages for each connected client
• The publish-subscribe messaging pattern requires a message broker. The MQTT server is usually referred to as the broker. There are various types of MQTT broker like Mosquitto, HiveMqtt, Mosca, cloudMQTT, MQTT.Js
• Publish information over unreliable networks and provide reliable deliveries over fragile connections
• A server, or broker, which communicates with the clients (publishers and subscribers) via an internet connection or a local network.
• A publisher creates messages and publishes them to a certain topic.
• A subscriber receives the messages relevant to the topic it is subscribed to.
• Publishers and subscribers may switch roles, and sometimes MQTT clients take on the role of both.
• Each topic comprises different subtopics, or levels, that form a hierarchy. By publishing messages to the exact subtopics, the publisher will be able to reach the intended recipient that has a subscription for the same topic levels.

Machine to machine:-

The cloud hosts an MQTT broker(Mosquitto, HiveMqtt, Mosca, cloudMQTT, MQTT.Js) — an intermediary between machines and other machines and/or people. And this is an important distinction, as the machines do not communicate directly with each other, but through the broker.

Message queue/message queing service* :-

• MQTT provides 3 QOS levels which can be used to guarantee message delivery .
• QOS of 1 or 2 will guarantee message delivery in the case of a short break in the network.
• Buffering can occur on the client and the broker.
• If the network connection fails between a client and broker then the client needs to buffer outgoing messages until it is restored.
• Message buffering is done in memory and most clients will buffer or queue messages by default.
• The client will usually have a setting that governs buffering
• That doesn’t mean that all messages will be queued as queueing will eventually fail as the memory is consumed.
• When this buffer is full the client has no option but to overwrite existing messages or discard new messages.
• You should be aware that small clients implemented on sensors will have very little buffering capability.
• Although buffering messages using a QOS of 1 would seem the most logical thing to do you need to be aware of the consequences.

Problems with Buffering Messages?

• If the network is down for a very short time (seconds not minutes) then holding messages isn’t really a problem as they will be sent with a short delay.
• However if it is down for minutes or hours does the application receiving the data really need to receive those messages or can it safely skip them?
• As an example lets assume we have 100 sensors sending temperature measurements every second to a broker and the broker sends messages to the cloud.
• Now if we have a network break to the cloud of 5mins then we will have to hold 100*5*60 =30000 messages.
• Once restored we then need to send and process 30000 messages on the receiver.
• These messages would have priority over new incoming messages meaning there would be even more of a delay before the application was receiving up to date data, and not historical data.
• The decision on whether or not to buffer messages cannot be taken without regard to the applications that are consuming those messages.
• Reliability of message delivery is important for many IoT use cases. This is why MQTT has 3 defined quality of service levels: 0 — at most once, 1- at least once, 2 — exactly once

Resource Constraints/Limited network bandwidth:-

MQTT is efficient protocol for unreliable networks. It allows for persistent sessions between the client and broker. Unlike many other protocols, if the connection is broken for any reason, the broker retains the information required to reconnect the client and does so automatically.

IOT:-

The Internet of things (IoT) describes physical objects (or groups of such objects) with sensors, processing ability, software and other technologies that connect and exchange data with other devices and systems over the Internet or other communications networks.[

Transport protocol that provides ordered:-

• No guarantees are made about the relative ordering of messages published with different QoS values. (for example, QoS 0 can over take QoS 2 for example as it involves a single packet rather than the 4 packets of the latter).
• QoS 0 messages will be delivered in order (albeit messages may get lost)
• QoS 2 messages will be delivered in order
• QoS 1 allows for message duplicates — it is possible a duplicate will arrive after the first instance of the next message that was published.
• QoS 1 ordering can be guaranteed if the client/broker only allow a single message inflight at any time.

Lossless

TCP comes with error correction and retransmission for lost packets only for the duration of a session. If the TCP session gets dropped (like when you reboot a machine) then all the TCP buffers are gone and you lose data.

MQTT QOS 1 and QOS 2 will not lose data, even when the publisher, subscriber, or mqtt broker reboots. It does this by writing messages to disk or some other non volatile place that can survive a reboot.

Bi-directional connections

• Bidirectional communication is when two or more parties take part in the conversation, in other words, a two-way conversation occurs. Each party consists of an individual, a group of individuals or an organisation.
• MQTT is bidirectional and maintains stateful session awareness.
• If an edge-of-network device loses connectivity, all subscribed clients will be notified with the “Last Will and Testament” feature of the MQTT server so that any authorised client in the system can publish a new value back to the edge-of-network device, maintaining bidirectional connectivity.

Basic requirement of MQTT Implementations:-

- Connection setup
- Connection tear up
- MQTT broker
- MQTT Client
- Publisher/subscribe
- Topic/Subtopic
- Internet
- Server to store message
- Client to store message
- SSL + MQTT

Let’s catch up implementation of MQTT+Swift+Broker in next topic

Thanks Again for reading article.

Let’s hope you enjoyed first part of MQTT Realtime data in swift. But I love to hear from you: what works, what doesn’t? Did I leave anything out? Are there any MQTT strategies that you’d like to see included here? 🙏🙏

If you found this interesting, you will enjoy these related articles I wrote:

50+ ways to secure iOS applications

MQTT Doc