Protocols

IoT Hub vs Event Hub–A quick comparison

December 11, 2016 Azure, Cloud Computing, Cloud to Device, Communication Protocols, Connectivity, Contrained Networks/Devices, Data Hubs, Device Shadow, Device to Cloud, Device Twin, Emerging Technologies, Event Hubs, HTTP2, Identity of Things (IDoT), Intelligent Cloud, Internet of Things, Interoperability, IoT, IoT Hub, IoT Privacy, IoT Security, Messaging, Microsoft, Performance, Protocols, Reliability, Scalability, Tech-Trends No comments

With this article I am trying to provide you a birds eye view comparison of IoT Hub and Azure Event Hub, so that some of you may stop feeling that there is nothing new in IoT Hub.

For the interest of this article, I put together a table with side-by-side comparison of some important features/desired features from an IoT Hub like platform.

Feature IoT Hub Event Hub
Communication Supports both device-to-cloud and cloud-to-device bidirectional communication Supports only device-to-cloud communication
State Management Can maintain device state using Device Twins and query them whenever needed. Not Supported
Protocol Support AMQP 1.1, AMQP over Web Sockets, MQTT 3.2, MQTT over Web Sockets, HTTP 1.1, Web Sockets. AMQP 1.1, AMQP over Web Sockets, HTTP 11 , Web Sockets only
Protocol Extensions Provides IoT protocol gateway a customizable implementation for industrial protocol channelling. Not Supported
Security Provides identity to each device and easily revocable through IoT Hub Device Management portal. Shared access policies with limited revocation capabilities are provided.
Monitoring/ Operations Provides a rich set of features through Device Management capability. Includes individually enable/disable or provision new device. Change security keys as needed. View/identify individual device problems easily. Does not provide individual performance metrics. Can provide only a high level aggregated metrics only.
Scalability Scalable to thousands/millions of simultaneous devices Limited number of simultaneous connections up to 5000 connections per Azure Service Bus Quotas. Event Hub provides a capability to partition your message to channel it in to associated Service Bus quotas.
SDK Support/ Developer Support Provides very good Integration SDK and developer support. Both Azure IoT  Device SDK and IoT Gateway SDK are the most essential kits provided for almost all devices/OS platforms. It also support all the latest programming languages such as C#, Node.js, Java and Python.
Also provides  direct MQTT, AMQP and REST based HTTP APIs.
Very detail oriented documentation provided.
.NET, Java and C apart from protocols such as AMQP, HTTP API interfaces.
Files/Images Upload Capability Supports IoT devices/solutions to upload files/images/snapshots to cloud and define a workflow for processing them. Not Available
Message Routing Very decent message routing capability is available out of the box. Up to 10 end points can be defined and Advanced Rules can be defined on how routing should occur. Requires additional programming and hosting to support as per the need.

From this comparison table, you can analyse that IoTHub is the right candidate for your IoT solution needs, as Event Hub lacking certain capabilities that are essential for an IoT Ingestion point. If you are only requiring to send messages to cloud and doesn’t require any fancy stuff as IoTHub provides, you can choose Event Hub.

Remember with more power comes more responsibility, that’s what IotHub intend to provide to you.

Hope this overview was helpful. Please feel free to comment or initiate a discussion any time. Please share your feedbacks on this article as well.

Introduction to HTTP/2

May 23, 2015 .NET, Communication, CSS, HTML, HTTP, HTTP2, IIS, KnowledgeBase, Microsoft, Protocols, Visual Studio 2015, VisualStudio, VS2015, Web, Windows, Windows 10 No comments

The reason I got started with topic is that, there  were some buzz around Visual Studio 2015 RC support for HTTP/2 and Windows 8 – IIS support for HTTP/2. I was curious to learn further about the HTTP/2 and sharing my findings in this article.

About HTTP/2.

HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardized in RFC 2068 in 1997.

  • HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. 
  • It also introduces unsolicited push of representations from servers to clients.
  • This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. 
  • HTTP’s existing semantics remain unchanged.

HTTP/2 allows the server to “push” content, that is, to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle.

Quoting from MSDN:

HTTP/2 is a new version of the HTTP protocol that provides much better connection utilization (fewer round-trips between client and server), resulting in lower latency web page loading for users.  Web pages (as opposed to services) benefit the most from HTTP/2, since the protocol optimizes for multiple artifacts being requested as part of a single experience.

The browser and the web server (IIS on Windows) do all the work. You don’t have to do any heavy-lifting for your users.

[Source: MSDN]

HTTP v1.1 vs HTTPv2

  • HTTP/2 leaves most of HTTP 1.1’s high level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.

At a high level, HTTP/2:

  • is binary, instead of textual  ( the reason being is – “Binary protocols are more efficient to parse, more compact “on the wire”, and most importantly, they are much less error-prone, compared to textual protocols like HTTP/1.x, because they often have a number of affordances to “help” with things like whitespace handling, capitalization, line endings, blank links and so on. “)
  • is fully multiplexed, instead of ordered and blocking
  • can therefore use one connection for parallelism
  • uses header compression to reduce overhead
  • allows servers to “push” responses proactively into client caches

Taking help of an image visualization

http-timing-diagram

Major Milestones:

  • December 2014: The HTTP Working Group presented HTTP/2 to IESG for consideration as a Proposed Standard.
  • Feb 17, 2015: IESG approved it to publish as Proposed Standard
  • May 2015: The HTTP/2 specification was published as RFC 7540

Browser Support:

  • Chrome supports HTTP/2 by default.  (from version 41)
  • Google Chrome Canary supports HTTP/2 by default. (from version 43)
  • Chrome for iOS supports HTTP/2 by default.  (from version 41)
  • Firefox supports HTTP/2 which has been enabled by default since version 34.
  • Internet Explorer supports HTTP/2 in version 11, but only for Windows 10 beta, and is enabled by default. Currently only HTTP/2 over TLS is implemented.
  • Opera supports HTTP/2 by default (from v 28 onwards)

Reference Links: