Introduction
À Maple Yard, les visiteurs veulent un petit aperçu des photos ou l’album complet du photomaton. Les serveurs photo fonctionnent déjà, mais les visiteurs ne devraient pas avoir besoin d’une fiche indiquant une adresse IP et un port. Vous publierez deux services nommés, les découvrirez depuis des clients et enregistrerez les collections correspondantes sans interrompre le point d’information.
Vous devez savoir reconnaître les adresses IPv4, noms d’hôte, ports, chemins et rôles des terminaux, et avoir déjà suivi des commandes complètes de téléchargement HTTP. Le projet précédent sur le réseau de l’événement est recommandé. Aucune expérience en administration DNS, en XML ou en programmation n’est requise. Les 60 minutes estimées comprennent la lecture et les erreurs courantes ; il s’agit d’une estimation de l’auteur, pas d’une durée mesurée auprès de débutants.
Publisher, Client et New Client sont des nœuds réseau Linux isolés sur un LAN préparé, partageant un même noyau. Photo Shelf affiche les fichiers téléchargés. Ce laboratoire enseigne mDNS et DNS-SD sur le lien local, et non le DNS public, la découverte à travers des routeurs, l’autorisation automatique ou la compatibilité avec tous les appareils physiques ou navigateurs. Les exemples sont des cartes illustrées synthétiques originales, pas des photographies de véritables participants.
Découvrir un service fonctionnel
Dans cette étape, vous utiliserez le point d’information fonctionnel avant de publier quoi que ce soit. Commencez dans Client. Son terminal démarre dans /home/labex/project/photo-network/client ; ce répertoire et son shell sont indépendants des autres onglets. pwd affiche le répertoire courant :
pwd
Le DNS multicast (mDNS) permet aux appareils voisins d’échanger des informations de nom sur le même lien local. Ici, ses paquets utilisent l’adresse multicast IPv4 224.0.0.251 et le port UDP 5353. Le suffixe .local appartient à ce mécanisme de découverte locale ; ne l’ajoutez pas au fichier hosts de la plateforme et ne le traitez pas comme une zone DNS publique.
La découverte de services basée sur DNS (DNS-SD) décrit des instances de service nommées. Un type de service précise ce que cherche un client : _http._tcp signifie HTTP sur TCP. Un nom d’instance, tel que Information Desk, identifie un service proposé. Le nom d’hôte cible identifie le nœud qui le fournit. Un port choisit l’application à l’écoute ; les métadonnées path choisissent une ressource dans celle-ci. Trouver un nom n’est que le début de l’utilisation d’un service.
avahi-browse demande au démon natif Avahi de découvrir des services. -r résout chaque instance en paramètres de connexion, -t quitte après l’exploration, -p affiche des champs séparés par des points-virgules et -k conserve les noms bruts des types de service plutôt que leurs traductions descriptives :
avahi-browse -rtpk _http._tcp
Vous devez obtenir une ligne résolue commençant par = et contenant ces champs :
=;eth0;IPv4;Information\032Desk;_http._tcp;local;desk.local;10.93.0.10;8080;"path=/welcome/index.json"
Avahi peut aussi afficher des lignes + pour les instances nouvellement détectées. Dans sa sortie analysable, \032 représente un espace. Lisez la ligne résolue dans cet ordre : instance, type, domaine, nom d’hôte cible, adresse, port, puis métadonnées TXT. L’ordre des lignes et les échappements peuvent varier. Le démon natif reçoit ces enregistrements sur ce LAN ; il n’existe aucune liste de découverte préétablie.
Utilisez le client fourni photo-get pour enregistrer une collection à partir de son nom d’instance. Les guillemets maintiennent un nom contenant des espaces dans un seul argument. Le second argument est un dossier de sortie dans l’espace de travail de ce terminal :
photo-get "Information Desk" desk
photo-get effectue une nouvelle exploration réelle avec Avahi, résout cette instance exacte, affiche son point de connexion, récupère l’index JSON annoncé et chaque PNG répertorié, décode toutes les images, puis enregistre les octets reçus. Il ne consulte pas le plan des stations pour obtenir une IP, un port ou un chemin. L’index indique les noms de fichiers des images ; c’est une convention applicative de ces services, pas un format DNS-SD universel. Vous devez voir Saved 1 real images pour le dossier desk.
Passez à Photo Shelf et sélectionnez Client. Rechargez les fichiers enregistrés. Vous devez voir la carte Welcome to Maple Yard. Le lecteur ne consulte que les fichiers enregistrés dans l’espace de travail de ce client ; il ne contacte jamais un serveur et ne remplace pas une image manquante. Le lien Download image renvoie ce même fichier enregistré.
La sélection Client identifie cet espace de travail. La carte du point d’information est la référence fonctionnelle à préserver lors de l’ajout du photomaton.
Si l’exploration est vide, vérifiez le type de service exact et que vous êtes dans Client, puis recommencez. Daemon not running signifie que le client de découverte ne peut pas joindre son démon préparé ; cela diffère d’un résultat vide. Si photo-get ne résout pas le nom, comparez son orthographe et ses guillemets à la ligne résolue. Un refus de connexion signifie qu’une adresse a été trouvée, mais que rien n’accepte ce port. HTTP 404 signifie que le serveur est atteint, mais que le chemin de la ressource n’existe pas. Une erreur JSON ou de décodage d’image signifie que le contenu reçu est inadapté. Ne remplacez pas la résolution de ces problèmes par une entrée hosts ou une image copiée manuellement.
Publier le photomaton à partir d’un modèle complet
Dans cette étape, vous annoncerez le serveur d’aperçu existant. Passez à Publisher. Son terminal démarre dans /home/labex/project/photo-network/services. cat affiche un fichier texte ; ../ désigne son répertoire parent :
cat ../stations.tsv
Ce plan métier décrit les véritables services à l’écoute déjà préparés. Photo Booth Preview appartient à publisher.local, sur le port 8081, avec la ressource /preview/index.json. L’album complet utilise un autre service à l’écoute et une autre ressource. Le point d’information appartient à un autre nœud et doit rester inchangé.
Lisez la définition d’aperçu incomplète :
cat preview.service
Ici, un fichier .service utilise XML : des balises ouvrantes et fermantes entourent chaque valeur. service-group contient le name affiché ; son élément service fournit type, port et txt-record. Publier une définition ne crée ni serveur web, ni collection, ni autorisation d’accès. Ces applications fonctionnent déjà.
Le here-document suivant écrit le petit fichier complet. > remplace son ancien contenu. Le délimiteur entre guillemets 'XML' conserve le texte littéral ; le XML final doit être seul au début de sa ligne. Copiez le bloc entier :
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
Lisez votre définition enregistrée :
cat preview.service
La commande du cours photo-load analyse les deux fichiers XML modifiables avant de demander uniquement au démon Avahi de Publisher de les recharger. Elle ne redémarre ni le point d’information ni les serveurs métier :
photo-load
Vous devez voir Reload requested for the photo publisher. Laissez quelques secondes à la vérification du nom et à l’enregistrement. Une analyse réussie confirme la structure XML, pas la justesse du port ou du chemin annoncé. Si une balise fermante manque, photo-load indique le fichier et l’erreur d’analyse sans demander de rechargement. Lisez le fichier, restaurez le bloc complet et relancez photo-load. Il n’est pas nécessaire de réinitialiser l’environnement.
Passez à Client et explorez à nouveau :
avahi-browse -rtpk _http._tcp
Repérez Photo Booth Preview, sa cible publisher.local, le port 8081 et /preview/index.json. Enregistrez et décodez la collection réelle :
photo-get "Photo Booth Preview" preview
Vous devez obtenir une image d’aperçu. Dans Photo Shelf, sélectionnez Client, rechargez et examinez la carte d’aperçu à côté de celle du point d’information existant. Un service affiché dans la liste sans fournir la bonne image reste incomplet.
Distinguer deux services
Dans cette étape, vous publierez l’album complet sur le même nœud et distinguerez les deux instances. Passez à Publisher. Elles utilisent toutes deux _http._tcp et publisher.local, mais l’album emploie le port 8082 et /album/index.json. Ses trois images diffèrent de l’aperçu à une seule image.
Écrivez sa définition séparée avec la syntaxe here-document déjà apprise :
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
Passez à Client. Explorez et lisez chaque ligne résolue séparément :
avahi-browse -rtpk _http._tcp
Les deux noms d’instance doivent être différents. Un nom d’hôte commun n’implique pas un port ou une ressource identique. Téléchargez l’album dans son propre dossier en conservant l’aperçu :
photo-get "Photo Booth Full Album" album
Vous devez obtenir trois PNG décodés et Saved 3 real images. Dans Photo Shelf, sélectionnez Client et rechargez. L’album et l’aperçu doivent afficher leurs propres fichiers enregistrés.
Exercez-vous maintenant à reconnaître une mauvaise ressource sans modifier ni supprimer vos collections correctes. Le nom d’instance volontairement absent ci-dessous doit provoquer un échec avant tout téléchargement :
photo-get "Photo Booth Missing" missing
Vous devez voir Download stopped: Expected one resolved instance avec un code de sortie non nul. C’est intentionnel. Rétablissez la situation en utilisant de nouveau le nom réellement résolu de l’album :
photo-get "Photo Booth Full Album" album
Si vous avez annoncé un mauvais port ou chemin, comparez la ligne résolue de cette instance avec stations.tsv. Corrigez uniquement le fichier .service correspondant dans Publisher, à l’aide de son bloc complet présenté, exécutez photo-load, puis explorez et téléchargez à nouveau dans Client. Un mauvais port d’écoute peut refuser la connexion ; un mauvais chemin peut produire HTTP 404 ; une collection accessible mais différente peut être décodée avec succès tout en constituant un résultat métier incorrect. Vérifiez le titre et les noms de fichiers de la collection, pas seulement un code de sortie nul.
Avahi annonce les modifications et les retraits. Un client peut brièvement conserver d’anciens enregistrements pendant la propagation d’une mise à jour. Attendez quelques secondes après le chargement et relancez l’exploration ; ne continuez pas à utiliser d’anciens points de connexion copiés. L’étape suivante vérifie le résultat depuis un démon client et un espace de travail indépendants.
Utiliser le résultat depuis un autre client
Dans cette étape, vous utiliserez une autre identité réseau et un démon Avahi indépendant. Passez à New Client. Il démarre dans /home/labex/project/photo-network/new-client ; par défaut, il ne partage ni les variables du shell ni les collections enregistrées du premier client. Ouvrir un onglet ne réinitialise pas le publicateur et ne crée pas d’annonces.
Explorez depuis ce client plutôt que de copier les lignes du premier :
avahi-browse -rtpk _http._tcp
Lisez les trois correspondances d’instances résolues. L’aperçu et l’album complet ont la même cible, mais des ports et chemins différents. Le point d’information a sa propre cible. Téléchargez les trois depuis ce client :
photo-get "Photo Booth Preview" preview
photo-get "Photo Booth Full Album" album
photo-get "Information Desk" desk
Vous devez obtenir un aperçu, trois images d’album et une carte du point d’information. Chaque appel résout de nouveau l’instance nommée et affiche le point de connexion réellement utilisé. Ces commandes ne configurent pas une découverte par IP statique.
Passez à Photo Shelf, sélectionnez New Client et rechargez. Examinez chaque image et titre de collection. Sélectionnez Download image sur une carte d’image enregistrée ; l’image téléchargée doit correspondre à la carte enregistrée affichée. Le lecteur ne copie pas silencieusement le travail du premier client et ne complète pas les fichiers manquants. Alternez entre Client et New Client pour voir leurs collections distinctes.
Repérez la sélection New Client, les trois cartes d’album, la carte du point d’information et la carte d’aperçu séparée. Chaque lien Download image correspond à un fichier réellement enregistré.
Si une collection manque, retournez dans New Client et relancez son téléchargement après avoir vérifié l’annonce actuelle. Si un PNG enregistré manque ou est illisible, le lecteur le signale au lieu de le remplacer. Corrigez d’abord la publication ou la connexion, puis relancez photo-get pour récupérer la collection originale complète. Le téléchargement n’est réussi qu’après récupération et décodage de l’index complet et de toutes les images.
Vous avez relié publication et utilisation : trois instances distinctes, des points de connexion actuels corrects, de vrais fichiers sur deux clients et un point d’information toujours utilisable. La découverte fournit des paramètres de connexion, pas une authentification ni la garantie qu’un service découvert est digne de confiance.
Résumé
Vous avez parcouru des enregistrements mDNS/DNS-SD natifs, distingué les noms d’instance des noms d’hôte et publié deux services HTTP avec des ports et des métadonnées de chemin distincts. Vous avez utilisé chaque résultat de découverte réel pour télécharger des images décodables, répété le parcours depuis un client indépendant et maintenu le point d’information disponible. Une ligne de découverte et une connexion réussie sont des preuves différentes ; le bon contenu enregistré complète le résultat.
