O modelo usado pelos dispositivos conectados ao Hub IoT é que eles nunca aceitarão conexões de entrada. Os dispositivos do Hub IoT nunca atuam como um 'servidor' e essa é uma parte crucial do modelo de segurança na IoT do Azure. O modelo definitivo é encapsulado na Comunicação assistida por serviços da Clemens Vasters .
Portanto, os dispositivos estão sempre 'pesquisando' um serviço externo para enviar dados ou receber comandos. As APIs fazem parecer que os dados estão sendo enviados para um dispositivo, mas é sempre o dispositivo que faz a conexão de saída.
O Hub IoT faz isso de duas maneiras:
- Enviando dados para o terminal do dispositivo
/devices/{deviceId}/messages/devicebound. Este é um ponto de extremidade do sistema de mensagens AMQP, semelhante a uma fila ou assinatura de tópico. O dispositivo, ao ler comandos, precisa receber confirmação, se necessário, que faz parte do protocolo AMQP subjacente. Isso funciona da mesma forma com o MQTT e https é um fallback válido. A API envolve tudo isso para você. Existem conceitos adicionais, como 'métodos diretos', que são um wrapper de API em torno do mesmo protocolo de mensagens subjacente
- Usando o dispositivo duplo do lado do servidor, que é uma maneira de manter logicamente as propriedades sincronizadas entre o dispositivo e o servidor. Você define uma propriedade no dispositivo gêmeo e, quando o dispositivo sincroniza, essa propriedade será sincronizada com o dispositivo. Isso é menos baseado em mensagens e construído sobre o protocolo de gerenciamento de dispositivos LWM2M.
Muitas pesquisas, conexões, compartilhamento de conexões, recebimentos etc. devem ser atendidos como parte do protocolo AMQP (ou MQTT), que, por sua vez, é agrupado no SDK do Hub IoT. Portanto, o acima exposto é altamente simplificado, mas, para reiterar, o IoT Hub não pode e nunca tentará enviar dados para um endereço / porta IP no seu dispositivo.