We continue to have discussions with friends and colleagues around the idea of defining a protocol for the Internet of Things. Many people are working on a lot of different approaches to this, and I think there’s validity in a lot of the effort there.
We spoke to this point a bit last week at Hardware Innovation Workshop–we don’t believe there will be one single protocol for the Internet of Things. Here’s why.
We’ll start high-level, at the APIs of the world. Let’s take Github and Twitter, as examples. Here’s a look at the documentation categories for Github’s API:
Here we have API concepts such as “activity”, “gists”, “pull requests”, “repositories”, and “users”, to name a few. These are all entities that relate to what Github is about. You can access users, and repositories, and the like by following their API. It’s fast, easy to understand, and relatively simple to implement against.
Here’s what Twitter’s API looks like:
Here Twitter describes its major entities: “tweets”, “users”, “entities”, and “places”. These are obviously specific to Twitter, and explain very clearly the taxonomy of the Twitter ecosystem. But you’ll notice there is no concept of a “pull request” in Twitter’s API, nor is there the concept of a “tweet” in the Github API.
What would an API look like that was able to work for both Twitter and Github? Would we just union-join the two entity lists and have a mega list of everything? Maybe. But Github and Twitter both have a concept of “users.” Uhoh. Now we have two definitions of “users”, from two different companies, and most likely these are used in slightly different ways. Does the user entity in Twitter have the same attribute mapping as the user entity in Github? If not, why not? Do we need to union-join every attribute in overlapping entities across these two platforms?
This becomes a crazy mess the deeper you go. I worked for a over a year and a half on this very problem, and believe me, it is extremely difficult to come up with a single complete description for even a single entity such as “user”.
Let’s move down the stack a bit. Consider SMTP, FTP, and DNS. These are Layer 7 protocols in the OSI model. For those that aren’t familiar with these protocols, SMTP is for sending email from one server to another. When you send an email to someone else, it is most likely transmitted through one or more SMTP servers. SMTP defines how to deliver mail to the recipient–what is called the message transport–and what to do if the message is undeliverable, how to deal with allowing messages to be received, etc.
FTP defines how to transfer files across networks–and is also a transport protocol. What the file format is that’s being sent is irrelevant, just as what the message contents are of an email message is irrelevant to SMTP.
But have you ever tried to send a 100MB file attachment through email before? It’ll likely fail, because SMTP (and its underlying server infrastructure) is not designed for that method of usage. Email delivery would grind to a halt if arbitrary-sized messages were allowed in email messages, and email user satisfaction would suffer as a result.
Likewise, if you had to log into an FTP server every time you wanted to get a message sent to you from a friend, you’d soon tire of the constant logging in. Whenever you wanted to send a message, you’d have to look up the IP address of the person you wanted to email, log into their FTP server, and leave a message. Though you probably could use FTP as a message transport, it’s kludgy at best.
These protocols were defined for specific use-cases, and they handle them well. It’s a testament to SMTP that email is still as popular as it is today–even with issues around spam and viruses as attachments. It’s been incredibly resilient for being a 31 year old protocol.
Now let’s move down even further. Even lower in the stack are protocols like TCP and UDP–both of which are on top of another even-lower protocol called IP. IP is famous for its IP addresses, with which almost everyone is familiar. TCP and UDP will both initiate packets of data being sent from one server to another. TCP ensures error correction, delivery validation, and packets of data being received in order. UDP does not, and is usually faster but can lose data in transmission. Web browsers, mail clients, and the like use TCP, whereas many games, video chat, and other time-sensitive applications use UDP. IP handles how to address, route, format, and receive packets of data.
Well, because if we start talking about a single protocol for the Internet of Things, we need to clarify first what level we’re talking here. Are we talking low levels like TCP and IP? Upper levels like HTTP? Even higher levels like entity taxonomy?
For the Internet of Things, much work has already been done in most of these layers. At the lower levels, we have protocols such as 802.15.4, 6LoWPAN, RPL, Zigbee, and others. At the higher levels there are protocols such as MQTT and CoAP.
First and foremost, Pinoccio strives to use open, industry standard protocols. It’s how the original Internet emerged, and we think it’ll happen again this way. So whenever there’s a group that is pushing a protocol, and it’s not IETF-standardized (or is at least in an IETF or OASIS working-group to get finalized), we shy away from it.
At the current time, we are using 802.15.4 for the physical and medium (lowest) protocol, a BSD-style licensed middle protocol called Lightweight Mesh from Atmel, and MQTT for the higher protocol. Lightweight Mesh is not IETF-standardized, but the source is available, and it’s extremely lightweight and thus simple to understand how it works. We’d like to see some maturity happen in 6LoWPAN and RPL, and we’ll likely move to that instead once more work is done in the IETF working group.
As far as what happens in the taxonomy level–well, we think that’s up to you as the implementor. What do you put in the payload of a web page? What about an email message? It’s up to you! There is no standard for that.
To close, Pinoccio very much embraces existing protocols for building the Internet of Things. We don’t want the future of connected devices to be a smattering of walled gardens, but rather an open platform where the best applications and projects are built on top of existing, well-understood systems. We trust that having strong, well-defined lower-layer protocols will allow for a flourishing of amazing things to happen in the highest levels.
Filed under Building the Internet of Things