ネットワーク監視とデバッグ (Network Monitoring and Debugging)

上記のアドレス解決プロトコルにより、マシンはイーサネットケーブル上のより高レベルのプロトコル活動 (例えば、CHAOS、インターネット、PUP、DECnet) に関する知識を得ることができます。使用されているイーサネットプロトコルタイプフィールド (値による) と各プロトコルタイプ内のプロトコルアドレスを特定できます。実際、モニターは関与するより高レベルのプロトコルのいずれかを使用する必要はありません。以下のように実行できます:

モニターがアドレス解決パケットを受信すると、常に <プロトコルタイプ, 送信者プロトコルアドレス, 送信者ハードウェアアドレス> をテーブルに入力します。パケットのar$hlnとar$plnフィールドから、ハードウェアアドレスとプロトコルアドレスの長さを決定できます。オペコードがREPLYの場合、モニターはパケットを破棄できます。オペコードがREQUESTで、ターゲットプロトコルアドレスがモニターのプロトコルアドレスと一致する場合、モニターは通常どおりREPLYを送信します。モニターは、REQUESTに対するREPLYが要求ホストに直接送信されるため、この方法で1つのマッピングしか取得しません。モニターは独自のREQUESTを送信しようとする可能性がありますが、これにより2つのモニターがREQUEST送信ループに陥る可能性があるため、注意が必要です。

プロトコルとオペコードが1つのフィールドに結合されていないため、モニターは同じより高レベルのプロトコルに対してどのリクエストオペコードがどの応答オペコードと一致するかを知る必要がありません。長さフィールドは、プロトコルアドレスの意味を知らなくても、プロトコルアドレスを「解析」できるようにするのに十分な情報を提供するべきです (should)。

アドレス解決プロトコルの動作実装は、動作しない実装をデバッグするためにも使用できます。ハードウェアドライバーは、おそらくイーサネットタイプフィールドが ether_type$ADDRESS_RESOLUTION のパケットをブロードキャストすることに成功するでしょう。パケットのフォーマットは完全に正しくない可能性があります。なぜなら、初期実装にはバグがある可能性があり、テーブル管理が少し厄介な可能性があるからです。リクエストはブロードキャストされるため、モニターはパケットを受信し、必要に応じてデバッグのために表示できます。

---