Partilhar via

Executar descoberta de serviço

  • Artigo

Importante

Esta é a documentação do Azure Sphere (Legado). O Azure Sphere (Legado) 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).

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

Os aplicativos usam consultas DNS-SD para recuperar registros DNS de servidores DNS não locais ou por meio de um link multicast. Se o nome que está sendo consultado estiver sob o domínio de nível superior (TLD) .local , a consulta será multicast na rede local por meio de 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.

Nota

O firewall do Azure Sphere impede que os aplicativos se comuniquem com serviços não autorizados. No entanto, permitir conexões de saída para TLDs .locais no manifesto do aplicativo pode aumentar o risco de segurança para um dispositivo, permitindo que um aplicativo se conecte a 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 partes não autorizadas de anunciar 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

Os aplicativos que executam a descoberta de serviço devem incluir o arquivo de cabeçalho do resolv:

 #include <resolv.h>

Permitir uma conexão de serviço

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

Os seguintes tipos de nomes de serviço são suportados no recurso 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

Aqui está um trecho de um manifesto de 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 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.
  • Um registro que contém os endereços IP dos nomes de host recuperados.

Antes de enviar a consulta, você precisa criá-la e inicializá-la e, em seguida, adicionar uma mensagem de consulta que solicita o registro DNS. Você pode criar e inicializar uma consulta DNS-SD chamando a função POSIX res_init(). Você pode criar uma mensagem para a consulta chamando a função POSIX res_mkquery().

Enviar uma consulta DNS unicast

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

Para enviar uma consulta DNS-SD através de um link multicast, o aplicativo deve abrir um soquete e enviar a solicitação pelo soquete para o endereço IP de loopback 127.0.0.1 (porta de destino 53). Depois que a solicitação for enviada, várias respostas poderão ser retornadas. O aplicativo deve esperar e ouvir 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á retirado e substituído em versões futuras. Esta será uma mudança significativa para os 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 de host. Se um host tiver vários endereços IP, o firewall do Azure Sphere só permitirá conexões com um dos endereços. Um aplicativo pode usar curl para fazer solicitações HTTPS para um host que tenha vários endereços IP; curl tentará se conectar a cada endereço IP até que o endereço permitido seja encontrado. No entanto, isso pode causar um atraso enquanto o aplicativo encontra o endereço permitido.