Andy Piper, project lead of the Eclipse Paho project, which provides clients for the MQTT (Message Queuing Telemetry Transport) protocol in a variety of languages.
MQTT originated in the industrial sector in the late 1990s – the first implementation was in 1999, to be precise. Companies wanting to monitor industrial and mechanical systems (think pipelines, oil pressures, water levels etc) needed a very lightweight technology, suitable for running on constrained systems and devices.
MQTT is a very light, publish/subscribe, asynchronous messaging protocol, ideal for the Internet of Things, mobile, and sensor networks. It started out at IBM, but in the past few years it has gone open source, with a standard being agreed at OASIS – so it is much more widespread than just being an IBM thing these days.
What kinds of Quality of Service does MQTT provide?
- QoS 0 is essentially "fire and forget" – the message may arrive, it may not, but the data probably isn't critical anyway (in most cases the message will be delivered somewhere, of course, but there's no double-check to make sure that happens).
- QoS 1 makes a bit more of an effort to ensure a message arrives: if an acknowledgement of receipt isn't received from the broker, we'll re-send the message again but with a duplicate header byte set, just in case.
- QoS 2 is closer to the two-phase commit world and tries to offer once and once-only delivery, for data where you want to be sure the broker did receive the message for onward delivery.
Facebook ... blogged about how they use MQTT in their Messenger and mobile apps,
MQ Telemetry Transport (MQTT) V3.1 Protocol Specification @ IBM
- The publish/subscribe message pattern to provide one-to-many message distribution and decoupling of applications
- A messaging transport that is agnostic to the content of the payload
- The use of TCP/IP to provide basic network connectivity
