Search code examples
c#azure-iot-hubazure-iot-sdk

Should one set the TransportType for the IoT Hub DeviceClient?

I am experimenting with sending messages to an Azure IoT Device via the DeviceClient class.

Connection is set up similar to this example: https://github.com/tamhinsf/SimpleAzureIoTCerts/blob/master/SimpleAzureIoTCerts/Program.cs

// works for me with SharedKey
DeviceClient.CreateFromConnectionString(...);
// or this also works:
var authWithPrimaryPfx = new DeviceAuthenticationWithX509Certificate(deviceId, cert);
return DeviceClient.Create(hostName, authWithPrimaryPfx);

What I also see in the example is that it is setting Microsoft.Azure.Devices.Client.TransportType on creating the DeviceClient.

Is this necessary, recommended, and if, are there any setting in the IoT Hub Interface to control which protocols a device supports?

Side Note: I'm also asking because while the connection to mylitlitesthub.azure-devices.net does work, the initial connection is horribly slow. It takes over 20 sec to send the first message.

Solution

  • IoT Hub Device Client class lets you create a device client instance without explicitly setting the Transport Type overload. The device client created using this method communicates on AMQP protocol (with fallback; see table below). You can find the different overloads the Create method has through the documentation link DeviceClient.Create Method. Below is a list of Transport Type options the Device Client Class supports:

    Available Transport Types

    IoT Hub supports all these protocols for Device-to-cloud messages. Specific scenarios such as reading Device twin's properties require the usage of MQTT or AMQP.

    IoT Hub does not determine the protocol supported by the device. This is determined by the manufacturer factoring in the limitations of the devices. Some of the low resource devices (for example less than 1MB of RAM) might only support MQTT. Refer the following resources to get more information on which protocol to use for different scenarios.

    It is hard to tell what is causing the delay in the initial connection. It could be due to network latency or delays in establishing the protocol negotiation. Based on the device you are testing from and its supportability of protocols, try testing MQTT Transport Type and see if that helps.