Data Transport Protocols in the Internet of Things

Data transport is certainly one of the more critical pieces of IoT development, providing data stream support and data flow control and ensuring that messages arrive reliably. It’s a piece you’ve got to get right.

There are many different data transport protocols to choose from, from HTTP, to MQTT, to any number of proprietary protocols. So how do you decide which one is best for your product or system? Let’s take a look at the pros and cons of some of the most common protocols.

HTTP: The Big One

HTTP is, far and away, the most widely used data transport protocol by IoT developers. There’s a reason for that: it’s a ubiquitous plain-text protocol, which means there will always be support for it and plenty of products using it. But there is a downside: its heavy weight could lead to packet fragmentation, resulting in extra work for your system. As common as it is, HTTP may not be the best choice.

MQTT: Lightweight and Efficient

The Message Queuing Telemetry Transport (MQTT) protocol was released by IBM in 1999. It was designed specifically for low-power and low-resource devices with poor connectivity. Since that time, though, network infrastructures have become much more robust, and the devices we used pre-IoT have become more powerful and have better power, whether it’s battery or cable.

To date, MQTT hasn’t garnered huge attention, especially when compared to HTTP. However, with the dawn of IoT, suddenly there were a host of devices with lower power and resources, sometimes poorly connected. These are exactly the types of devices MQTT was designed to support, so it’s actually an excellent candidate for IoT development.

If MQTT has a drawback, it’s that it isn’t ubiquitous like HTTP or some other protocols. And for mobile device development, there isn’t any integrated use of push services. To get around that challenge, though, developers could implement such services themselves or, even better, use Golgi, which has push integration built in.

Proprietary Protocols: The Benefits

Like all protocols, proprietary protocols have a mix of advantages and disadvantages. The major advantage is that the protocol can be designed specifically for your use case, which is IoT. That means the design eliminates any unnecessary extras in the protocol. A good example of such an extra is the need for superfluous headers in HTTP. Eliminating these types of extras leads to more efficient data transport, particularly on constrained bandwidth networks.

Another benefit of proprietary protocols is that they can include use-specific features. For example, Golgi includes integrated push notifications for mobile clients, and it also supports multiple physical layers for IoT devices. This is a fairly new development, as until recently Golgi has been transmitted purely over IP networks – either Ethernet or WiFi. However, as we talked about in a recent blog, Ethernet or WiFi might not always be an option, and you may want to use technologies like Bluetooth, BLE, or ZigBee instead.

With that in mind, Golgi is currently restructuring its implementation to allow it to be split into two sections. This restructured implementation will see a data abstraction layer, which provides type-safe encodings/decodings of data objects for transport, and a separate transport layer. There will still be a Golgi transport layer so you can use Golgi just as you have been up until now. However, you also have the option of leveraging Golgi’s data abstraction layer while making use of a non-Golgi transport layer. This separation of responsibility means that you can use Golgi to transmit from a low-power IoT device over a technology like ZigBee to a ZigBee-to-IP gateway device, which can then transport to the Golgi cloud for routing.

There is an alternate use for this separation: instead of using Golgi as the IP bearer of transport, you could leverage Golgi’s abstraction layer and use either your own or a third party’s data transport technology. This kind of flexibility would allow you to swap out Golgi’s transport layer if you choose.

Proprietary Protocols: The One Con

If you choose a proprietary protocol, there is one issue: the provider might halt their transport services at some point in the future. This makes developers and IoT companies wary. But you can mitigate that fear with the ability to swap out that transport for another option (an option Golgi provides, as we saw in the previous paragraph). Although you might lose some functionality specific to the first transport provider, keep in mind you wouldn’t have had it if you didn’t use that provider in the first place.

Taken altogether, proprietary solutions should be excellent candidates for IoT development – especially when implemented properly. Developers can benefit from an efficient data transport system that works out of the box, and has industry-specific features such as integrated push and a choice of physical layer transports. All of these features can accelerate time to market. And to protect against any future lack of a transport service, you can take advantage of a well-defined mechanism for migrating your devices away from proprietary data transport to another data transport mechanism.

It’s absolutely essential that you weigh all the pros and cons of each before choosing a data transport protocol. But even with their disadvantages, keep in mind that MQTT and proprietary protocols offer the best solutions for IoT because they are designed for low-power, limited-resource, poorly connected environments.