MQTT: An Overview

Edit online

MQTT (Message Queuing Telemetry Transport), is a publish/subscribe, simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth by IBM / Eurotech in 1999. The simplicity and low overhead of the protocol make it ideal for the emerging "machine-to-machine" (M2M) or "Internet of Things" (IoT) world of connected devices, and for mobile applications where bandwidth and battery power are at a premium. The protocol is openly published with a royalty-free license, and a variety of client libraries have been developed especially on popular embedded hardware platforms such as arduino/netduino, mbed and Nanode.

In addition to Universal Messaging's own protocol, NSP and NHP interfaces are capable of also accepting MQTT connections over TCP sockets, while NSPS and NHPS interfaces can accept MQTT connections over SSL/TLS for client implementations that support it.

Connecting

In order to connect to a Universal Messaging server using MQTT, your application needs to use a tcp://host:port URL (NSP and NHP interfaces) or ssl://host:port URL (NSPS and NHPS interfaces). MQTT connections are treated in the same way as any other connections by the Universal Messaging realm. If the username is present, the Universal Messaging subject is username@hostname, otherwise the subject is anonymous@hostname.

Figure 1. Figure 1: Connection List with an MQTT connection

This way you can define realm and channel or queue ACLs as you would for any Universal Messaging connection. For example using the IBM WMQTT sample application without a username/password to connect to tcp://localhost:1883 will result in a Universal Messaging subject of anonymous@localhost.

Publishing

MQTT applications can publish events to channels. If the specified channels do not already exist in the Universal Messaging realm, they will be automatically created by the server as MIXED type with a JMS engine.

These channels are regular Universal Messaging channels but all events published from MQTT will be persisted to disk. While it is possible to create other channel types using the Administration API / Enterprise Manager, the mixed type with JMS engine is the recommended combination.

Note: The set of permissible characters you can use to name a channel is the same as for standard Universal Messaging channels. This character set is described in the section Creating Channels in the Enterprise Manager section of the Administration Guide. Therefore it is possible that a channel name could be valid according to MQTT naming rules but invalid, and therefore would be rejected, according to Universal Messaging naming rules.

Events published via MQTT only contain a byte[] payload and are tagged MQTT. They are fully interoperable with any Universal Messaging subscriber on any client platform supported and can be snooped using the Universal Messaging Enterprise Manager:

Figure 2. Figure 2: Snooping an MQTT message

All messages published from MQTT are flagged as JMS BytesMessage objects.

Note: Publishing to queues via MQTT is not supported.

Subscribing

MQTT applications can subscribe to channels. If the specified channels do not already exist in the Universal Messaging realm, they will be automatically created by the server as MIXED type with a JMS engine.

These channels are regular Universal Messaging channels with all messages being persistent, regardless of whether they are published by MQTT or Universal Messaging applications.

Note: Subscribing to queues via MQTT is not supported.

Quality of Service

Universal Messaging supports QOS levels 0 and 1 as defined by the MQTT standard. This is driven by the MQTT client connection and describes the effort the server and client will make to ensure that a message is received, as follows:

  1. QOS 0 (At most once delivery): The Universal Messaging realm will deliver the message once with no confirmation
  2. QOS 1 (At least once delivery): The Universal Messaging realm will deliver the message at least once, with confirmation required.
Note: Universal Messaging does not support QOS level 2 (Exactly once delivery). Connections requesting QoS level 2 will be downgraded to QoS level 1 at connection time, as allowed by the MQTT specification.

Will

Universal Messaging supports connections with Will settings, which indicate messages that need to be published automatically if the MQTT application disconnects unexpectedly.