Introduction
Le comptoir communautaire distribue des notes de terrain de North Pier et une fiche destinée aux bénévoles du jardin. Avant sa fermeture, un bénévole souhaite laisser finir un téléchargement déjà accepté. La première implémentation ferme immédiatement ses connexions. Vous obtiendrez d'abord un document complet et utile, puis observerez précisément ce qu'interrompt un arrêt immédiat.
Vous devez connaître les fonctions, gestionnaires et valeurs d'erreur de Go, ainsi que les responsabilités des goroutines et canaux présentées dans les deux projets précédents, ou posséder une expérience équivalente. L'identité des processus et SIGTERM sont introduits ici. Les deux terminaux nommés sont des sessions sur la même machine. Les outils préparés enregistrent uniquement le serveur compilé du cours et ses processus enfants curl ; vous n'avez pas à apprendre leur format de traces natives. Prévoyez environ 45 minutes, lecture et erreurs courantes comprises ; il s'agit d'une estimation de l'auteur. Chaque unité démarre indépendamment.
Téléchargez un document complet
Dans cette étape, obtenez un document complet et utile, puis vérifiez ses octets réels.
Commencez dans Downloads. Les deux entrées de terminal ouvrent uniquement l'espace de travail existant ; ouvrir un onglet ne reconstruit jamais le scénario. En cas d'erreur ordinaire de répertoire, cette commande visible vous ramène au bon endroit :
cd /home/labex/project/download-desk
Lisez les deux fichiers texte originaux. Ils contiennent des documents pratiques différents, et non deux noms pour le même exemple. cat affiche leur contenu sans modifier les fichiers.
cat documents/north-pier.txt documents/garden-route.txt
Conservez ces originaux et tous les fichiers préparés sans modification pendant cette unité. Vous pouvez compiler desk, lancer des essais observés nommés et créer des téléchargements. Cette unité ne modifie aucun code Go. Chaque unité suivante fournit sa propre copie neuve.
Passez à Server. L'exécutable Go est disponible à son chemin absolu. build compile ce paquet ; . désigne le paquet courant et -o desk nomme l'exécutable produit. Un binaire compilé rend explicite l'identité du processus, contrairement à l'envoi d'un signal à un intermédiaire go run.
cd /home/labex/project/download-desk
/usr/local/go/bin/go build -o desk .
Lancez un essai nommé. L'observateur fourni démarre votre binaire et enregistre son processus réel, ses requêtes HTTP, ses signaux et sa sortie native ; il n'implémente pas l'arrêt progressif. first est un nom d'essai. Les noms existants sont refusés pour éviter d'écraser silencieusement les preuves précédentes.
python3 desk.py serve first
Attendez Ready. Use Downloads for client requests.. Ce terminal reste occupé jusqu'à la sortie du processus d'origine. Le PID affiché est celui de l'enfant Go compilé, pas de l'observateur. Laissez Server fonctionner et passez à Downloads.
Le client préparé exécute réellement curl, enregistre le résultat natif de son processus et sauvegarde sa sortie effective. Ses quatre arguments choisissent l'essai, une nouvelle étiquette de sortie, un document préparé et un délai en millisecondes par tranche de 32 octets. Le délai 0 correspond à l'exemple rapide normal. L'étiquette normal produit downloads/normal.txt.
python3 desk.py download first normal north-pier.txt 0
Vous devez voir Original curl native exit: 0. Zéro indique un transfert terminé, sans suffire à prouver son contenu. cmp compare les fichiers réels octet par octet et n'affiche rien s'ils sont identiques. Lisez également le document utile sauvegardé :
cmp documents/north-pier.txt downloads/normal.txt
cat downloads/normal.txt
Si le client signale une connexion refusée, revenez à Server et lisez sa sortie existante. Ne relancez pas sans cesse un autre processus sur le même port. Si Go signale une erreur de compilation, corrigez le répertoire ou comparez le fichier préparé avant de recompiler. Un nouveau shell n'hérite pas des variables d'un autre, mais les fichiers et l'essai observé sont partagés entre ces deux sessions.
Arrêtez le serveur d'origine pendant un téléchargement accepté
Dans cette étape, interrompez un transfert réellement accepté et distinguez l'échec du client de la sortie du serveur.
Commencez dans Downloads pendant que Server exécute encore first. Un identifiant de processus, ou PID, désigne un processus actuellement en cours, mais le système peut réutiliser ce numéro après sa sortie. L'observateur vérifie aussi le chemin de l'exécutable, l'identifiant de l'utilisateur actuel et les ticks de démarrage Linux dans /proc pour distinguer le processus d'origine. Ne signalez que le processus compilé de ce cours. N'utilisez pas pkill, ne ciblez pas l'observateur et ne modifiez ni processus de la plateforme ni configuration du shell.
SIGTERM est une demande ordinaire de terminaison. kill -TERM PID l'envoie à un PID précis. Cette commande n'attend pas elle-même les téléchargements et ne prouve pas la fin du processus. Le programme Go préparé reçoit le signal, appelle immédiatement Close, puis retourne de main. C'est le comportement à observer, pas une panne réseau.
Lisez la suite de l'étape, y compris les échecs attendus et la récupération, avant de lancer le transfert lent. Exécutez ensuite les blocs dans l'ordre ; n'apprenez pas le concept suivant pendant cette requête de durée finie. Pour ce document, la fenêtre est d'environ une demi-minute, sans attente illimitée.
Lancez un téléchargement lent fini en arrière-plan. & permet au shell d'accepter la commande suivante pendant l'exécution du client ; $! est le PID du dernier travail en arrière-plan et l'affectation conserve ce travail observateur afin que wait lise ensuite son résultat natif. Le délai public de 300ms se situe entre les écritures de 32 octets et laisse le temps de lire et de changer d'onglet ; c'est un transfert d'entraînement contrôlé, pas une mesure de performances.
python3 desk.py download first interrupted north-pier.txt 300 & download_job=$!
Avant tout arrêt, demandez à l'observateur de lire la requête native déjà enregistrée. Cette commande n'envoie ni requête de remplacement ni signal. Elle doit annoncer que le serveur d'origine a accepté ce client réel et que les deux identités sont encore présentes. curl peut mettre en tampon les petites écritures ; un fichier temporairement vide ne signifie donc pas que la requête n'a jamais démarré.
python3 desk.py accepted first interrupted
Obtenez et inspectez l'identité d'origine. $(...) place le PID affiché par cette commande dans une variable du shell ; "$server_pid", entre guillemets, le transmettra ensuite comme un seul argument. L'outil refuse une combinaison périmée PID/démarrage/exécutable/UID.
server_pid=$(python3 desk.py pid first)
python3 desk.py identity first
N'envoyez le signal précis qu'après avoir observé la requête acceptée :
kill -TERM "$server_pid"
Lisez le résultat du client d'origine. wait attend le travail en arrière-plan de ce shell. La commande suivante doit renvoyer 18, accompagnée du message curl sur les octets manquants. C'est une observation achevée d'un transfert échoué, pas un échec à masquer par un marqueur de réussite.
wait "$download_job"
echo $? affiche immédiatement le statut natif précédent, attendu à 18. Un cat réussi ensuite remplacerait ce statut du shell ; lisez-le donc aussitôt :
echo $?
cat downloads/interrupted.txt
Comparez avec l'original :
cmp documents/north-pier.txt downloads/interrupted.txt
Cette comparaison doit renvoyer 1 et indiquer la fin prématurée du fichier partiel. Le texte reçu commence bien par du contenu North Pier réel, mais reste incomplet. Un nom identique ou un fichier non vide ne prouvent donc pas un téléchargement complet et utile. Passez à Server et lisez Original server native exit: 0. Un serveur sorti normalement peut néanmoins avoir interrompu ses clients.
Revenez à Downloads et conservez les deux résultats. La vérification ne fait que lire les observations existantes et les fichiers réels ; elle n'arrête jamais un processus actif et ne crée pas pour vous l'interruption manquante.
Si le transfert a terminé avant le signal parce que vous avez attendu, ne le qualifiez pas d'interruption. Lisez son résultat natif 0, comparez ses octets complets et conservez-le. Si first fonctionne encore, relancez la même commande lente avec une nouvelle étiquette, par exemple interrupted2, sauvegardez son nouveau travail et utilisez cette même étiquette dans accepted avant le signal. Si le serveur d'origine est déjà sorti, passez à Server et lancez explicitement un autre essai, tel que retry1, en conservant l'ancien ; utilisez ensuite ce nom et une nouvelle étiquette dans les commandes download, accepted, pid et identity. La vérification accepte ces nouveaux noms. Répétez l'observation réelle au lieu de copier un fichier partiel. Un transfert terminé ou inconnu n'autorise pas un nouveau signal vers un PID recyclé.
Voici la reprise complète sur le même essai first encore actif. Ne l'utilisez qu'après la fin réelle de l'ancien client ; conservez downloads/interrupted.txt. Lisez tous les blocs avant de commencer. La nouvelle étiquette produit une sortie distincte :
python3 desk.py download first interrupted2 north-pier.txt 300 & download_job=$!
python3 desk.py accepted first interrupted2
server_pid=$(python3 desk.py pid first)
python3 desk.py identity first
kill -TERM "$server_pid"
L'attente suivante doit encore renvoyer 18 ; lisez immédiatement ce résultat, puis comparez le nouveau fichier partiel réel (comparaison attendue à 1) :
wait "$download_job"
echo $?
cmp documents/north-pier.txt downloads/interrupted2.txt
Si first est déjà sorti, lancez plutôt un essai distinct dans Server :
python3 desk.py serve retry1
Après son message de disponibilité, utilisez cette séquence complète dans Downloads, avec une troisième étiquette neuve :
python3 desk.py download retry1 interrupted3 north-pier.txt 300 & download_job=$!
python3 desk.py accepted retry1 interrupted3
server_pid=$(python3 desk.py pid retry1)
python3 desk.py identity retry1
kill -TERM "$server_pid"
wait "$download_job"
echo $?
L'attente doit renvoyer 18. Conservez la sortie réelle et vérifiez qu'elle est incomplète (comparaison attendue à 1) :
cmp documents/north-pier.txt downloads/interrupted3.txt
Terminez avec le comptoir d'origine arrêté et les résultats conservés. Votre téléchargement normal est complet et reste lisible ; ne laissez pas un listener de remplacement fonctionner avant la vérification. L'unité indépendante suivante enseigne à préserver les transferts actifs.
Résumé
Vous avez observé un téléchargement réel complet, puis relié une interruption de transfert à l'arrêt précis de son serveur d'origine. Une connexion refusée, un transfert partiel et la sortie normale d'un processus décrivent des faits différents.
