The model that IoT Hub connected devices use is that they will never accept incoming connections. IoT Hub devices never act as a 'server', and this is a crucial part of the security model in Azure IoT. The definitive model on this is encapsulated in Clemens Vasters' 'Service Assisted Communication'.
Therefore devices are always 'polling' an external service in order to send data or receive commands. The APIs make it look like data is being sent to a device, but it is always the device making the outgoing connection.
IoT hub does this in two ways:
- By sending data to the device endpoint
/devices/{deviceId}/messages/devicebound
. This is an AMQP messaging endpoint, similar to a queue or topic subscription. The device, when reading commands, needs to acknowledged receipt if needed, which is part of the underlying AMQP protocol. This works the same with MQTT, and https is a valid fallback.
The API wraps all of this up for you. There are additional concepts, such as 'direct methods' which are an API wrapper around essentially the same underlying message protocol
- By using the server-side device twin, which is a way to logically keep properties in sync between device and server. You set a property on the device twin, and when the device syncs up that property will be synced to the device. This is less message-based and built on top of the LWM2M device management protocol.
A lot of the 'polling', connecting, sharing connections, receipts, etc should be taken care of as part of the AMQP (or MQTT) protocol, which in turn is wrapped up in the IoT Hub SDK. So the above is highly simplified, but to reiterate, IoT Hub cannot, and will not (ever) try and send data to a ip address/port on your device.