With the explosion of IOT (Internet of things), there are now more technologies we can use to build systems. In reality, we’ve been doing IOT for years. We’ve been networking devices for a long time. We’ve been collecting data from remote nodes. This is nothing new, but what the IOT movement brings to the table is technologies that are much lower cost, and more standardized. Two of these technologies are MQTT and CoAP. Both very interesting, and very useful. Recently, I helped a system manufacturer think through the architecture of a system with the following requirements:
- They plan to sell a relatively small number (200-1000) of fairly expensive machines ($5,000-$10,000). The point here is we are not dealing with millions of $10 nodes, which is really the vision of IOT.
- There might be as many as a dozen machines installed in each location.
- Users of these machines need to monitor them remotely. The manufacturer would also like to monitor them for diagnostics and customer support.
- The machines can be connected to the Internet at the install sites.
- These machines are installed at various locations where the manufacturer doesn’t have much control over the network (firewall, filtering, which ports are blocked, etc).
- The machines don’t need to talk to each other.
- It should be relatively difficult to hack into a machine and mess up what it is doing.
- Data will be mostly going from machines to the cloud.
There are several ways to address these requirements, but one of the simplest today is for each machine to talk to a server in the cloud, and then users monitor and control the machines through a web application running in the cloud. The web application can be designed to be viewed on both personal computers and mobile devices.
So the question is which protocol do we use to communicate from the installed machines to the cloud? In this case, we really do not need a lot of efficiency, as the number of nodes is relatively small. Bandwidth requirements are not really a huge concern because a) the number of nodes is relatively small, and b) we can use the existing broadband infrastructure at the install sites. While it might be interesting to use one of the new protocols like MQTT or CoAP, we need to carefully consider them in the context of requirement #5 — we don’t have control over what ports are blocked or what type of filtering/proxying happens at the install site. Support costs can run very high debugging networking problems at remote locations. Because MQTT and CoAP typically use non-standard ports, they are less attractive for this application. Even if we did run MQTT or CoAP over port 80, the install site might have internet filters or proxies that would reject non HTTP data. So this puts us back to HTTP, perhaps with a REST implementation. As it turns out, this is not a bad way to go. Even though HTTP is old, it is still a perfectly valid protocol for this application. Some of the advantages include:
- HTTP is the most compatible with existing network infrastructure, and you are pretty much guaranteed HTTP will work. If a web browser works, then machines in this scenario should be able to send data to the cloud.
- Stateless HTTP/REST will traverse firewalls and NAT systems easily. Again, web browsers work.
- Because the Machines initiate the connection to the server (users are not connecting directly to a browser on the machine), the machines are much easier to secure. Thy don’t even need any open ports. Most of the security effort in this system only needs to be focused in one place (cloud server).
- HTTP provides well understood authentication and encryption mechanisms.
There are other applications where MQTT or CoAP might make more sense.
- In a system connected via cellular modems where data is very expensive, you might want to consider CoAP, because it can use UDP which eliminates the overhead of TCP/IP, which is significant (both MQTT and HTTP require TCP/IP). Especially if you have 1000’s of nodes, and are trying to keep the monthly usage of each one under 5MB.
- If the various machines need to talk to each other, then MQTT would be a good choice.
While I’d like to use MQTT or CoAP, in this application I’m going to recommend they stick with HTTP(S). Even though MQTT might be more convenient to work with, the support costs of debugging network issues at install sites will probably swamp any advantages during development. This project can benefit from the host of Wifi enabled microcontroller systems, low cost embedded Linux technologies, or cloud technologies aimed at IOT systems. All of these support HTTP just fine.