Compartilhar via

Executar a descoberta de serviço

  • Artigo

Importante

Esta é a documentação do Azure Sphere (herdado). O Azure Sphere (herdado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).

Aplicativos de alto nível no Azure Sphere podem executar a descoberta de serviço por meio da DNS-SD (descoberta de serviço DNS). Os aplicativos podem usar a descoberta de serviço para encontrar serviços de rede e executar a resolução de nome de host para que eles possam interagir com o serviço por meio do firewall do Azure Sphere. O mDNS (DNS multicast) também pode ser usado para executar a descoberta de ponto a ponto em uma rede local, o que é especialmente útil quando os endereços IP e os nomes de host do ponto de extremidade de destino não são conhecidos no tempo de design.

Os aplicativos usam consultas de DNS-SD para recuperar os registros de DNS dos servidores DNS não locais ou por um link de multicast. Se o nome que está sendo consultado estiver sob o TLD (domínio de nível superior) .local, a consulta será feita por multicast na rede local em todas as interfaces de rede habilitadas; caso contrário, a descoberta de serviço unicast será executada. O Exemplo de descoberta de serviço demonstra como executar a descoberta de serviço no Azure Sphere.

Observação

O firewall do Azure Sphere impede que os aplicativos comuniquem-se com serviços não autorizados. No entanto, permitir conexões de saída para TLDs .local no manifesto do aplicativo pode aumentar o risco de segurança a um dispositivo ao permitir que um aplicativo conecte-se com serviços não autorizados anunciados na rede local. Os aplicativos só devem permitir conexões de saída para TLDs .local em ambientes seguros que impeçam que partes não autorizadas anunciem serviços. Para fornecer proteção adicional nesse cenário, o Azure Sphere requer que os serviços descobertos na rede local também residam na sub-rede local.

Incluir arquivos de cabeçalho

Aplicativos que executam a descoberta de serviço devem incluir o arquivo de cabeçalho resolv:

 #include <resolv.h>

Permitir uma conexão de serviço

Antes de executar uma consulta DNS-SD, você deve adicionar o serviço para o recurso de AllowedConnections do Manifesto do aplicativo. O firewall do Azure Sphere então permitirá que o aplicativo conecte-se a instâncias de serviço descobertas usando os respectivos endereços IP e nomes de host associados. Se um serviço TLD .local for especificado, o firewall só permitirá conexões a recursos descobertos na sub-rede local.

Os seguintes tipos de nomes de serviço são compatíveis com a capacidade AllowedConnections:

  • Nome do serviço DNS local, como "_sample._tcp.local"
  • Nome do serviço DNS não local, como "_sampleinstance._tcp.dns-sd.org"
  • Nome da instância de serviço local, como "_sampleinstance._tcp.hostname.local"
  • Nome de domínio, como "samplehost.contoso.com"
  • Endereço IP

Veja aqui um trecho de um manifesto do aplicativo que inclui um nome de serviço não local.

"AllowedConnections": [ "_http._tcp.dns-sd.org" ]

Executar uma consulta DNS-SD

Para executar uma consulta DNS-SD, você precisa solicitar vários tipos de registros DNS:

  • Registros PTR que enumeram as instâncias de um serviço DNS.
  • Registros SRV e TXT que contêm detalhes das instâncias de serviço, como nome do host e porta.
  • Registros A que contêm os endereços IP de nomes do host recuperados.

Antes de enviar a consulta, você precisa criar e inicializar essa consulta, então adicionar uma mensagem de consulta que solicite o registro de DNS. Você pode criar e inicializar uma consulta DNS-SD ao chamar o função POSIX res_init(). Você pode criar uma mensagem para a consulta ao chamar o função POSIX res_mkquery().

Enviar uma consulta DNS por unicast

Ao executar a descoberta de serviço de unicast, você pode enviar a consulta DNS-SD e recuperar a resposta ao chamar o a função POSIX res_send().

Para enviar uma consulta DNS-SD em um link de multicast, o aplicativo deve abrir um soquete e enviar a solicitação do soquete para o endereço IP de loopback 127.0.0.1 (porta de destino 53). Depois que a solicitação é enviada, várias respostas podem ser retornadas. O aplicativo deve aguardar e escutar por vários segundos para coletar todas as respostas. Isso é demonstrado no Exemplo de descoberta de serviço.

Importante

Esse endereço IP de loopback é um recurso Beta que será desativado e substituído em versões futuras. Essa será uma mudança significativa para aplicativos que dependem do endereço.

Conexões permitidas para hosts com vários endereços IP

O firewall do Azure Sphere só permite conexões com um endereço IP por nome do host. Se um host tiver vários endereços IP, o firewall do Azure Sphere só permitirá conexões para um dos endereços. Um aplicativo pode usar o curl para fazer solicitações HTTPS a um host que tenha vários endereços IP. O curl tentará conectar-se a cada endereço IP até que o endereço permitido seja encontrado. No entanto, isso pode causar um atraso enquanto o aplicativo localiza o endereço permitido.