IoT Hub Messaging

In this step, we’ll learn about IoT Hub messaging.

We’ll take a look at:

• How Azure IoT Hub manages messages
• How device-to-cloud and cloud-to-device messaging works
• How to manage the messaging life cycle using Azure IoT Hub.

As we noted in the previous topic, IoT Hub provides the following messaging primitives to communicate with a device:

• Device-to-cloud from a device to a back-end app.
• Cloud-to-device from a back-end app (service or cloud).

Core properties of IoT Hub messaging functionality are the reliability and durability of messages. These properties enable resilience to intermittent connectivity on the device side, and to load spikes in event processing on the cloud side. IoT Hub implements once delivery guarantees for both device-to-cloud and cloud-to-device messaging.

IoT Hub supports multiple device-facing protocols (such as MQTT, AMQP, and HTTP). To support seamless interoperability across protocols, IoT Hub defines a common message format that all device-facing protocols support.

IoT Hub exposes a built-in Event Hub-compatible endpoint to enable back-end apps to read the device-to-cloud messages received by the Hub. You can also create custom endpoints in your IoT Hub by linking other services in your subscription to the Hub.

Use device-to-cloud messages for sending time-series telemetry and alerts from your device app, and cloud-to-device messages for one-way notifications to the device app.

Device-To-Cloud

You send device-to-cloud messages through a device-facing endpoint (/devices//messages/events). Routing rules then route your messages to one of the service-facing endpoints on your IoT Hub. Routing rules use the properties of the device-to-cloud messages flowing through your hub to determine where to route them. By default, messages are routed to the built-in service-facing endpoint (messages/events) that’s compatible with Event Hubs. Therefore, you can use standard Event Hubs integration and SDKs to receive device-to-cloud messages.

IoT Hub implements device-to-cloud messaging using a streaming messaging pattern. IoT Hub’s device-to-cloud messages are more like Event Hubs events than Service Bus messages in that there’s a high volume of events passing through the service that can be read by multiple readers.

This implementation has the following implications:

• Like Event Hubs events, device-to-cloud messages are durable and retained in an IoT Hub’s default messages/events endpoint for up to seven days.
• Like Event Hubs events, device-to-cloud messages can be at most 256 KB, and can be grouped in batches to optimise sends. Batches can be at most 256 KB.

There are, however, a few important distinctions between IoT Hub device-to-cloud messaging and Event Hubs:

• IoT Hub allows per-device authentication and access control.
• IoT Hub allows you to create up to 10 custom endpoints. Messages are delivered to the endpoints based on routes configured on your IoT Hub.
• IoT Hub allows millions of simultaneously connected devices (see Quotas and throttling), while Event Hubs is limited to 5000 AMQP connections per namespace.
• IoT Hub does not allow arbitrary partitioning using a PartitionKey. Device-to-cloud messages are partitioned based on their originating device.
• Scaling IoT Hub is slightly different than scaling Event Hubs.
• Cloud-To-Device
• You send cloud-to-device messages through a service-facing endpoint (/messages/device bound). A device receives them through a device-specific endpoint (/devices//messages/device bound).

Each cloud-to-device message is targeted at a single device by setting the to property to /devices//messages/devicebound.

Message Lifecycle

To guarantee message delivery, IoT Hub persists cloud-to-device messages in per-device queues. Devices must explicitly acknowledge completion for IoT Hub to remove them from the queue. This guarantees resilience against connectivity and device failures.

Cloud-To-Device-Messaging

When the service sends a message, it’s considered Enqueued. When a device wants to receive a message, IoT Hub locks the message (sets the state to Invisible) allowing other threads on the same device to start receiving other messages. When a device thread completes the processing of a message, it notifies IoT Hub by completing the message.

A device can also:

• Reject the message, which causes IoT Hub to set it to the Deadlettered state. Note: devices connecting with MQTT cannot reject cloud-to-device messages.
• Abandon the message, which causes IoT Hub to put the message back in the queue, with the state set to Enqueued.

A thread could fail to process a message without notifying IoT Hub. In this case, messages automatically transition from the Invisible state back to the Enqueued state after a visibility (or lock) timeout. The default value of this timeout is one minute.

A message can transition between the Enqueued and Invisible states for the number of times specified in the max delivery count property on IoT Hub. After that number of transitions, IoT Hub sets the state of the message to Deadlettered. Similarly, IoT Hub sets the state of a message to Deadlettered after its expiration time (see Time to live).

Do you have a good understanding of Hub messaging? If so, mark this step as complete and let’s move on to IoT device configuration.