by Exosite, on March 10, 2016
In the last Embedded IoT Protocols Guide Part I blog, we briefly discussed the old standards of application protocols as explained by Exosite’s Application Engineer, Patrick Barrett. This blog segment will continue the discussion of embedded IoT protocols by summarizing the benefits and drawbacks of using HTTP.
THE WELL-UNDERSTOOD AND WELL-SUPPORTED POSTER CHILD
HTTP is the poster child of well-understood and well-supported protocols and is the application-layer protocol that runs almost the entirety of the web. HTTP uses a client-server model to describe how its requests are made. This model works well for traditional web browsing because there is a user directing the browser as to when it should make requests for certain resources. As such, it will be the lowest common denominator in supported protocols for the foreseeable future.
However, it also has its limitations and challenges when it comes to IoT connected deployment use cases. When IoT connected products are involved, there is not always a person or user to guide the actions, and the device must decide when it should request updates to a resource from the server on its own. That means that once a connected device decides to request an update and the server returns a response, it must repeat the request immediately since it has no other way of knowing if a server-side resource has changed.
Ideally, the server would instead notify the device when a resource changed. Unfortunately, the architecture of the Internet prevents this when using HTTP. Servers are almost always unable to send arbitrary messages to clients without first receiving a request from the client due to the security issues that might arise. So, HTTP is left using a model that is less than ideal because of the amount of data overhead it creates. With a large number of devices operating in this manner, network latency and congestion can quickly become an issue. This problem is exacerbated by the fact that HTTP is a verbose, text-based protocol that adds a significant amount of overhead in each request.
Also, as a text-based protocol, HTTP is actually very hard for an embedded system to parse correctly. There are problems with encoding, because users must scan for special characters that define the divisions between certain parts of the message. It takes time and excess memory to re-encode the different parts of the messages, and there are also no defined maximums for the different components of the messages. This increases the complexity of implementations and can cause users of a given library headaches depending on how that particular library decides to deal with the problem.
Although these problems seemingly suggest HTTP is not an ideal protocol choice, they can sometimes be accommodated and in some cases, depending on external factors, may be a viable option. For a full breakdown of HTTP and other IoT protocols to consider when building your IoT business strategy, download the full white paper.
