Introdução
No Maple Yard, os visitantes querem uma pequena prévia das fotos ou o álbum completo da cabine. Os servidores de fotos já funcionam, mas os visitantes não deveriam precisar de um papel com endereço IP e porta. Você publicará dois serviços nomeados, descobrirá seus destinos a partir dos clientes e salvará as coleções correspondentes sem interromper o balcão de informações.
Você deve reconhecer endereços IPv4, nomes de host, portas, caminhos e papéis dos terminais, além de já ter seguido comandos completos de download HTTP. Recomenda-se o projeto anterior sobre a rede do evento. Não é necessário conhecer administração DNS, XML ou programação. Os 60 minutos estimados incluem leitura e erros comuns; trata-se de uma estimativa do autor, não de um tempo medido com iniciantes.
Publisher, Client e New Client são nós de rede Linux isolados em uma LAN preparada e compartilham um kernel. Photo Shelf mostra arquivos baixados. Este laboratório ensina mDNS e DNS-SD no enlace local, não DNS público, descoberta entre roteadores, autorização automática ou compatibilidade com todos os dispositivos físicos e navegadores. As imagens de exemplo são cartões ilustrados sintéticos originais, não fotografias de participantes reais.
Descobrir um serviço em funcionamento
Nesta etapa, você usará o balcão de informações que já funciona antes de publicar qualquer coisa. Comece em Client. O terminal inicia em /home/labex/project/photo-network/client; esse diretório e seu shell permanecem separados das outras abas. pwd mostra o diretório atual:
pwd
O DNS multicast (mDNS) permite que dispositivos vizinhos troquem informações de nomes no mesmo enlace local. Aqui, os pacotes usam o endereço multicast IPv4 224.0.0.251 e a porta UDP 5353. O sufixo .local pertence a esse mecanismo de descoberta local; não o adicione ao arquivo hosts da plataforma nem o trate como uma zona DNS pública.
A descoberta de serviços baseada em DNS (DNS-SD) descreve instâncias de serviços nomeadas. Um tipo de serviço indica o que um cliente procura: _http._tcp significa HTTP sobre TCP. Um nome de instância, como Information Desk, identifica um serviço oferecido. O nome de host de destino identifica o nó que o fornece. Uma porta seleciona a aplicação que está escutando; os metadados path selecionam um recurso dentro dela. Encontrar um nome é apenas o início da utilização de um serviço.
avahi-browse pede ao daemon nativo do Avahi que descubra serviços. -r resolve cada instância em informações de conexão, -t encerra após a busca, -p imprime campos separados por ponto e vírgula e -k mantém os nomes originais dos tipos de serviço em vez de traduções descritivas:
avahi-browse -rtpk _http._tcp
Espere uma linha resolvida começando com = e contendo estes campos:
=;eth0;IPv4;Information\032Desk;_http._tcp;local;desk.local;10.93.0.10;8080;"path=/welcome/index.json"
O Avahi também pode imprimir linhas + para instâncias recém-encontradas. Na saída analisável, \032 representa um espaço. Leia a linha resolvida na ordem: instância, tipo, domínio, nome de host de destino, endereço, porta e metadados TXT. A ordem das linhas e os escapes podem variar. O daemon nativo recebe esses registros por esta LAN; não existe uma lista de descoberta preparada.
Use o cliente fornecido photo-get para salvar uma coleção pelo nome da instância. As aspas mantêm um nome com espaços como um único argumento. O segundo argumento é uma pasta de saída dentro do espaço de trabalho deste terminal:
photo-get "Information Desk" desk
photo-get faz outra busca real com Avahi, resolve exatamente essa instância, imprime o destino, busca o índice JSON anunciado e cada PNG listado, decodifica todas as imagens e salva os bytes recebidos. Ele não consulta o plano das estações para obter IP, porta ou caminho. O índice lista os nomes dos arquivos de imagem; isso é uma convenção de aplicação desses serviços, não um formato universal do DNS-SD. Espere Saved 1 real images na pasta desk.
Mude para Photo Shelf e selecione Client. Recarregue os arquivos salvos. Você deverá ver o cartão Welcome to Maple Yard. O visualizador lê apenas os arquivos salvos no espaço de trabalho deste cliente; nunca busca dados no servidor nem repõe uma imagem ausente. O link Download image retorna o mesmo arquivo salvo.
A seleção Client identifica este espaço de trabalho. O cartão do balcão de informações é a referência funcional que você preservará ao adicionar a cabine.
Se a busca estiver vazia, confira o tipo exato de serviço e se você está em Client, depois repita. Daemon not running significa que o cliente de descoberta não consegue acessar seu daemon preparado; isso é diferente de um resultado vazio. Se photo-get não resolver o nome, compare a grafia e as aspas com a linha resolvida. Conexão recusada significa que um endereço foi encontrado, mas nada aceitou aquela porta. HTTP 404 significa que o servidor foi alcançado, mas o caminho do recurso não existe. Um erro de JSON ou de decodificação de imagem indica conteúdo inadequado. Não substitua a correção desses problemas por uma entrada hosts ou uma imagem copiada manualmente.
Publicar a cabine a partir de um modelo completo
Nesta etapa, você anunciará o servidor de prévia existente. Mude para Publisher. O terminal inicia em /home/labex/project/photo-network/services. cat mostra um arquivo de texto; ../ significa seu diretório pai:
cat ../stations.tsv
Este plano de negócio descreve os serviços reais de escuta preparados. Photo Booth Preview pertence a publisher.local, na porta 8081, com o recurso /preview/index.json. O álbum completo usa outro serviço de escuta e outro recurso. O balcão de informações está em outro nó e deve permanecer inalterado.
Leia a definição incompleta da prévia:
cat preview.service
Um arquivo .service aqui usa XML: etiquetas de abertura e fechamento envolvem cada valor. service-group contém o name exibido; seu elemento service fornece type, port e txt-record. Publicar uma definição não cria um servidor web, uma coleção ou uma permissão de acesso. Essas aplicações já estão em execução.
O here-document a seguir grava o pequeno arquivo completo. > substitui seu conteúdo anterior. O delimitador entre aspas 'XML' mantém o texto literal; o XML final deve estar sozinho no início da linha. Copie o bloco inteiro:
cat > preview.service <<'XML'
<?xml version="1.0" standalone="no"?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>Photo Booth Preview</name>
<service>
<type>_http._tcp</type>
<port>8081</port>
<txt-record>path=/preview/index.json</txt-record>
</service>
</service-group>
XML
Leia a definição salva:
cat preview.service
O comando do curso photo-load analisa os dois arquivos XML editáveis antes de pedir somente ao daemon Avahi de Publisher que os recarregue. Ele não reinicia o balcão de informações nem os servidores de negócio:
photo-load
Espere Reload requested for the photo publisher. Aguarde alguns segundos para a verificação do nome e o registro. Uma análise bem-sucedida confirma a estrutura XML; não prova que a porta ou o caminho anunciados estejam corretos. Se faltar uma etiqueta de fechamento, photo-load informa o arquivo e o erro de análise sem enviar uma solicitação de recarga. Leia o arquivo, restaure o bloco completo e execute photo-load novamente. Não é necessário redefinir o ambiente.
Mude para Client e busque novamente:
avahi-browse -rtpk _http._tcp
Encontre Photo Booth Preview, seu destino publisher.local, a porta 8081 e /preview/index.json. Salve e decodifique a coleção real:
photo-get "Photo Booth Preview" preview
Espere uma imagem de prévia. No Photo Shelf, selecione Client, recarregue e examine o cartão de prévia ao lado do cartão existente do balcão de informações. Um serviço na lista sem a imagem correta ainda é um resultado incompleto.
Distinguir dois serviços
Nesta etapa, você publicará o álbum completo no mesmo nó e distinguirá as duas instâncias. Mude para Publisher. Ambas usam _http._tcp e publisher.local, mas o álbum usa a porta 8082 e /album/index.json. Suas três imagens diferem da prévia de uma única imagem.
Escreva sua definição separada com a sintaxe here-document já aprendida:
cat > album.service <<'XML'
<?xml version="1.0" standalone="no"?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>Photo Booth Full Album</name>
<service>
<type>_http._tcp</type>
<port>8082</port>
<txt-record>path=/album/index.json</txt-record>
</service>
</service-group>
XML
photo-load
Mude para Client. Faça a busca e leia cada linha resolvida separadamente:
avahi-browse -rtpk _http._tcp
Os nomes das duas instâncias devem ser diferentes. Um nome de host comum não significa uma porta ou um recurso comum. Baixe o álbum para sua própria pasta, preservando a prévia:
photo-get "Photo Booth Full Album" album
Espere três PNGs decodificados e Saved 3 real images. No Photo Shelf, selecione Client e recarregue. Álbum e prévia devem mostrar seus próprios arquivos salvos.
Agora pratique reconhecer um recurso errado sem editar nem apagar suas coleções corretas. Um nome de instância intencionalmente ausente deve falhar antes de qualquer download:
photo-get "Photo Booth Missing" missing
Espere Download stopped: Expected one resolved instance e um código de saída diferente de zero. Isso é intencional. Recupere-se usando novamente o nome real resolvido do álbum:
photo-get "Photo Booth Full Album" album
Se anunciou uma porta ou um caminho errado, compare a linha resolvida da instância com stations.tsv. Corrija apenas o arquivo .service correspondente em Publisher, usando o bloco completo mostrado, execute photo-load e volte a buscar e baixar em Client. Uma porta de escuta errada pode recusar a conexão; um caminho errado pode produzir HTTP 404; uma coleção acessível, porém diferente, pode ser decodificada e ainda ser um resultado de negócio incorreto. Confira o título da coleção e os nomes de arquivo, não apenas um código de saída zero.
O Avahi anuncia alterações e retiradas. Um cliente pode manter registros antigos brevemente enquanto uma atualização se propaga. Aguarde alguns segundos depois de carregar e repita a busca; não continue usando destinos antigos copiados. A próxima etapa verifica o resultado em um daemon de cliente e um espaço de trabalho independentes.
Usar o resultado em outro cliente
Nesta etapa, você usará outra identidade de rede e um daemon Avahi independente. Mude para New Client. Ele inicia em /home/labex/project/photo-network/new-client; por padrão, não compartilha as variáveis do shell nem as coleções salvas do primeiro cliente. Abrir uma aba não redefine o publicador nem cria anúncios.
Faça a busca neste cliente em vez de copiar as linhas do primeiro:
avahi-browse -rtpk _http._tcp
Leia as relações das três instâncias resolvidas. A prévia e o álbum completo têm o mesmo destino, mas portas e caminhos diferentes. O balcão de informações tem seu próprio destino. Baixe os três neste cliente:
photo-get "Photo Booth Preview" preview
photo-get "Photo Booth Full Album" album
photo-get "Information Desk" desk
Espere uma prévia, três imagens do álbum e um cartão do balcão de informações. Cada chamada resolve novamente a instância nomeada e mostra o destino real usado. Esses comandos não configuram descoberta por IP estático.
Mude para Photo Shelf, selecione New Client e recarregue. Inspecione cada imagem e título de coleção. Selecione Download image em um cartão de imagem salva; a imagem baixada deve corresponder ao cartão salvo exibido. O visualizador não copia silenciosamente o trabalho do primeiro cliente nem repõe arquivos ausentes. Alterne entre Client e New Client para ver suas coleções separadas.
Encontre a seleção New Client, três cartões do álbum, o cartão do balcão de informações e o cartão separado da prévia. Cada link Download image pertence a um arquivo realmente salvo.
Se faltar uma coleção, volte para New Client e repita seu download depois de conferir o anúncio atual. Se um PNG salvo estiver ausente ou ilegível, o visualizador informa o problema em vez de substituí-lo. Corrija primeiro a publicação ou a conexão e repita photo-get para obter a coleção original completa. O download só é bem-sucedido após obter e decodificar o índice completo e todas as imagens.
Agora você conectou publicação e uso: três instâncias distinguíveis, destinos atuais corretos, arquivos reais em dois clientes e um balcão de informações ainda utilizável. A descoberta fornece dados de conexão, não autenticação nem garantia de confiança no serviço encontrado.
Resumo
Você explorou registros mDNS/DNS-SD nativos, distinguiu nomes de instância de nomes de host e publicou dois serviços HTTP com portas e metadados de caminho separados. Usou cada resultado real de descoberta para baixar imagens decodificáveis, repetiu o fluxo em um cliente independente e manteve o balcão de informações disponível. Uma linha de descoberta e uma conexão bem-sucedida são evidências diferentes; o conteúdo correto salvo completa o resultado.
