MQTT is a lightweight protocol typically used with IoT devices that are designed to be power efficient and consume minimal bandwidth.
The protocol runs over TCP/IP and is based on a bi-directional publish-subscribe model with lossless communication.
A system architected to use MQTT will comprise two primary elements:
MQTT is a hugely flexible protocol and the client can be any endpoint that implements MQTT. In the case of IoT, the client is the connected device such as a sensor, monitor, Arduino board, etc. The device is responsible for connecting to a ‘message broker’ and exchanging data by publishing or subscribing to ‘topics’. MQTT scales to thousands of devices and devices will need to be securely provisioned.
2. The message broker
The MQTT broker, a server component that typically runs in the cloud, is responsible for connecting multiple devices and managing the publish-subscribe infrastructure over which the devices communicate. The broker is also responsible for managing device connection state and ensuring the system is resilient to devices dropping & reconnecting. When a client subscribes to a particular topic the broker is responsible for maintaining that association and delivering any data published on that topic back to the client.
Does PubNub support MQTT?
Absolutely! PubNub provides an MQTT bridge offering very low latency which avoids having to deploy a custom MQTT broker and provides simple integration with other PubNub functionality such as functions and data streaming.
Since PubNub is designed around the publish-subscribe model, it maps very nicely to MQTT:
Publish / Subscribe: These concepts are identical for both PubNub and MQTT
PubNub channels: The equivalent in MQTT is a ‘topic’.
UUID: Both PubNub and MQTT have the concept of a unique identifier assigned to each client.
Wildcards: Both PubNub and MQTT support wildcards when subscribing to channels/topics. See the docs for more detail.