Over a million developers have joined DZone.

Internet of Things - Protocols and Access Keys

DZone's Guide to

Internet of Things - Protocols and Access Keys

· IoT Zone
Free Resource

Cisco IoT makes digital transformation a reality in factories, transportation, and utilities. Learn how to start integrating with Cisco DevNet.

 I've just read this article from Mark O'Neill on the 10 concerns for the Internet of Things. Mark brings up some very interesting aspects and concerns. I'd like to comment on two of those: protocols and access keys.

His primary concern is protocol proliferation. I agree this is an issue. Mark explicitly mentions CoAP, MQTT, AMQP and XMPP. Interestingly he doesn't mention HTTP, which I have found to be heavily used by devices, especially the new generation of Raspberry Pi based systems. Many Arduino's also use HTTP.

I will admit to a strong bias. I think that MQTT is the best of these protocols for IoT devices, with CoAP a distant second.

Let's get XMPP out of the way. I love XMPP. I think its a fantastic protocol. Do I want to create XML packets on my Arduino? Er... nope. Even on 32-bit controllers, there is still the network traffic to consider: suppose I'm using a GPRS connection and I have thousands of devices deployed: minimizing network traffic is important for cost and efficiency, and XMPP was not designed for that.

AMQP is not an appropriate protocol for IoT devices and was not designed for that. It is designed for "the efficient exchange of information within and between enterprises". It was certainly not designed for lightweight, non-persistent, non-transactional systems. To that end, my own system (WSO2) will be providing efficient bridging for AMQP and MQTT to enable lightweight systems to get their data into wider enterprise contexts. I also demonstrated HTTP to MQTT bridging with the WSO2 ESB at the MQTT Interop held last week at EclipseCon.

How about CoAP vs MQTT. Firstly, CoAP is more appropriate to compare to MQTT-SN. It is UDP only, and designed to emulate a RESTful model over UDP. My biggest concern with CoAP is this: most people don't actually understand REST - they understand HTTP. If I had a dollar for every time I've come across supposedly RESTful interfaces that are really HTTP interfaces, I'd be a rich man! 
Interestingly, despite MQTT having been around for 10 years, the Google Trend shows that it has only recently hit the public notice:
However, as you can see, it has quickly overtaken CoAP. In terms of traffic, it is a clear winner: every Facebook mobile app uses MQTT to communicate with the Facebook servers.
The other area I'd like to comment on is access keys. I agree this is a big issue, and that is the reason I've been working on using OAuth2 access keys with MQTT and IoT devices. I recently gave talks about this at FOSDEM, QCon London, and EclipseCon.  The EclipseCon talk also covered a set of wider security concerns and the slides are available here. OAuth2 and OpenID Connect are important standards that have got incredible traction in a short period of time. They have evolved out of 10+ years of trying to solve the distributed, federated identity and access control problems of the Internet. 
In my presentation I strongly argued that passwords are bad for users, but worse for devices. Tokens are the correct model, and the OAuth2 token is the best available token to use at this point. There was considerable interest in the MQTT interop session on standardizing the use of OAuth2 tokens with the protocol. 
My personal prediction is that we will see MQTT and HTTP become the most-used IoT protocols, and I strongly urge (and hope) that OAuth2 tokens will become the de-facto model across both of these.

Cisco is a software company. Surprised? Don’t be. Join DevNet to explore APIs, tools, and techniques that developers are using to add collaboration, IoT, security, network priority, and more!


Published at DZone with permission of Paul Fremantle, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}