Brokers

MQTT brokers occupy a broad range from open source software to expensive appliances. The open source Mosquitto [1] is a lightweight, but powerful, broker developed in C with ACLs, with authentication plugins written in C and TLS (Transport Layer Security). Mosquitto also supports client authentication with TLS client certificates. Although you will find it can be found in most repositories, we recommend the packages from the project site.

A new candidate called Vernemq [2] was written in Erlang and supports clustering. Hivemq [3], written in Java, has proved its worth in the commercial environment: Hivemq also comes with clustering and a plugin system. Mosquitto, Vernemq, and Hivemq all support WebSockets, even if Mosquitto users have to compile it in.

Mosquitto's default configuration is ideal for experimenting. Users need to adapt it first if they want to add authentication and TLS. However, you don't need to preconfigure either topics or client. Mosquitto's command-line tools are useful for initial experiments (Listing 1). Subscribing watches all topics ( mosquitto_sub ), and publishing (mosquitto_pub) publishes a message from the second terminal that arrives at the subscriber.

01 # in the first terminal
02 mosquitto_sub -v -t '#'
03
04 # in the second terminal
05 mosquitto_pub -t linux/magazine -m "Hello world"
06
07 # with Retain Flag
08 mosquitto_pub -r -t linux/magazine -m "Hello World"

If the subscriber is simply restarted, it doesn't receive the old messages – it only receives the message if it was started before the publisher. However, if users use the retained flag in the final example from Listing 1, MQTT treats its future subscriber to the linux/magazine topic. The older message is submitted later in this case. If the subscriber remains connected, it will see the new message on this topic from now on. If the subscriber reconnects, it will receive the retained message and then all new messages.

Choosing a broker depends on your personal requirements: Is clustering support required or is a unique solution with HA proxy available? Is Java reliable on the system? Is commercial support needed? Can your own people master the necessary programming languages (C, Erlang, Java) to develop their own broker plugins?

Bridges

Not all client APIs, and thus not all devices that communicate via MQTT, have all protocol features. Microcontrollers, for example, are typically not capable of using TLS because of the meager hardware equipment.

If, however, you want to safely use such devices in the network, you should use a bridge for help. In this scenario, place MQTT clients in the vicinity of a broker, which then takes on the tasks of sending a configurable list of topics to remote brokers and receiving lists from remote brokers to distribute to local clients. Without TLS support, the clients are only exposed on the short network section to the nearest broker.

A bridge does not necessarily have to transport all topics – instead, you can define which topics it should accept and which it should send again. This design allows finely tuned configurations that don't just blurt out all data. In Figure 2, the P and S clients are capable of exchanging messages amongst themselves about both brokers, and system administrators determine which of the two brokers address the other first (keyword: firewall).

Figure 2: A bridge between two MQTT brokers.

It gets more difficult if redundancy comes into play – for example, if a second broker is to step in when the first one fails. This isn't possible in Mosquitto, but Vernemq and Hivemq are both equipped with clustering capabilities. Whether a client in a two-node cluster publishes via node A or B is irrelevant – the nodes try to act as brokers.

Sys Admin

MQTT can render useful services for system administrators in many situations. If a system administrator has started a long running shell script and wants to know sometime later whether it is still carrying out the job, the admin can simply check whether a few instructions like mosquitto_pub appear now and then in the script.

These instructions are signs of life that a smaller broker following localhost can easily receive. The trivial function

progname=${progname:=$(basename $0)}
topic="processes/${progname}"
  mqtt_opts="--quiet -h localhost -p 1883"
function mqtt() {
   # Ignore PUB errors
   mosquitto_pub ${mqtt_opts} -t "${topic}" -m "$*" || true
}

ensures that you can look for the rights with a subscribe on the broker (see Listing 2).

01 #!/bin/sh
02
03 source mqttfuncs.sh
04
05 mqtt Start
06
07 # for ... # long loop
08 mqtt "process now xyz `date`"
09 # done
10
11 mqtt "So, now it is the end"