関連する問題 (Related Issue)

テーブルのエージングおよび/またはタイムアウトが望ましい場合があります。これらの実装は、このプロトコルの範囲外です。ここに、より詳細な説明があります (MOON@SCRC@MIT-MCに感謝)。

ホストが移動した場合、そのホストによって開始された接続は機能します。移動時に自身のアドレス解決テーブルがクリアされると仮定します。しかし、他のホストによって開始されたそのホストへの接続は、古いアドレスを破棄する特別な理由がありません。ただし、48ビットイーサネットアドレスは、ユニークで永久に固定されているべきなので、変更されるべきではありません (should not)。ホスト名 (および他のプロトコルのアドレス) が異なる物理ハードウェアに再割り当てされた場合、ホストが「移動」する可能性があります。さらに、経験から知っているように、ハードウェアまたはソフトウェアのエラーによって誤ったルーティング情報が誤って送信される危険性は常に存在します; これが永久に存続することを許可すべきではありません (should not)。おそらく、接続の開始の失敗は、ホストが到達不能であるという理由で情報を削除するようにアドレス解決モジュールに通知すべきです (should)。おそらくホストがダウンしているか、古い変換がもはや有効ではないためです。あるいは、ホストからパケットを受信すると、そのホストへパケットを送信するために使用されるアドレス解決エントリのタイムアウトをリセットする可能性があります; 適切な時間内にホストからパケットが受信されない場合、アドレス解決エントリは忘れられます。これにより、各着信パケットのテーブルをスキャンする追加のオーバーヘッドが発生する可能性があります。おそらく、ハッシュまたはインデックスを使用すると、これをより高速にできます。

提案されたアドレス解決パケット受信アルゴリズムは、ホストが実際に移動した場合の回復時間を短縮しようとします。<プロトコルタイプ, 送信者プロトコルアドレス> ペアが既に変換テーブルに存在する場合、新しいハードウェアアドレスが既存のエントリに優先することを思い出してください。したがって、ブロードキャストREQUESTがケーブル上のすべてのステーションに到達する完璧なイーサネットでは、各ステーションが新しいハードウェアアドレスを取得します。

別の選択肢は、デーモンにタイムアウトを実行させることです。適切な時間の後、デーモンはエントリの削除を検討します。最初に、オペコードがREQUESTのアドレス解決パケットをテーブル内のイーサネットアドレスに直接送信します (必要に応じて少数の再送信を行います)。短時間でREPLYが見られない場合、エントリは削除されます。リクエストは、イーサネット上のすべてのステーションに迷惑をかけないように直接送信されます。エントリを忘れるだけでは、有用な情報が忘れられる可能性があり、再取得する必要があります。

ホストは自分自身以外の誰の情報も送信しないため、ホストを再起動すると、そのアドレスマッピングテーブルは最新になります。悪い情報がマシン間で受け渡されることによって永久に存続することはできません; 存在できる唯一の悪い情報は、他のマシンが48ビットイーサネットアドレスを変更したことを知らないマシン内のものです。おそらく、アドレスマッピングテーブルを手動でリセット (またはクリア) するだけで十分でしょう。

この問題が重要であると考えられる場合、デーモンがタイムアウトして質問を再度尋ねることが重要です。エントリを削除するだけではありません。デーモンは、このプロトコルよりも再送信をより適切に処理することもできます。なぜなら、物理的に接続されているが到達不能なターゲットマシン (例えば、ソフトウェア障害のため) は、リクエストに応答する必要がないからです。このプロトコルは、次のホップゲートウェイのイーサネットアドレスを決定するために使用され、そのゲートウェイはイーサネット上のすべてのアドレス解決パケットに応答する必要はありません。これは重要な問題ではありません。なぜなら、デーモンは独自のプロトコルを使用するのではなく、アドレス解決プロトコルを使用して質問をすることができるからです。