MQTT vs SSE: A Comparison

Building a real-time web or mobile application is a bit more challenging than building a standard service. That’s because the protocol you choose to deliver data from the server to the client— and back—will have a significant impact on the overall experience.

When you need data to flow from the server to the client quickly, a persistent connection is necessary. You do this by using long polling, WebSockets, Server-Sent Events (SSE) or HTTP2 Push.

Today, we’re going to take a look at MQTT and SSE, specifically, to see how they compare.

A Brief History of MQTT and SSE

MQTT, or Message Queuing Telemetry Transport, is a publish-subscribe messaging protocol that first appeared back in 1999. Two well-known developers—Andy Stanford-Clark of IBM and Arlen Nipper of Eurotech—published the protocol that year.

Initially, it powered the connection between sections of a desert pipeline for active monitoring. This was achieved by syncing the pipeline connection with a network of satellites.

The idea was to create a lightweight machine-to-machine communication protocol that worked even on limited networks with low bandwidth, unpredictable connectivity and also on low-power devices. It also incorporated varying levels of Quality of Service (QoS).

MQTT has since become the accepted protocol for similar applications, bridging connections between devices with limited CPU power, battery restrictions and unpredictable communication instances. More recently, MQTT has become a go-to protocol for IoT solutions.

SSE or Server-Sent Events, on the other hand, appeared much later, in 2006. The protocol is based on something called Server-Sent DOM Events, which was introduced in the Opera 9 web browser. At the time, it was an experimental technology meant to push content from a server to the client—or web browser—only when new events or updates occurred.

First, the client establishes a connection using the EventSource interface. The JavaScript-based API keeps an HTTP stream open and receiving updates until it is eventually closed.

Here's an example of a new EventSource object set up to receive events from a server:

How Are They Different?

There are two primary ways to handle data delivery. The first is called a client pull, and it means a browser or app is requesting data from a server. The second method is called server push, and it’s when a remote server is proactively pushing data to a website or app. Essentially, one involves the client-side, and the other involves the server.

While there are only two methods for data delivery, there are a few ways the process can be achieved:

• Long or short polling (client pull)
• WebSockets (server push)
• Server-Sent Events (server push)

Polling is done client-side and happens when an app or website regularly requests data from the server.

WebSockets are persistent connections between the client and server, mainly used as a communications protocol.

Finally, SSE, or Server-Sent Events, is an asynchronous mechanism that pushes data to the client over an active connection. The server may also send data when a new chunk or update is available. A connection may remain open, but that doesn’t necessarily mean data is being transmitted.

From these definitions alone, you can see how different the client-server processes are. That also means they each have pros and cons, which make them ideal for use during certain situations and not as practical during others.

An Overview of MQTT in Action

The MQTT protocol relies on a network-like system, including a server, one or more clients and a broker. The broker is the MQTT server, and the connected devices are the clients. Neither the publisher nor the clients handle the legwork. Instead, the processing power and communications are mainly handled by the broker.

For this reason, MQTT allows developers to establish a communication-channel hierarchy. Visually, this resembles a tree branch. The publisher or server sends new data to the broker first, along with a delivery control note.

The broker then facilitates the exchange of information to the clients on the other end. High-level clients may receive every message or update from the publisher, while low-level clients only receive messages relating to their basic-level.

All data published and sent to the broker — and received — is encoded with a binary protocol. As a result, the message must be interpreted before the data contents have any use.

Despite this, MQTT only distributes security credentials via plain text, so it’s not entirely secure and does not provide ample authentication or security for most applications. Developers can solve this by implementing the SSL framework, which protects any transmitted data through encryption.

MQTT: Pros and Cons

Pros

• MQTT is an incredibly lightweight protocol, designed to connect even the most resource-constrained of devices.
• It has multiple layers of Quality of Service (QoS) built-in.
• Most cloud OT vendors and providers already support MQTT, making it ideal for IoT solutions where sensors are constantly collecting and reporting aggregate data.
• MQTT is bi-directional.

