はじめに
Willow Gamesは新しいヒートの準備ができました。スコアデスクは応答の良いやり取りを、メディアデスクは完全なリハーサル音声の納品を必要としています。2本のリンクは動作していますが、初期経路は両方の作業を1本へ送ります。
新しく準備された環境で短い測定を繰り返し、宛先別の経路を選び、新しいスコアと完全な音声を送信します。先に イベントの各作業に必要な通信性能を測る を完了するか、同等のping、iperf3、対象を限定したIPv4経路のスキルを用意してください。プログラミングとメディアエンコードは不要です。
コマンドには Event Client、実際に受信した内容の表示・再生には Event Receipts を使います。編集可能なのは指定された2つの宛先経路と新しい送信だけです。45分は著者の見積もりです。隔離ノードはカーネルを共有する有線の仮想経路であり、公共事業者を測定するものではありません。
指定されたワークロードに合わせて選ぶ
このステップでは用意されたリンクを測り、各作業に1本を選びます。すでに /home/labex/project/event-links にいる Event Client から始めます。この実験には独自の新しいネットワークとファイルがあります。イベントの各作業に必要な通信性能を測る の遅延・スループット用ツールと基本的な宛先経路の読み方を前提とし、ファイルや実行中プロセスは引き継ぎません。
最初に、維持すべき正常な機能を見ます。スコアデスクにはすでにウォームアップの記録があります。curl --noproxy '*' はプロキシを迂回し、-fsS はHTTPエラーで失敗してエラーを表示し、--max-time 35 は転送時間を制限します。
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.10:8080/reference
保持された warmup の 1–1 が期待値です。Event Receipts に切り替えます。メインの2枚のカードは heat-7 と opening-sound.wav を待っています。ページはウォームアップを新しい作業の完了とは扱いません。Event Client に戻ってください。
スコアデスクには短いやり取りが必要です。RTTが一貫して低く、サンプル平均が計画上の予算80 msを十分下回るリンクを選びます。メディア担当には大量アップロードの能力が必要です。この準備場面で受信側スループットが10 Mbpsを十分上回る経路を選びます。これらの幅を持たせた予算は判断の目安で、インターネットサービスの保証ではありません。達成するためにリンクを調整しないでください。
提供されたリンク識別情報と新しいスコアを読みます。cat は各ファイルを表示します。
cat links.tsv
cat source/score.json
業務の宛先はスコア用の 10.205.10.10 とメディア用の 10.205.10.20 で、どちらもHTTPポート 8080 を使います。最初は両方の /32 経路がlane1を使います。同じクライアントから同じメディア宛先を各リンクで、1テストずつ測定します。ip route replace はその宛先だけを変更し、via はネクストホップ、dev はインターフェースを指定します。トラフィックを送る前に ip route get でカーネルの選択を確認します。
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
ping -n は数値アドレスを使い、-c 4 は4回の要求で停止し、-W 2 は各応答の待ち時間を2秒に制限します。RTTの平均とばらつきをミリ秒で読みます。
ping -n -c 4 -W 2 10.205.10.20
iperf3 -c は準備された受信側のポート 5201 に接続し、-t 5 は5秒間のTCPデータテストを実行します。デフォルトはクライアントから受信側へのアップロードで、メディアの作業と一致します。最後の receiver のビットレートを読みます。Mbpsは毎秒数百万ビットで、8で割ると付加分を除く前のおよそのMB/sです。
iperf3 -c 10.205.10.20 -t 5
完了を待ちます。次にメディア経路だけを変更して繰り返します。
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
実験後、開始時のメディア経路を復元します。
ip route replace 10.205.10.20/32 via 10.205.1.1 dev lane1
ip route get 10.205.10.20
lane1は約11 ms RTT・約1.9 Mbps、lane2は約180 ms・数十Mbpsという大きな違いが見えるはずです。初回の近隣探索やスケジューリングは1回の結果に影響します。結果が近い場合やサーバーが使用中の場合は、時間限定のテストの終了を待ち、経路を確認して同じ測定を順番に繰り返します。テストを重ねたり整形を変更したりしないでください。印刷したレポートは実際の通信の代わりにならず、iperfのテスト用バイトはどちらの新しい業務タスクも届けていません。
宛先経路だけを変更する
このステップでは測定に基づくワークロードの判断を2つの具体的な経路に反映します。Event Client から始めます。lane1は小さなスコア交信に必要な低RTTを、lane2は大きな試音ファイルに必要なアップロード能力を提供します。両リンクを使用可能なまま維持してください。
編集前に表全体を読みます。
ip route show
コースのデフォルト経路と参照宛先 10.205.10.30 は変更しません。置き換えてよいのは 10.205.10.10/32 と 10.205.10.20/32 の経路だけです。/32 はIPv4アドレス1つだけを意味します。より広いネットワーク経路は他の宛先に影響します。プラットフォームのネットワークはこのタスクの範囲外です。
学習済みの replace、via、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
カーネルの実際の選択をそれぞれ確認します。
ip route get 10.205.10.10
ip route get 10.205.10.20
スコアは 10.205.1.1 dev lane1 src 10.205.1.2、メディアは 10.205.2.1 dev lane2 src 10.205.2.2 が期待値です。片方が誤っていたら、正しいネクストホップとインターフェースを使い、その完全な replace コマンドだけをやり直します。表の全消去やデフォルトの変更はしないでください。
実際の要求で、独立した参照経路の維持を確認します。
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
元の warmup、1–1、preserved が期待値です。この演習は2つの異なる宛先アドレスで通信を分けます。同一宛先を共有するアプリケーションの区別、ポリシールーティング、リンクの集約、公共ISPの選定は行いません。
新しいスコアとメディアを届ける
このステップでは選んだ経路で新しい作業を届け、受信メディア全体を比較します。Event Client から始めます。新スコアは試合 heat-7、ホーム 3、アウェイ 1 です。新メディアタスクは opening-sound.wav で、独自に作成された48秒の合成リハーサル試音音です。有効なモノラルPCM WAVのバイト列は準備されており、エンコードや編集はしません。
送信前に提供されたスコアを読みます。
cat source/score.json
JSONの名前と文字列値は二重引用符を使い、スコアは数値です。-H はJSONコンテンツタイプを指定し、--data-binary @source/score.json はそのファイルをそのまま読みPOSTします。-w の文字列は受領記録の後に経過秒を追加します。\n は改行、%{time_total} はcurlの合計時間です。これは接続確立も含み、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
試合とスコアが正しく、local_ip が 10.205.10.10、peer_ip が 10.205.1.2 であることを確認します。peerは受信側が実際に見た送信元です。受領記録は今回の送信の証拠であり、現在の経路からの予測ではありません。
-T は指定ファイルをPUTでメディアサービスへアップロードします。数秒かかることがあるので、結果を待ちます。
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
新しいファイル名、バイト数、内容ダイジェスト、local_ip の 10.205.10.20、peer_ip の 10.205.2.2 が期待値です。デモファイルの成功応答ではこのタスクは完了しません。
同じ試合IDのPOSTはその試合を、同じメディア名のPUTはそのタスクを置き換えます。誤った経路で送った場合、経路を修正して同じタスクを再送します。送信後に経路を変えても、古い受領記録は変わりません。結果を装うために受領記録の保存先や元ファイルを編集してはいけません。
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
ローカルの元ファイルをコピーするのではなく、受信済みメディアをダウンロードします。-o は応答を保存し、cmp は全バイトを比較し、sha256sum は指定した各ファイルのダイジェストを表示します。
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 は何も表示せず、2つのダイジェスト文字列は一致するはずです。空のファイルや内容が異なるファイルは、準備した音声と一致しません。名前を変更しても、ファイルのバイト列やハッシュは変わりません。比較が失敗したら、メディア受領記録を読み、未変更の元ファイルを正しい宛先へ再度PUTし、再ダウンロードして比較します。
Event Receipts に切り替え、Refresh receipts を選び、heat-7 の 3 : 1、新メディア名、異なる接続元を探します。Received event audio を再生し、Download received audio で受信側のバイトを取得します。ブラウザーがミュート中、または音声機器がなくても、表示される長さと進む再生位置は受信WAVをデコードできることを確認できます。明示的に再生を開始してください。ページは自動再生しません。
以下の最終画面では、新スコアと受信音声の横にある2つの Connection from を比較してください。音声コントロールは実際にデコードした長さを表示し、再生位置を選択できます。
curlが接続できない（終了コード 7）か時間切れ（終了コード 28）なら、Event Clientへ戻り、対応する ip route get の結果と正確なURLを再確認します。HTTP拒否（終了コード 22）は別です。正確なエンドポイントパスと提供されたJSON・本文ファイルを比較します。-f はHTTPエラー応答の本文を省きます。業務フォーマットのエラーを直すためにネットワークを調整しないでください。ページの更新は受信側を読むだけで、未完了の作業を実行しません。
Event Client に戻り、維持した参照をもう一度確認します。
curl --noproxy '*' -fsS --max-time 35 http://10.205.10.30:8080/reference
2種類のワークロードを適切な経路で届け、両リンク、元バイト、準備済み整形、参照データ、無関係の経路を維持できました。採点は既存の業務記録とネイティブなネットワークの事実を読んだ後、限定的なGET確認を行います。スコア送信、ファイルアップロード、経路修復は行いません。
まとめ
ワークロードで経路を選び、2つの宛先経路だけを変更し、新スコアと完全な再生可能メディアを届けました。受信側の接続元は、送信がどこから到着したかを示します。後から経路を変えても書き換えられません。既存の参照と準備された両リンクも維持しました。
