Comparison between MQTT and SSE

Building a real-time web or mobile application is more challenging than building a standard service. This is because the protocol you choose to pass data from the server to the client will have a significant impact on the overall experience.

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

Today, we’ll look specifically at MQTT and SSE and see how they compare.

[[332275]]

A brief history of MQTT and SSE

MQTT, or Message Queuing Telemetry Transport, is a publish-subscribe messaging protocol that first appeared in 1999. Andy Stanford-Clark of IBM and Arlen Nipper of Eurotech released the protocol that year.

Initially, it provides support for connections between desert pipeline segments for active monitoring. This is achieved by synchronizing pipeline connections with a satellite network.

The idea is to create a lightweight machine-to-machine communication protocol that can run even on limited networks with low bandwidth and unpredictable connectivity, and on low-power devices. It also incorporates different levels of quality of service (QoS).

Since then, MQTT has become a recognized protocol for similar applications, bridging connections between devices with limited CPU power, battery constraints, and unpredictable communication instances. More recently, MQTT has become the protocol of choice for IoT solutions.

On the other hand, SSE (Server-Sent Events) came much later, in 2006. The protocol is based on server-sent DOM events, which were introduced with the Opera 9 web browser. At the time, it was an experimental technology that pushed content from the 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 the HTTP stream open and receives updates until it is eventually closed.

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

How are they different?

There are two main ways to handle data delivery. The first is called a client request, which means that the browser or app is requesting data from the server. The second method is called a server push, which is when the remote server actively pushes data to the website or application. Essentially, one involves the client and the other involves the server.

While there are only two ways to do data transfer, there are several ways to achieve this process:

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

Polling is done on the client side and occurs when an application or website periodically requests data from the server.

WebSockets is a persistent connection between a client and a server, used primarily as a communication protocol.

Finally, SSE (Server-Sent Events) is an asynchronous mechanism that pushes data to the client over an active connection. The server can also send data when a new block of data or an update is available. The connection may remain open, but this does not necessarily mean that data is being transferred.

Just from these definitions, you can see how different client-server processes are. This also means that they each have advantages and disadvantages, which makes them very suitable for use in some situations and not so practical in others.

Overview of MQTT functions

The MQTT protocol relies on a web-like system consisting of 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 client handles the work. Instead, the processing power and communication are primarily handled by the broker.

Therefore, MQTT allows developers to build a hierarchy of communication channels. Visually, this looks like a tree branch. The publisher or server first sends new data to the broker, along with passing control instructions.

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

All data published and sent to the broker (and data received) is encoded in a binary protocol. Therefore, the message must be interpreted before the data contents can be used.

Still, MQTT only distributes security credentials via plain text, so it is not completely secure and does not provide adequate authentication or security for most applications. Developers can work around this by implementing the SSL framework, which protects any transmitted data through encryption.

MQTT: Pros and Cons

advantage:

• MQTT is an incredibly lightweight protocol designed to connect the most resource-constrained 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 continuously collect and report aggregate data.
• MQTT is bidirectional.

shortcoming:

• Due to the nature of centralized brokers, developers may encounter scaling limitations when using MQTT, with the local broker hub limiting the amount of scaling it can support.
• Ironically, MQTT typically runs on top of a TCP/IP network stack that is designed for devices with larger memory and processing power. As a result, wake-up and communication times can be extended, which can affect long-term battery consumption.

SSE Overview

An SSE connection is usually started on the client side of the link between a client-server configuration. The client starts and opens the connection by creating a new EventSource object in JavaScript. It sends the relevant URL via an HTTP request.

Once the connection is established, the client will expect and look for a stream of event messages. The HTTP request remains open as long as data is being transferred. After a period of time, when the client deems the transfer stale, the connection is closed. The client can also simply close the connection if the initial request was cancelled.

As you can see, SSE is simpler than MQTT and does not involve a broker.

SSE: Pros and Cons

advantage:

• Data is synchronized over the simple and widely used HTTP protocol rather than proprietary protocols.
• Includes built-in support for reestablishing connections and event ID functionality.
• Useful for applications and services that utilize one-way communication.

shortcoming:

• Unfortunately, SSE only supports UTF-8 encoding and not binary data.
• Strict limits on the maximum number of open connections can make things difficult, with each browser setting a limit.
• SSE is one-way.

MQTT and SSE

The most important thing to consider when comparing MQTT and SSE is their connection capabilities. For example, SSE is one-way and is designed specifically for services or applications that need to extract information from a server. On the other hand, MQTT is a robust two-way communication option that facilitates data transfer back and forth between a server and a client.

This means that SSE is well suited for applications that store information on the server and push it to the client, such as a real-time stock application or a news-based service. Essentially, there is no need to pass data in the opposite direction from the client.

This also explains why developers prefer MQTT in IoT applications, sensors and devices, among other advantages. Because the information has a bidirectional structure, it can be transmitted in both directions.

SSE Open Source Solutions

Now that you know about SSE, you may be ready to look for open source SSE software that can help you get started. One example is Gossed. It allows you to push the standard output of any program to the browser as server-sent events.

There is also SSE Channel, which broadcasts messages to all connected clients. In addition, this tool automatically maintains the history. Another feature is the ability to send automatic "keep-alive" packets to clients as needed.

MQTT open source solution

There are also open source MQTT options. Eclipse Mosquitto is lightweight and works well with all devices. It can handle the messaging needs of a wide range of devices from smartphones to connected sensors. There is also a test server that allows you to see the functionality of the client using several MQTT-related scenarios.

HiveMQ is another MQTT broker that became an open source software in April 2019. It is specifically designed to process information related to IoT devices. The tool provides a real-time monitoring interface, as well as advanced end-to-end MQTT analytics for troubleshooting.

Difficulties in implementation

At first, implementing an in-house solution for MQTT or SSE might sound feasible. However, there are common issues to overcome, such as those related to message ordering and guaranteed delivery. You must also keep security in mind, including access control and configuration. In 2019, security researchers detailed how at least 3,200 homes with smart home technology could be vulnerable to hackers due to insecure misconfigurations of MQTT.

Add to that other necessities, like creating developer documentation, and it’s easy to see why you might eventually decide that using an in-house solution is too labor-intensive and cost-intensive from both an operations and engineering perspective. You’ll likely come to that conclusion as your number of end users grows. All of the challenges listed here are likely to become more problematic as you scale up your efforts.

Although, as mentioned earlier, both MQTT and SSE have open source options, the smarter choice is to invest in a commercial real-time messaging platform. It can help you achieve high performance and reliability even as you scale up.