Share MQTT device client connection for multiple devices (SDK v2)

[WillooWisp]

I wonder what the resource / performance implications might be when you have thousands of devices, each having it's own identity (device id) in the IoT hub for separation and authentication purposes, and therefore each having a device client of its own. This means that from a single .NET program thousands of MQTT connections will be initiated and kept alive, what about network resource exhaustion, is it a problem or not?

If this will become a problem, with many device clients, do you have any plans on being able to share a single device client and MQTT connection in the upcoming v2 of the Azure IoT SDK? E.g. creating a single device client for the gateway device itself, but then allow sending messages for each device (sensor) through the same device client, passing on device id and device key for authentication with the IoT hub.

A "shared" device client for multiple devices would also help with the throttling implications of the IoT hub related to new connections, file uploads and telemetry message quota.

[abhipsaMisra]

Hello @WillooWisp

As you've indicated above, initializing thousands of client connections through a single .NET application does bring in the possibility of running into port exhaustion. What you'd want to do instead, is use multiplexing to multiplex multiple client sessions over the same connection. This feature, however, is available only over AMQP. MQTT v3.1 does not support multiplexing.

In order to create a complete solution, there are a couple of ways you can implement identity translation through a gateway using the IoT SDK.

• the IoT device client supports multiplexing and connection pooling over AMQP. What this means is that you can define your maximum no. of connections in your connection pool and the maximum no of devices you want multiplexed over a single connection: https://github.com/Azure/azure-iot-sdk-csharp/blob/previews/v2/iothub/device/src/TransportSettings/AmqpConnectionPoolSettings.cs. The IoT SDK will create each client instance with the connection pool settings that you define. You can use the individual created clients to send their respective telemetry to IoT hub.
• you can use an Azure offering for gateway scenarios, Azure IoT Edge: https://learn.microsoft.com/azure/iot-edge/iot-edge-as-gateway?view=iotedge-1.4. You can use an IoT Edge device as a gateway, while also getting other benefits like analytics at edge, offline capabilities, etc.

Let me know if you have any further questions.

[WillooWisp]

Yes I know all about AMQP and multiplexing, but AMQP is not an option and MQTT is much more preffered.

So the question was more related to v2 of the SDK and if there are any plans to improvement with many connections over MQTT. Even if multiplexing cannot be used per say, a shared connection could still be implemented as transport for many devices.

[abhipsaMisra]

The v2 SDK follows MQTT 3.1. specs, which doesn't support multiplexing out-of-the-box.
Do you have an idea for a shared connection implementation over MQTT? While we don't have anything planned for the moment, we'd be happy to discuss a proposal, if you have one.

Also, Azure IoT Edge supports protocol and identity translation for downstream devices. Would that address your scenario?

[WillooWisp]

Multiplexing is not really what I am after, but rather the possibility to use a single shared MQTT connection, e.g. device client, that allows sending messages to separate IoT hub devices. We have IoT gateways with thousand of devices routed through it, and creating thousands of device clients just to be able to separate the individual device messages in a secure way is not optimal, both to resources and Azure costs and limits to throttling of the IoT hub.

It would be good if the SDK supported creating a single device client, MQTT connection, for the gateway itself, but the be allowed to send separate messages to specific IoT hub devices through that single shared connection. The thing you would need to implement is the key verification so that it's verified that the single shared connection through a common device client is allowed to send the messages for those devices.

[abhipsaMisra]

It sounds to me that what you're looking for might be identity translation within a gateway scenario, wherein the identity of the downstream device is preserved so that each device has its own twin and service can identity each device separately, even though they're communication via the gateway.
Our IoT Edge offering might provide what you're looking for - https://learn.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway?view=iotedge-1.4#identity-translation.

If you'd like, I could connect you with a member of the IoT Edge team and they could walk you through the different features and capabilities that Azure IoT Edge offers.

[abhipsaMisra]

You can use the Azure IoT SDK when communicating with both IoT hub directly, and also when communicating with IoT hub via IoT Edge. Depending on how you application is architectured, you'd need to initialize your client accordingly.
If the IoT Edge scenario works for you, we can guide you on how to use the SDK when communicating with IoT Hub via IoT Edge (it is mostly the client initialization that differs, since connecting via IoT Edge introduces a gateway).