Introduction
Willow Games est prêt pour une nouvelle série. Le poste de score a besoin d’interactions réactives ; le poste multimédia attend un fichier audio de répétition complet. Les deux liaisons fonctionnent, mais la route initiale envoie les deux travaux sur une seule liaison.
Vous répéterez de courtes mesures dans un environnement nouvellement préparé, choisirez des routes distinctes par destination et enverrez le nouveau score et l’audio complet. Terminez d’abord Mesurer les besoins réseau de chaque tâche, ou possédez des compétences équivalentes en ping, iperf3 et routes IPv4 à portée limitée. Aucune programmation ni encodage multimédia n’est nécessaire.
Utilisez Event Client pour les commandes et Event Receipts pour voir et lire le contenu réellement reçu. Seules les deux routes de destination nommées et vos nouveaux envois sont modifiables. Les 45 minutes sont une estimation de l’auteur ; les nœuds isolés partagent un noyau et représentent des chemins virtuels câblés, pas des mesures de fournisseurs publics.
Choisir selon la charge de travail annoncée
Vous mesurerez ici les liaisons préparées et en choisirez une pour chaque travail. Commencez dans Event Client, déjà dans /home/labex/project/event-links. Ce TP possède son propre réseau et ses nouveaux fichiers. Il suppose les outils de délai et de débit de Mesurer les besoins réseau de chaque tâche, ainsi que la lecture élémentaire des routes par destination ; aucun fichier ni processus actif n’est repris.
Observez d’abord la fonction normale à préserver. Le poste de score possède déjà un enregistrement d’échauffement. curl --noproxy '*' contourne les proxies, -fsS échoue sur les erreurs HTTP tout en affichant les messages, et --max-time 35 limite le transfert :
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Le score conservé attendu est warmup, 1–1. Passez à Event Receipts. Les deux cartes principales attendent heat-7 et opening-sound.wav ; la page ne considère pas l’échauffement comme un nouveau travail terminé. Revenez à Event Client.
Le poste de score demande de courtes interactions : choisissez la liaison dont le RTT est régulièrement faible, avec une moyenne d’échantillon nettement sous le budget de planification de 80 ms. L’équipe multimédia a besoin de capacité d’envoi en masse : choisissez le chemin dont le débit au récepteur dépasse largement 10 Mbps dans ce scénario préparé. Ces budgets larges guident votre choix ; ils ne garantissent pas un service Internet. Ne cherchez pas à régler les liaisons pour les atteindre.
Lisez les identités de liaison fournies et le nouveau score. cat affiche chaque fichier :
cat links.tsv
cat source/score.json
Les deux destinations métier sont 10.205.10.10 pour les scores et 10.205.10.20 pour le multimédia, toutes deux sur le port HTTP 8080. Au départ, les deux routes /32 utilisent lane1. Mesurez la même cible multimédia depuis ce même client par chaque liaison, un test à la fois. ip route replace ne change que cette destination ; via désigne le prochain saut et dev l’interface. ip route get confirme le choix du noyau avant l’envoi de trafic.
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n utilise des adresses numériques, -c 4 s’arrête après quatre requêtes et -W 2 borne chaque attente à deux secondes. Lisez la moyenne et la dispersion du RTT en millisecondes :
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c se connecte au port 5201 du récepteur préparé ; -t 5 lance un test TCP de données de cinq secondes. Le sens par défaut est montant, du client vers le récepteur, comme le travail multimédia. Lisez le débit final receiver. Mbps signifie millions de bits par seconde ; divisez par huit pour estimer les Mo/s avant les surcoûts.
iperf3 -c 10.205.10.20 -t 5
Attendez la fin. Changez maintenant seulement la route multimédia et répétez :
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
ip route get 10.205.10.20
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c 10.205.10.20 -t 5
Rétablissez la route multimédia de départ après l’expérience :
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Vous devriez observer un fort contraste : lane1, environ 11 ms de RTT et 1,9 Mbps ; lane2, environ 180 ms et des dizaines de Mbps. La première découverte des voisins et l’ordonnancement peuvent influencer un échantillon. Si un résultat est proche ou si un test indique un serveur occupé, laissez le test de durée limitée se terminer, confirmez la route et répétez le même échantillon en série. Ne superposez pas les tests et ne changez pas la régulation. Un rapport imprimé ne remplace pas le trafic réel, et les octets iperf ne livrent aucune des nouvelles tâches métier.
Modifier uniquement les routes de destination
Vous traduirez ici la décision de charge fondée sur les mesures en deux routes précises. Commencez dans Event Client. Lane1 fournit le faible RTT nécessaire à la petite interaction de score. Lane2 fournit la capacité montante nécessaire au gros fichier de test sonore. Les deux liaisons doivent rester utilisables.
Lisez toute la table avant de la modifier :
ip route show
Conservez la route par défaut du cours et la destination de référence 10.205.10.30. Vous pouvez remplacer uniquement les routes 10.205.10.10/32 et 10.205.10.20/32. /32 désigne exactement une adresse IPv4 ; une route réseau plus large toucherait d’autres destinations. Le réseau de la plateforme est hors du périmètre.
Explicitez la route des scores avec la forme déjà enseignée replace, via et dev :
ip route replace 10.205.10.10/32 via 10.205.1.1 dev lane1
ip route replace 10.205.10.20/32 via 10.205.2.1 dev lane2
Vérifiez chaque sélection réelle du noyau :
ip route get 10.205.10.10
ip route get 10.205.10.20
Le trafic des scores doit passer par 10.205.1.1 dev lane1 src 10.205.1.2 et le multimédia par 10.205.2.1 dev lane2 src 10.205.2.2. Si une route est incorrecte, répétez uniquement sa commande replace complète avec le bon prochain saut et la bonne interface. Ne videz pas la table et ne changez pas la route par défaut.
Vérifiez la préservation de la route de référence indépendante par une vraie requête :
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
La réponse attendue reste l’originale : warmup, 1–1, preserved. Cet exercice sépare le trafic selon deux adresses de destination distinctes. Il ne distingue pas les applications partageant une même cible, ne configure pas de routage par politiques, n’agrège pas les liaisons et ne choisit pas de fournisseur Internet public.
Livrer les nouveaux scores et fichiers multimédias
Vous livrerez ici le nouveau travail par les routes choisies et comparerez le fichier multimédia reçu en entier. Commencez dans Event Client. Le nouveau score est le match heat-7, domicile 3, extérieur 1. La nouvelle tâche multimédia est opening-sound.wav, une tonalité synthétique originale de 48 secondes pour les essais sonores de répétition. Ses octets PCM WAV mono valides sont préparés ; vous n’avez pas à les encoder ni les modifier.
Lisez le score fourni avant de l’envoyer :
cat source/score.json
Les noms JSON et les chaînes utilisent des guillemets doubles ; les scores sont des nombres. -H fournit le type JSON, et --data-binary @source/score.json lit le fichier exact et réalise le POST. La chaîne -w ajoute les secondes écoulées après l’accusé : \n crée un saut de ligne et %{time_total} est la durée totale de curl. Cela inclut l’établissement de la connexion, pas seulement le RTT.
curl --noproxy '*' -fsS --max-time 35 -H 'Content-Type: application/json' --data-binary @source/score.json -w '\nseconds=%{time_total}\n' http://10.205.10.10:8080/scores
Vous devez voir le bon match et les bons scores, local_ip à 10.205.10.10 et peer_ip à 10.205.1.2. Le peer est la source réellement observée par le récepteur. L’accusé témoigne de cette livraison ; il ne prédit pas le chemin à partir de la route actuelle.
-T envoie le fichier indiqué par PUT au service multimédia. Cela peut prendre quelques secondes ; attendez le résultat :
curl --noproxy '*' -fsS --max-time 35 -T source/opening-sound.wav -w '\nseconds=%{time_total}\n' http://10.205.10.20:8080/media/opening-sound.wav
Vous devez voir le nouveau nom, le nombre d’octets, l’empreinte, local_ip à 10.205.10.20 et peer_ip à 10.205.2.2. Une réponse réussie pour le fichier de démonstration ne terminerait pas cette tâche.
Un POST avec le même identifiant de match remplace ce match ; un PUT avec le même nom multimédia remplace cette tâche. Si vous avez livré par le mauvais chemin, corrigez la route et renvoyez la même tâche. Changer la route après une livraison ne change pas son ancien accusé. Ne modifiez jamais le stockage des accusés ni les fichiers sources pour simuler un résultat.
Lisez les récepteurs indépendamment par GET :
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/receipts
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.20:8080/receipts
Téléchargez le fichier reçu au lieu de copier la source locale. -o enregistre la réponse, cmp compare chaque octet et sha256sum affiche une empreinte pour chaque fichier nommé :
curl --noproxy '*' -fsS --max-time 35 -o received/opening-sound.wav http://10.205.10.20:8080/media/opening-sound.wav
cmp source/opening-sound.wav received/opening-sound.wav
sha256sum source/opening-sound.wav received/opening-sound.wav
cmp ne doit rien afficher et les deux empreintes doivent être identiques. Un fichier vide ou de contenu différent ne correspondra pas à l’audio préparé. Renommer un fichier ne modifie ni ses octets ni son empreinte. Si la comparaison échoue, lisez l’accusé multimédia, répétez le PUT de la source intacte vers la bonne destination, téléchargez à nouveau et comparez.
Passez à Event Receipts, sélectionnez Refresh receipts et recherchez heat-7 avec 3 : 1, le nouveau nom de fichier et les sources de connexion distinctes. Lancez le contrôle Received event audio et utilisez Download received audio pour récupérer les octets du récepteur. Votre navigateur peut être muet ou sans périphérique audio ; la durée affichée et la progression confirment néanmoins qu’il décode le WAV reçu. Démarrez explicitement la lecture ; la page ne la lance pas automatiquement.
Dans la vue finale ci-dessous, comparez les deux valeurs Connection from à côté du nouveau score et de l’audio reçu. Le lecteur affiche la durée réellement décodée et permet de choisir une position de lecture.
Si curl ne peut pas se connecter (code 7) ou dépasse le délai (code 28), revenez à Event Client et revérifiez le résultat ip route get correspondant et l’URL exacte. Un refus HTTP (code 22) est différent : comparez le chemin exact du point d’accès et le fichier JSON ou corps fourni. L’option -f omet le corps d’erreur HTTP ; ne réglez pas le réseau pour corriger un problème de format métier. L’actualisation de la page lit seulement les récepteurs et ne réalise pas les travaux manquants.
Revenez à Event Client et confirmez encore la référence préservée :
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Vous avez livré deux charges différentes par des chemins adaptés tout en préservant les deux liaisons, les octets sources, la régulation préparée, les données de référence et les routes sans rapport. L’évaluation lit les enregistrements métier et les faits réseau natifs existants avant ses sondes GET limitées ; elle n’envoie jamais de scores, ne téléverse pas de fichiers et ne répare aucun chemin.
Résumé
Vous avez choisi des chemins selon la charge, modifié seulement deux routes de destination et livré un nouveau score et un fichier multimédia complet et lisible. Les sources de connexion du récepteur prouvent par où ces livraisons sont arrivées ; une modification ultérieure des routes ne peut pas les réécrire. Vous avez aussi préservé la référence existante et les deux liaisons préparées.