Cons

• Because of the nature of centralized brokers, developers may encounter scaling restrictions when using MQTT—the local broker hub limits scale by how much it can support.
• Ironically, MQTT often runs on top of the TCP/IP networking stack, which was designed for devices with more memory and processing power. Wake-up and communication times may be prolonged as a result, which can affect long-term battery consumption.

An Overview of SSE in Action

An SSE connection generally begins on the client-side of a link between client-server configurations. The client initiates and opens the connection by creating a new EventSource object in JavaScript. It sends a relevant URL via an HTTP request.

Once a connection has been established, the client expects and looks for a stream of event messages. The HTTP request remains open for as long as data is being transmitted. After a period, the connection is closed when the client considers the transmission stale. The connection can also be closed by the client directly if the initial request is canceled.

As you can see, SSE is more straightforward than MQTT, and there are no brokers involved.

SSE: Pros and Cons

Pros

• Data syncs via the simple and widely used HTTP protocol instead of a proprietary one.
• Includes built-in support for re-establishing a connection and event-ID functions.
• Remarkably useful for apps and services that utilize one-way communication.

Cons

• Unfortunately, SSE is exclusive to UTF-8 encoding and does not support binary data.
• Strict limitations on the maximum number of open connections can make things difficult — limits are set per browser.
• SSE is mono-directional.

MQTT vs. SSE

The most important thing to consider when comparing MQTT and SSE is their connection capabilities. SSE, for example, is mono-directional and specifically designed for services or applications that need to pull information from a server. MQTT, on the other hand, is a robust, bi-directional communication option that can facilitate data transfers back and forth between the server and client(s).

What this means is that SSE would be ideal for applications like real-time stock apps or news-based services where information is stored on the server and pushed to the client. Inherently, there’s no need for data to pass from the client in the opposite direction.

That also explains why developers prefer MQTT for IoT applications, sensors and devices—among its other traits, of course. Information can be passed both ways, due to its bi-directional structure.

SSE Open Source Solutions

After learning about SSE, you might be ready to look for open source SSE software that helps you get started. Gossed is one example. It allows you to push any program's standard output to browsers as server-sent events.

There's also SSE Channel, which enables broadcasting messages to all connected clients.  Plus, this tool automatically maintains a history. Another one of its features is the ability to send automatic "keep-alive" packets to clients as needed.

MQTT Open Source Solutions

There are open source MQTT options to check out, too. Eclipse Mosquitto is lightweight and suitable for all devices. It can handle messaging needs for devices ranging from smartphones to connected sensors. There's also a test server that lets you see the functionality of your clients using several MQTT-related scenarios.

HiveMQ is another MQTT broker, and it became an open-source in April 2019. It's specifically for handling information associated with IoT devices. This tool provides a real-time monitoring interface, plus advanced end-to-end MQTT analytics for troubleshooting purposes.

Difficulties in Implementation

Implementing an in-house solution for MQTT or SSE may sound feasible at first. But, there are common issues to overcome, such as those associated with message ordering and guaranteed delivery. You also must keep security in mind, both concerning access control and configuration. In 2018, security researchers detailed how at least 3,200 homes with smart home technology were potentially vulnerable to hacking due to an insecure MQTT misconfiguration.

Add to these things other necessities like creating developer documents, and it's easy to see why you may ultimately determine that moving forward with an in-house solution is too labor and cost-intensive from an operational and engineering standpoint. You're especially likely to reach that conclusion as the number of end-users grows. All the challenges outlined here may become more problematic while ramping up your efforts.

Although, as the previous sections show, there are open source options for both MQTT and SSE, the smarter choice is to invest in a commercially available real-time messaging platform. It could help you enjoy consistently high levels of performance and reliability, even as you scale up.

This post was originally published at ably.io.