Why HTTP won’t work for IoT

Why HTTP won’t work for IoT

Feature articles |
By eeNews Europe

HTTP is for the Old World Internet. The New World Internet (the IoT) is made up of unseen devices that require very little interaction. They consume very little power and frequently have poor network connectivity. HTTP is too heavy to be a good fit for these devices. An HTTP request requires a minimum of nine TCP packets, even more when you consider packet loss from poor connectivity, and plain text headers can get very verbose. And even with all this overhead HTTP doesn’t guarantee message delivery!

The HTTP overhead also adds to IoT operating expenses. Current costs of wireless connectivity are exorbitant. My cellphone provider charges $10/GB, and I’ve seen as much as $1/MB! This is to say nothing of the wireless spectrum shortage. Bandwidth conservation is especially important with enterprise customers that often have hundreds of thousands or millions of devices deployed.

Fortunately there are suitable alternatives to HTTP for communicating with IoT devices.

IoT network traffic falls into two categories: telemetry and telecommand. Telemetry is the act of gathering telemetrics, or sending data over long distances. Usually telemetry involves sending data from many dumb sensors to a smart hub of some sort. The dual of telemetry is telecommand, or the act of sending commands across a network.

Most telemetry protocols are modelled as publish/subscribe architecture. Sensors connect to a broker and periodically publish their readings to a topic. A central cluster of servers (the cloud) will then subscribe to the topic and process sensor readings in real-time. A typical enterprise arrangement will have thousands or millions of sensors sending telemetrics to a handful of servers that split up the task of processing the data.

MQTT (Message Queue Telemetry Transport) is the leading telemetry protocol. It typically runs on top of TCP, adding only a 2-byte header. Usually clients are expected to have poor network connectivity — either a fault of the wireless technology or because the device sleeps as a means of saving power. MQTT solves this problem by having the recipient acknowledge that it processed a message. This is called Quality of Service (QoS) and allows clients to opt out of this behaviour by using a lower QoS level if the normal guarantees of TCP are suitable.

The protocol allows the subscriber to encode information into the topic. Sensors will often publish to a topic such as "device123/temp" or "device456/temp"; consumers can use a wildcard and subscribe to "+/temp" to receive messages from all devices, yet still retain the device ID information separate from the message payload.

MQTT has a couple variants. First, you can run MQTT over SSL/TLS to create a secure connection that’s safe against man-in-the-middle attacks. Second, MQTT-SN (MQTT for Sensor Networks) is made to run over a non-TCP/IP stack. This could mean using UDP, SMS, or a variety of packet-based wireless protocols. I believe MQTT-SN is promising, as recent results may indicate problems in certain TCP-based protocols over cellular networks.

MQTT provides a lot of functionality for such a low overhead. It’s oriented toward devices with low bandwidth requirements. However, I think that the debugging experience is sacrificed. My main complaint is that there isn’t an easy way to indicate to the client that it did something wrong. When topic security is enforced, the broker can acknowledge a SUBSCRIBE request, but it can’t actively deny one (i.e., lack of permission). The only way some MQTT requests can be denied is by the broker not responding with an acknowlegement.

There are alternatives to MQTT: STOMP, XMPP, and ActiveMQ all are sometimes used for telemetry. They all meet M2M requirements to varying degrees, but I think MQTT and variants are superior for low-power devices and are most likely to become ubiquitous.

So, don’t use HTTP for the IoT. HTTP was created for the "command ->" response required by web pages and applications. IoT has different requirements. Wireless bandwidth is placed at a premium. Connectivity can’t be expected to be available all the time. Most importantly, architecture is much cleaner and easier to understand when publishers and subscribers don’t have to be simultaneously available.


Tim Kellogg is a software engineer working on the platform, protocols, and cloud services at 2lemetry, a provider of IoT services.

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles