Einführung
Willow Games ist bereit für einen neuen Durchgang. Der Spielstandstisch braucht reaktionsschnelle Interaktionen; der Medientisch eine vollständige Audioübertragung für die Probe. Beide Verbindungen funktionieren, doch die Ausgangsrouten senden beide Aufgaben über eine Verbindung.
Du wiederholst kurze Messungen in einer frisch vorbereiteten Umgebung, wählst getrennte Zielrouten und sendest den neuen Spielstand und das vollständige Audio. Absolviere zuerst Den Netzwerkbedarf jeder Veranstaltungsaufgabe messen oder bringe gleichwertige Kenntnisse in ping, iperf3 und begrenzten IPv4-Routen mit. Programmierung und Medienkodierung sind nicht erforderlich.
Nutze Event Client für Befehle und Event Receipts zum Anzeigen und Abspielen tatsächlich empfangener Inhalte. Nur die zwei genannten Zielrouten und deine neuen Übermittlungen dürfen geändert werden. Die 45 Minuten sind eine Schätzung des Autors; die isolierten Knoten teilen einen Kernel und bilden kabelgebundene virtuelle Pfade ab, keine Messungen öffentlicher Anbieter.
Nach der vorgegebenen Arbeitslast auswählen
In diesem Schritt misst du die vorbereiteten Verbindungen und wählst für jede Aufgabe eine aus. Beginne in Event Client, bereits in /home/labex/project/event-links. Dieses Lab hat ein eigenes neues Netzwerk und eigene Dateien. Vorausgesetzt werden die Verzögerungs- und Durchsatzwerkzeuge aus Den Netzwerkbedarf jeder Veranstaltungsaufgabe messen sowie grundlegendes Lesen von Zielrouten; keine Dateien oder laufenden Prozesse werden übernommen.
Sieh dir zuerst die normale Funktion an, die erhalten bleiben muss. Der Spielstandstisch hat bereits einen Aufwärmeintrag. curl --noproxy '*' umgeht Proxies, -fsS schlägt bei HTTP-Fehlern mit Fehlermeldungen fehl und --max-time 35 begrenzt die Übertragung:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
Erwarte den erhaltenen Spielstand warmup mit 1–1. Wechsle zu Event Receipts. Die beiden Hauptkarten warten auf heat-7 und opening-sound.wav; die Seite wertet das Aufwärmen nicht als erledigte neue Aufgabe. Kehre zu Event Client zurück.
Der Spielstandstisch braucht kurze Interaktionen: Wähle die Verbindung mit beständig niedriger RTT und einem Stichprobenmittel deutlich unter dem Planungsbudget von 80 ms. Das Medienteam braucht Kapazität für große Uploads: Wähle den Pfad mit einem Empfängerdurchsatz deutlich über 10 Mbps in diesem vorbereiteten Szenario. Diese großzügigen Budgets lenken deine Entscheidung; sie sind keine Internetdienstgarantie. Versuche nicht, die Verbindungen darauf abzustimmen.
Lies die bereitgestellten Verbindungskennungen und den neuen Spielstand. cat zeigt jede Datei:
cat links.tsv
cat source/score.json
Die beiden Geschäftsziele sind 10.205.10.10 für Spielstände und 10.205.10.20 für Medien, beide auf HTTP-Port 8080. Anfangs verwenden beide /32-Routen lane1. Miss dasselbe Medienziel von diesem selben Client über jede Verbindung, immer nur einen Test gleichzeitig. ip route replace ändert nur dieses Ziel; via benennt den nächsten Hop und dev die Schnittstelle. ip route get bestätigt die Kernelauswahl vor dem Senden von Verkehr.
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n nutzt numerische Adressen, -c 4 stoppt nach vier Anfragen und -W 2 begrenzt jede Antwortwartezeit auf zwei Sekunden. Lies RTT-Mittelwert und Streuung in Millisekunden:
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c verbindet sich mit Port 5201 des vorbereiteten Empfängers; -t 5 führt einen fünfsekündigen TCP-Datentest aus. Standardmäßig sendet der Client zum Empfänger, passend zur Medienaufgabe. Lies die letzte receiver-Bitrate. Mbps bedeutet Millionen Bits pro Sekunde; geteilt durch acht erhältst du ungefähr MB/s vor zusätzlichem Aufwand.
iperf3 -c 10.205.10.20 -t 5
Warte auf das Ende. Ändere jetzt nur die Medienroute und wiederhole:
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
Stelle die anfängliche Medienroute nach dem Versuch wieder her:
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
Du solltest einen großen Unterschied sehen: lane1 etwa 11 ms RTT und 1,9 Mbps, lane2 etwa 180 ms und mehrere zehn Mbps. Erste Nachbarerkennung und Zeitplanung können einzelne Messungen beeinflussen. Ist ein Ergebnis knapp oder meldet ein Test einen belegten Server, lasse den zeitlich begrenzten Test enden, bestätige die Route und wiederhole dieselbe Messung nacheinander. Überlagere keine Tests und ändere nicht die Verkehrsformung. Ein gedruckter Bericht ersetzt keinen echten Verkehr; iperf-Testbytes liefern keine der neuen Geschäftsaufgaben.
Nur die Zielrouten ändern
In diesem Schritt setzt du die gemessene Entscheidung für die Arbeitslasten in zwei konkrete Routen um. Beginne in Event Client. Lane1 bietet die niedrige RTT für die kleine Spielstandsinteraktion. Lane2 bietet die Upload-Kapazität für die große Soundcheck-Datei. Beide Verbindungen müssen nutzbar bleiben.
Lies vor Änderungen die vollständige Tabelle:
ip route show
Lasse die Kursstandardroute und das Referenzziel 10.205.10.30 unverändert. Du darfst nur die Routen 10.205.10.10/32 und 10.205.10.20/32 ersetzen. /32 bedeutet genau eine IPv4-Adresse; eine breitere Netzroute würde weitere Ziele beeinflussen. Das Plattformnetz liegt außerhalb dieser Aufgabe.
Lege die Spielstandsroute mit der bereits gelernten Form aus replace, via und dev ausdrücklich fest:
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
Prüfe jede tatsächliche Kernelauswahl:
ip route get 10.205.10.10
ip route get 10.205.10.20
Erwarte Spielstandsverkehr über 10.205.1.1 dev lane1 src 10.205.1.2 und Medienverkehr über 10.205.2.1 dev lane2 src 10.205.2.2. Ist eine Auswahl falsch, wiederhole nur deren vollständigen replace-Befehl mit richtigem nächsten Hop und richtiger Schnittstelle. Leere nicht die Tabelle und ändere nicht die Standardroute.
Prüfe den Erhalt der unabhängigen Referenzroute mit einer echten Anfrage:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Erwarte die ursprüngliche Antwort warmup, 1–1, preserved. Diese Übung trennt Verkehr anhand zweier unterschiedlicher Zieladressen. Sie unterscheidet keine Anwendungen mit derselben Zieladresse, richtet kein Policy-Routing ein, bündelt keine Verbindungen und wählt keinen öffentlichen ISP.
Neue Spielstände und Medien übertragen
In diesem Schritt überträgst du die neuen Aufgaben über die gewählten Routen und vergleichst das vollständig empfangene Medium. Beginne in Event Client. Der neue Spielstand gehört zu heat-7, Heim 3, Auswärts 1. Die neue Medienaufgabe heißt opening-sound.wav, ein selbst erstellter synthetischer Soundcheck-Ton von 48 Sekunden für die Probe. Seine gültigen Mono-PCM-WAV-Bytes sind vorbereitet; du kodierst oder bearbeitest sie nicht.
Lies den bereitgestellten Spielstand vor dem Senden:
cat source/score.json
JSON-Namen und Zeichenketten verwenden doppelte Anführungszeichen; Spielstände sind Zahlen. -H setzt den JSON-Inhaltstyp, und --data-binary @source/score.json liest genau die Datei und führt POST aus. Die Zeichenkette -w ergänzt nach dem Beleg die verstrichenen Sekunden: \n erzeugt einen Zeilenumbruch und %{time_total} ist die curl-Gesamtzeit. Sie enthält auch den Verbindungsaufbau, nicht nur 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
Erwarte das richtige Spiel mit richtigen Punkten, local_ip von 10.205.10.10 und peer_ip von 10.205.1.2. Der Peer ist die Quelle, die der Empfänger tatsächlich beobachtete. Der Beleg ist ein Nachweis dieser Übertragung, keine Vorhersage anhand der aktuellen Route.
-T lädt die angegebene Datei mit PUT zum Mediendienst hoch. Das kann einige Sekunden dauern; warte auf das Ergebnis:
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
Erwarte neuen Dateinamen, Bytezahl, Inhaltsprüfsumme, local_ip von 10.205.10.20 und peer_ip von 10.205.2.2. Eine Erfolgsmeldung für die Beispieldatei würde diese Aufgabe nicht abschließen.
Ein POST mit derselben Spiel-ID ersetzt dieses Spiel; ein PUT mit demselben Mediennamen ersetzt diese Medienaufgabe. Hast du über den falschen Pfad gesendet, korrigiere die Route und sende dieselbe Aufgabe erneut. Eine Routenänderung nach der Übertragung ändert deren alten Beleg nicht. Bearbeite niemals Belegspeicher oder Quelldateien, um ein Ergebnis vorzutäuschen.
Lies die Empfänger unabhängig mit 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
Lade das empfangene Medium herunter, statt die lokale Quelle zu kopieren. -o speichert die Antwort, cmp vergleicht jedes Byte und sha256sum zeigt eine Prüfsumme für jede benannte Datei:
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
Erwarte keine Ausgabe von cmp und zwei identische Prüfsummen. Eine leere Datei oder eine Datei mit anderem Inhalt stimmt nicht mit dem vorbereiteten Audio überein. Das Umbenennen einer Datei ändert weder ihre Bytes noch ihren Hash. Schlägt der Vergleich fehl, lies den Medienbeleg, wiederhole den PUT der unveränderten Quelle an das richtige Ziel, lade erneut herunter und vergleiche.
Wechsle zu Event Receipts, wähle Refresh receipts und suche heat-7 mit 3 : 1, den neuen Mediennamen und die unterschiedlichen Verbindungsquellen. Starte die Wiedergabe über Received event audio und nutze Download received audio, um die Bytes des Empfängers abzurufen. Dein Browser kann stummgeschaltet sein oder kein Audiogerät haben; Daueranzeige und fortschreitende Wiedergabe bestätigen dennoch, dass er die empfangene WAV dekodiert. Starte die Wiedergabe ausdrücklich; die Seite spielt nicht automatisch ab.
Vergleiche in der folgenden Endansicht die beiden Werte Connection from neben neuem Spielstand und empfangenem Audio. Die Audiosteuerung zeigt die tatsächlich dekodierte Dauer und lässt dich eine Wiedergabeposition auswählen.
Kann curl keine Verbindung aufbauen (Code 7) oder läuft die Zeit ab (Code 28), kehre zu Event Client zurück und prüfe das passende Ergebnis von ip route get sowie die genaue URL erneut. Eine HTTP-Ablehnung (Code 22) ist etwas anderes: Vergleiche den genauen Endpunktpfad und die bereitgestellte JSON- oder Körperdatei. Die Option -f lässt den HTTP-Fehlerkörper weg; stimme nicht das Netzwerk ab, um einen Fehler im Geschäftsformat zu beheben. Das Aktualisieren der Seite liest nur Empfänger und erledigt keine fehlende Aufgabe.
Kehre zu Event Client zurück und bestätige die erhaltene Referenz noch einmal:
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
Du hast zwei unterschiedliche Arbeitslasten über geeignete Pfade übertragen und beide Verbindungen, Quellbytes, vorbereitete Verkehrsformung, Referenzdaten und andere Routen erhalten. Die Bewertung liest vorhandene Geschäftseinträge und native Netzwerkfakten vor ihren begrenzten GET-Abfragen; sie sendet niemals Spielstände, lädt keine Dateien hoch und repariert keinen Pfad.
Zusammenfassung
Du hast Pfade nach Arbeitslast gewählt, nur zwei Zielrouten geändert und einen neuen Spielstand sowie vollständige abspielbare Medien übertragen. Die Verbindungsquellen am Empfänger belegen, wo diese Übertragungen ankamen; spätere Routenänderungen können sie nicht umschreiben. Du hast auch die vorhandene Referenz und beide vorbereiteten Verbindungen erhalten.
