Einführung
Die Downloadstelle der Gemeinschaft verteilt North-Pier-Feldnotizen und eine Information für Gartenhelfer. Vor dem Schließen möchte ein Helfer einen bereits angenommenen Download fertigstellen lassen. Die erste Implementierung schließt ihre Verbindungen sofort. Sie laden zunächst ein vollständiges, brauchbares Dokument herunter und beobachten dann genau, was ein sofortiger Stopp unterbricht.
Vorausgesetzt werden Go-Funktionen, Handler und Fehlerwerte sowie die Verantwortlichkeiten von Goroutines und Channels aus den beiden vorherigen Projekten oder gleichwertige Erfahrung. Prozessidentität und SIGTERM werden hier eingeführt. Die beiden benannten Terminals sind Sitzungen auf demselben Rechner. Vorbereitete Beobachtungswerkzeuge zeichnen nur den selbst kompilierten Kursserver und dessen curl-Kindprozesse auf; ihr natives Traceformat müssen Sie nicht lernen. Planen Sie etwa 45 Minuten einschließlich Lesen und üblicher Fehler ein; dies ist eine Schätzung des Autors. Jede Einheit beginnt unabhängig.
Laden Sie ein vollständiges Dokument herunter
In diesem Schritt erhalten Sie ein vollständiges, brauchbares Dokument und prüfen seine tatsächlichen Bytes.
Beginnen Sie in Downloads. Beide Terminaleinträge wechseln nur in den vorhandenen Arbeitsbereich; das Öffnen eines Tabs baut die Umgebung nie neu auf. Bei einem gewöhnlichen Verzeichnisfehler führt dieser sichtbare Befehl zurück zum richtigen Ort:
cd /home/labex/project/download-desk
Lesen Sie die beiden Originaltextdateien. Sie enthalten unterschiedliche praktische Unterlagen, nicht zwei Namen für dasselbe Beispiel. cat zeigt Dateiinhalte an, ohne die Dateien zu verändern.
cat documents/north-pier.txt documents/garden-route.txt
Bewahren Sie diese Originale und alle vorbereiteten Dateien während dieser Einheit unverändert auf. Sie dürfen desk kompilieren, benannte beobachtete Versuche starten und Downloads erzeugen. Diese Einheit verändert keinen Go-Quelltext. Jede spätere Einheit stellt eine eigene neue Kopie bereit.
Wechseln Sie zu Server. Das Go-Programm liegt unter seinem absoluten Pfad bereit. build kompiliert dieses Paket; . bezeichnet das aktuelle Paket und -o desk benennt das erzeugte Programm. Ein kompiliertes Binärprogramm macht die Prozessidentität eindeutig, anders als ein Signal an einen go run-Wrapper.
cd /home/labex/project/download-desk
/usr/local/go/bin/go build -o desk .
Starten Sie einen benannten Versuch. Der vorbereitete Beobachter startet Ihr Binärprogramm und zeichnet seinen echten Prozess, HTTP-Anfragen, Signale und nativen Exitstatus auf; er implementiert kein geordnetes Herunterfahren. first ist ein Versuchsname. Vorhandene Namen werden abgelehnt, damit frühere Belege nicht unbemerkt überschrieben werden.
python3 desk.py serve first
Warten Sie auf Ready. Use Downloads for client requests.. Dieses Terminal bleibt bis zum Ende des ursprünglichen Prozesses belegt. Die angezeigte PID gehört zum kompilierten Go-Kindprozess, nicht zum Beobachter. Lassen Sie Server laufen und wechseln Sie zu Downloads.
Der vorbereitete Downloadclient führt echtes curl aus, erfasst dessen natives Prozessergebnis und speichert die tatsächliche Ausgabe. Seine vier Argumente wählen Versuch, neue Ausgabebezeichnung, vorbereitetes Dokument und Verzögerung in Millisekunden pro 32 Bytes. Eine Verzögerung von 0 ist das normale schnelle Beispiel. Die Bezeichnung normal erzeugt downloads/normal.txt.
python3 desk.py download first normal north-pier.txt 0
Erwartet wird Original curl native exit: 0. Null bedeutet, dass die Übertragung abgeschlossen wurde, beweist allein aber nicht den Inhalt. cmp vergleicht die tatsächlichen Dateien Byte für Byte und bleibt bei Gleichheit stumm. Lesen Sie auch das gespeicherte brauchbare Dokument:
cmp documents/north-pier.txt downloads/normal.txt
cat downloads/normal.txt
Meldet der Client eine abgelehnte Verbindung, kehren Sie zu Server zurück und lesen Sie dessen vorhandene Ausgabe. Starten Sie nicht wiederholt einen weiteren Prozess auf demselben Port. Meldet Go einen Buildfehler, korrigieren Sie das Verzeichnis oder vergleichen Sie die vorbereitete Datei vor einem neuen Build. Eine neue Shell erbt keine Variablen einer anderen Shell; Dateien und beobachteter Versuch werden jedoch zwischen diesen Sitzungen geteilt.
Stoppen Sie den ursprünglichen Server während eines angenommenen Downloads
In diesem Schritt unterbrechen Sie eine tatsächlich angenommene Übertragung und unterscheiden den Clientfehler vom Serverende.
Beginnen Sie in Downloads, während Server weiterhin first ausführt. Eine Prozess-ID, kurz PID, bezeichnet einen aktuell laufenden Prozess; nach dessen Ende kann das Betriebssystem sie wiederverwenden. Der Beobachter prüft zusätzlich Programmpfad, aktuelle Benutzer-ID und Linux-Startticks aus /proc, um den ursprünglichen Prozess zu unterscheiden. Senden Sie nur dem selbst kompilierten Kursprozess ein Signal. Verwenden Sie kein pkill, zielen Sie nicht auf den Beobachter und verändern Sie weder Plattformprozesse noch Shellkonfiguration.
SIGTERM ist eine gewöhnliche Aufforderung zur Prozessbeendigung. kill -TERM PID sendet sie an genau eine PID. Der Befehl wartet weder selbst auf Downloads noch beweist er das Prozessende. Das vorbereitete Go-Programm empfängt das Signal, ruft sofort Close auf und kehrt aus main zurück. Dies ist das zu beobachtende Verhalten, kein Netzausfall.
Lesen Sie den restlichen Schritt einschließlich erwarteter Fehler und Wiederherstellung, bevor Sie die langsame Übertragung starten. Führen Sie danach die Blöcke nacheinander aus; lernen Sie nicht erst während dieser zeitlich begrenzten Anfrage den nächsten Begriff. Das Zeitfenster für dieses Dokument beträgt ungefähr eine halbe Minute, nicht unbegrenzt lange.
Starten Sie einen zeitlich begrenzten langsamen Download im Hintergrund. & lässt diese Shell den nächsten Befehl annehmen, während der Client läuft; $! ist die Prozess-ID des letzten Hintergrundjobs. Die Zuweisung speichert diesen Beobachterjob, damit wait später dessen natives Ergebnis lesen kann. Die offen angegebene Verzögerung von 300ms liegt zwischen 32-Byte-Schreibvorgängen und lässt Zeit zum Lesen und Tabwechsel; dies ist eine kontrollierte Trainingsübertragung, keine Leistungsmessung.
python3 desk.py download first interrupted north-pier.txt 300 & download_job=$!
Bitten Sie den Beobachter vor jedem Stopp, die bereits aufgezeichnete native Anfrage zu lesen. Dieser Befehl sendet weder eine Ersatzanfrage noch ein Signal. Er muss melden, dass der ursprüngliche Server diesen echten Client angenommen hat und beide Identitäten noch vorhanden sind. curl kann kleine Dateischreibvorgänge puffern; eine vorübergehend leere Ausgabedatei bedeutet daher nicht, dass die Anfrage nie begonnen hat.
python3 desk.py accepted first interrupted
Ermitteln und prüfen Sie nun die ursprüngliche Identität. $(...) speichert die vom Befehl ausgegebene PID in einer Shellvariablen; das später in Anführungszeichen gesetzte "$server_pid" übergibt sie als ein Argument. Das Hilfsprogramm lehnt eine veraltete Kombination aus PID/Start/Programm/UID ab.
server_pid=$(python3 desk.py pid first)
python3 desk.py identity first
Senden Sie das genaue Signal erst nach der Beobachtung der angenommenen Anfrage:
kill -TERM "$server_pid"
Lesen Sie das Ergebnis des ursprünglichen Clients. wait wartet auf den Hintergrundjob dieser Shell. Der nächste Befehl soll 18 zurückgeben, zusammen mit curls Meldung über fehlende Bytes. Das ist eine abgeschlossene Beobachtung einer fehlgeschlagenen Übertragung, kein Fehler, den Sie durch eine Erfolgsmeldung verdecken sollten.
wait "$download_job"
echo $? zeigt sofort den vorherigen nativen Status an, erwartet wird 18. Ein später erfolgreiches cat würde diesen Shellstatus ersetzen; lesen Sie ihn deshalb unmittelbar:
echo $?
cat downloads/interrupted.txt
Vergleichen Sie mit dem Original:
cmp documents/north-pier.txt downloads/interrupted.txt
Dieser Vergleich soll 1 zurückgeben und ein vorzeitiges Dateiende melden. Der empfangene Text beginnt mit echtem North-Pier-Inhalt, ist aber unvollständig. Ein passender Dateiname oder eine nicht leere Datei beweist somit keinen vollständigen brauchbaren Download. Wechseln Sie zu Server und lesen Sie Original server native exit: 0. Auch ein normal beendeter Server kann seine Clients unterbrochen haben.
Kehren Sie zu Downloads zurück und behalten Sie beide Ergebnisse. Die Kursprüfung liest nur vorhandene Beobachtungen und tatsächliche Dateien; sie stoppt niemals einen laufenden Prozess und erzeugt keine fehlende Unterbrechung für Sie.
Falls die langsame Übertragung vor dem Signal bereits fertig war, nennen Sie das keine Unterbrechung. Lesen Sie ihr natives Ergebnis 0, vergleichen Sie die vollständigen Bytes und behalten Sie die Datei. Läuft first noch, starten Sie denselben langsamen Befehl mit einer neuen Bezeichnung wie interrupted2, speichern den neuen Hintergrundjob und verwenden diese Bezeichnung vor dem Signal auch in accepted. Ist der ursprüngliche Server schon beendet, wechseln Sie zu Server und starten ausdrücklich einen neuen Versuch wie retry1, ohne den alten zu entfernen; verwenden Sie anschließend diesen Versuchsnamen und eine neue Ausgabebezeichnung in download, accepted, pid und identity. Die Prüfung akzeptiert diese neuen Namen. Wiederholen Sie eine echte Beobachtung, statt eine Teildatei zu kopieren. Eine beendete oder unbekannte Übertragung erlaubt kein weiteres Signal an eine wiederverwendete PID.
Hier ist ein vollständiger Neuversuch im weiterhin laufenden Versuch first. Nutzen Sie ihn erst nach dem tatsächlichen Ende des alten Clients; behalten Sie downloads/interrupted.txt. Lesen Sie vorher alle folgenden Blöcke. Die neue Bezeichnung erzeugt eine separate Ausgabe:
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"
Auch das nächste wait soll 18 liefern; lesen Sie den Status sofort und vergleichen Sie dann die neue tatsächliche Teildatei (Vergleich erwartet 1):
wait "$download_job"
echo $?
cmp documents/north-pier.txt downloads/interrupted2.txt
Ist first bereits beendet, starten Sie stattdessen einen anderen Versuch in Server:
python3 desk.py serve retry1
Nutzen Sie nach der Bereitschaftsmeldung diese vollständige Folge in Downloads, mit einer dritten neuen Ausgabebezeichnung:
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 $?
wait soll 18 zurückgeben. Bewahren Sie die tatsächliche Ausgabe auf und prüfen Sie ihre Unvollständigkeit (Vergleich erwartet 1):
cmp documents/north-pier.txt downloads/interrupted3.txt
Beenden Sie den Schritt mit der gestoppten ursprünglichen Downloadstelle und erhaltenen Ergebnissen. Der normale Download ist vollständig und bleibt lesbar; lassen Sie vor der Prüfung keinen Ersatzlistener laufen. Die nächste unabhängige Einheit zeigt, wie aktive Übertragungen erhalten bleiben.
Zusammenfassung
Sie haben einen echten vollständigen Download beobachtet und danach eine unterbrochene Übertragung dem gezielten Stopp ihres ursprünglichen Servers zugeordnet. Eine abgelehnte Verbindung, eine Teilübertragung und ein normaler Prozessabschluss beschreiben unterschiedliche Tatsachen.
