10. Related Issues (相关问题)
🇨🇳 中文
可能希望有表老化和/或超时。这些的实现超出了本协议的范围。这里是更详细的描述（感谢MOON@SCRC@MIT-MC）。
如果主机移动，该主机发起的任何连接都将正常工作，假设它在移动时清除了自己的地址解析表。但是，其他主机发起的到它的连接将没有特别的理由知道要丢弃其旧地址。然而，48位以太网地址应该是唯一的并且永远固定的，所以它们不应该改变。如果主机名（以及某些其他协议中的地址）被重新分配给不同的物理硬件，主机可能会"移动"。此外，正如我们从经验中知道的，总是存在通过硬件或软件错误意外传输不正确路由信息的危险；不应允许它永久存在。也许启动连接失败应该通知地址解析模块根据主机不可达（可能是因为它已关闭或旧转换不再有效）来删除信息。或者，从主机接收数据包应该重置用于向该主机传输数据包的地址解析条目中的超时；如果在适当的时间长度内没有从主机接收到数据包，则忘记地址解析条目。这可能会导致扫描表以处理每个传入数据包的额外开销。也许哈希或索引可以使这更快。
建议的接收地址解析数据包的算法试图减少主机确实移动时的恢复时间。回想一下，如果 <协议类型，发送者协议地址> 已经在转换表中，则发送者硬件地址将取代现有条目。因此，在完美的以太网上，广播REQUEST到达电缆上的所有站点，每个站点将获得新的硬件地址。
另一种选择是让守护进程执行超时。在适当的时间之后，守护进程考虑删除条目。它首先直接向表中的以太网地址发送（如果需要，进行少量重传）操作码为REQUEST的地址解析数据包。如果在短时间内看不到REPLY，则删除条目。请求直接发送，以便不打扰以太网上的每个站点。只是忘记条目可能会导致有用的信息被忘记，这些信息必须重新获得。
由于主机不传输关于除自己之外的任何人的信息，重新启动主机将使其地址映射表保持最新。坏信息不能通过从一台机器传递到另一台机器而永久存在；唯一可能存在的坏信息是在不知道其他机器已更改其48位以太网地址的机器中。也许手动重置（或清除）地址映射表就足够了。
如果认为这很重要，这个问题显然需要更多思考。它是由任何类似地址解析的协议引起的。
🇬🇧 English
It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol. Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).
If a host moves, any connections initiated by that host will work, assuming its own address resolution table is cleared when it moves. However, connections initiated to it by other hosts will have no particular reason to know to discard their old address. However, 48.bit Ethernet addresses are supposed to be unique and fixed for all time, so they shouldn't change. A host could "move" if a host name (and address in some other protocol) were reassigned to a different physical piece of hardware. Also, as we know from experience, there is always the danger of incorrect routing information accidentally getting transmitted through hardware or software error; it should not be allowed to persist forever. Perhaps failure to initiate a connection should inform the Address Resolution module to delete the information on the basis that the host is not reachable, possibly because it is down or the old translation is no longer valid. Or perhaps receiving of a packet from a host should reset a timeout in the address resolution entry used for transmitting packets to that host; if no packets are received from a host for a suitable length of time, the address resolution entry is forgotten. This may cause extra overhead to scan the table for each incoming packet. Perhaps a hash or index can make this faster.
The suggested algorithm for receiving address resolution packets tries to lessen the time it takes for recovery if a host does move. Recall that if the <protocol type, sender protocol address> is already in the translation table, then the sender hardware address supersedes the existing entry. Therefore, on a perfect Ethernet where a broadcast REQUEST reaches all stations on the cable, each station will be get the new hardware address.
Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained.
Since hosts don't transmit information about anyone other than themselves, rebooting a host will cause its address mapping table to be up to date. Bad information can't persist forever by being passed around from machine to machine; the only bad information that can exist is in a machine that doesn't know that some other machine has changed its 48.bit Ethernet address. Perhaps manually resetting (or clearing) the address mapping table will suffice.
This issue clearly needs more thought if it is believed to be important. It is caused by any address resolution-like protocol.
🇯🇵 日本語
テーブルのエージングやタイムアウトを持つことが望ましい場合があります。これらの実装はこのプロトコルの範囲外です。以下はより詳細な説明です（MOON@SCRC@MIT-MCに感謝）。
ホストが移動した場合、そのホストによって開始された接続は、移動時に自身のアドレス解決テーブルがクリアされると仮定すれば機能します。しかし、他のホストによって開始された接続は、古いアドレスを破棄すべき特別な理由を持ちません。ただし、48ビットイーサネットアドレスは永久に一意で固定されているはずなので、変更すべきではありません。ホスト名（および他のプロトコルのアドレス）が異なる物理ハードウェアに再割り当てされた場合、ホストは「移動」する可能性があります。また、経験から知っているように、ハードウェアまたはソフトウェアのエラーによって誤ったルーティング情報が誤って送信される危険が常にあります。これは永久に持続することを許されるべきではありません。おそらく接続の開始に失敗した場合、ホストが到達できない（おそらくダウンしているか、古い変換が無効になっている）という理由で、アドレス解決モジュールに情報を削除するよう通知すべきです。または、ホストからパケットを受信することで、そのホストにパケットを送信するために使用されるアドレス解決エントリのタイムアウトをリセットすべきです。適切な時間の長さでホストからパケットが受信されない場合、アドレス解決エントリは忘れられます。これは、各受信パケットに対してテーブルをスキャンする追加のオーバーヘッドを引き起こす可能性があります。おそらくハッシュまたはインデックスによってこれを高速化できます。
アドレス解決パケットを受信するための推奨アルゴリズムは、ホストが実際に移動した場合の回復にかかる時間を短縮しようとします。<プロトコルタイプ、送信者プロトコルアドレス>が既に変換テーブルにある場合、送信者ハードウェアアドレスが既存のエントリを置き換えることを思い出してください。したがって、ブロードキャストREQUESTがケーブル上のすべてのステーションに到達する完璧なイーサネットでは、各ステーションが新しいハードウェアアドレスを取得します。
別の代替案は、デーモンにタイムアウトを実行させることです。適切な時間の後、デーモンはエントリの削除を検討します。まず、テーブル内のイーサネットアドレスに直接、オペコードREQUESTのアドレス解決パケットを送信します（必要に応じて少数の再送信を行います）。短時間でREPLYが見られない場合、エントリは削除されます。リクエストは、イーサネット上のすべてのステーションに迷惑をかけないように直接送信されます。エントリを忘れるだけでは、有用な情報が忘れられる可能性があり、それを再取得する必要があります。
ホストは自分自身以外の誰についても情報を送信しないため、ホストの再起動によってそのアドレスマッピングテーブルが最新の状態になります。悪い情報はマシンからマシンへ渡されることによって永遠に持続することはできません。存在できる唯一の悪い情報は、他のマシンが48ビットイーサネットアドレスを変更したことを知らないマシン内のものです。おそらく、アドレスマッピングテーブルを手動でリセット（またはクリア）することで十分でしょう。
この問題が重要であると考えられる場合、明らかにさらなる検討が必要です。これは、アドレス解決のようなプロトコルによって引き起こされます。
🇫🇷 Français
Il peut être souhaitable d'avoir un vieillissement des tables et/ou des délais d'expiration. L'implémentation de ceux-ci est en dehors du champ d'application de ce protocole. Voici une description plus détaillée (merci à MOON@SCRC@MIT-MC).
Si un hôte se déplace, toutes les connexions initiées par cet hôte fonctionneront, en supposant que sa propre table de résolution d'adresse soit effacée lorsqu'il se déplace. Cependant, les connexions initiées vers lui par d'autres hôtes n'auront aucune raison particulière de savoir qu'elles doivent rejeter leur ancienne adresse. Cependant, les adresses Ethernet 48 bits sont censées être uniques et fixes pour toujours, donc elles ne devraient pas changer. Un hôte pourrait "se déplacer" si un nom d'hôte (et une adresse dans un autre protocole) étaient réaffectés à un matériel physique différent. De plus, comme nous le savons par expérience, il y a toujours le danger que des informations de routage incorrectes soient accidentellement transmises par erreur matérielle ou logicielle ; cela ne devrait pas être autorisé à persister pour toujours. Peut-être que l'échec d'initier une connexion devrait informer le module de résolution d'adresse de supprimer les informations sur la base que l'hôte n'est pas accessible, peut-être parce qu'il est éteint ou que l'ancienne traduction n'est plus valide. Ou peut-être que la réception d'un paquet d'un hôte devrait réinitialiser un délai d'expiration dans l'entrée de résolution d'adresse utilisée pour transmettre des paquets à cet hôte ; si aucun paquet n'est reçu d'un hôte pendant une durée appropriée, l'entrée de résolution d'adresse est oubliée. Cela peut causer une surcharge supplémentaire pour scanner la table pour chaque paquet entrant. Peut-être qu'un hachage ou un index peut rendre cela plus rapide.
L'algorithme suggéré pour recevoir des paquets de résolution d'adresse essaie de réduire le temps nécessaire pour la récupération si un hôte se déplace effectivement. Rappelez-vous que si la paire <type de protocole, adresse de protocole de l'expéditeur> est déjà dans la table de traduction, alors l'adresse matérielle de l'expéditeur remplace l'entrée existante. Par conséquent, sur un Ethernet parfait où une DEMANDE de diffusion atteint toutes les stations sur le câble, chaque station obtiendra la nouvelle adresse matérielle.
Une autre alternative consiste à avoir un démon qui effectue les délais d'expiration. Après un temps approprié, le démon envisage de supprimer une entrée. Il envoie d'abord (avec un petit nombre de retransmissions si nécessaire) un paquet de résolution d'adresse avec le code d'opération DEMANDE directement à l'adresse Ethernet dans la table. Si une RÉPONSE n'est pas vue dans un court laps de temps, l'entrée est supprimée. La demande est envoyée directement pour ne pas déranger chaque station sur l'Ethernet. Simplement oublier les entrées causera probablement l'oubli d'informations utiles, qui doivent être récupérées.
Étant donné que les hôtes ne transmettent pas d'informations sur quiconque d'autre qu'eux-mêmes, le redémarrage d'un hôte fera que sa table de mappage d'adresses sera à jour. Les mauvaises informations ne peuvent pas persister éternellement en étant transmises de machine en machine ; les seules mauvaises informations qui peuvent exister sont dans une machine qui ne sait pas qu'une autre machine a changé son adresse Ethernet 48 bits. Peut-être que réinitialiser (ou effacer) manuellement la table de mappage d'adresses suffira.
Cette question nécessite clairement plus de réflexion si elle est considérée comme importante. Elle est causée par tout protocole de type résolution d'adresse.
🇩🇪 Deutsch
Es kann wünschenswert sein, Tabellenalterung und/oder Zeitüberschreitungen zu haben. Die Implementierung dieser liegt außerhalb des Umfangs dieses Protokolls. Hier ist eine detailliertere Beschreibung (Dank an MOON@SCRC@MIT-MC).
Wenn ein Host umzieht, funktionieren alle von diesem Host initiierten Verbindungen, vorausgesetzt, seine eigene Adressauflösungstabelle wird beim Umzug gelöscht. Verbindungen, die von anderen Hosts zu ihm initiiert werden, haben jedoch keinen besonderen Grund zu wissen, dass sie ihre alte Adresse verwerfen sollten. Allerdings sollten 48-Bit-Ethernet-Adressen einzigartig und für alle Zeit festgelegt sein, also sollten sie sich nicht ändern. Ein Host könnte "umziehen", wenn ein Hostname (und eine Adresse in einem anderen Protokoll) einem anderen physischen Hardwareteil neu zugewiesen würde. Auch wissen wir aus Erfahrung, dass immer die Gefahr besteht, dass falsche Routing-Informationen versehentlich durch Hardware- oder Software-Fehler übertragen werden; dies sollte nicht für immer bestehen bleiben dürfen. Vielleicht sollte das Scheitern beim Initiieren einer Verbindung das Adressauflösungsmodul informieren, die Informationen auf der Grundlage zu löschen, dass der Host nicht erreichbar ist, möglicherweise weil er ausgefallen ist oder die alte Übersetzung nicht mehr gültig ist. Oder vielleicht sollte der Empfang eines Pakets von einem Host eine Zeitüberschreitung im Adressauflösungseintrag zurücksetzen, der zum Senden von Paketen an diesen Host verwendet wird; wenn für eine geeignete Zeitdauer keine Pakete von einem Host empfangen werden, wird der Adressauflösungseintrag vergessen. Dies kann zusätzlichen Overhead verursachen, um die Tabelle für jedes eingehende Paket zu scannen. Vielleicht kann ein Hash oder Index dies schneller machen.
Der vorgeschlagene Algorithmus zum Empfangen von Adressauflösungspaketen versucht, die Zeit für die Wiederherstellung zu verkürzen, wenn ein Host tatsächlich umzieht. Erinnern Sie sich daran, dass, wenn das Paar <Protokolltyp, Absender-Protokolladresse> bereits in der Übersetzungstabelle ist, dann die Absender-Hardware-Adresse den bestehenden Eintrag ersetzt. Daher erhält auf einem perfekten Ethernet, wo eine Broadcast-ANFRAGE alle Stationen auf dem Kabel erreicht, jede Station die neue Hardware-Adresse.
Eine andere Alternative besteht darin, einen Daemon die Zeitüberschreitungen durchführen zu lassen. Nach einer geeigneten Zeit erwägt der Daemon, einen Eintrag zu entfernen. Er sendet zuerst (mit einer kleinen Anzahl von Neuübertragungen, falls erforderlich) ein Adressauflösungspaket mit Opcode ANFRAGE direkt an die Ethernet-Adresse in der Tabelle. Wenn eine ANTWORT in kurzer Zeit nicht gesehen wird, wird der Eintrag gelöscht. Die Anfrage wird direkt gesendet, um nicht jede Station auf dem Ethernet zu stören. Nur Einträge zu vergessen wird wahrscheinlich dazu führen, dass nützliche Informationen vergessen werden, die wiedergewonnen werden müssen.
Da Hosts keine Informationen über irgendjemanden außer sich selbst übertragen, wird ein Neustart eines Hosts dazu führen, dass seine Adresszuordnungstabelle auf dem neuesten Stand ist. Schlechte Informationen können nicht für immer bestehen, indem sie von Maschine zu Maschine weitergegeben werden; die einzigen schlechten Informationen, die existieren können, sind in einer Maschine, die nicht weiß, dass eine andere Maschine ihre 48-Bit-Ethernet-Adresse geändert hat. Vielleicht genügt das manuelle Zurücksetzen (oder Löschen) der Adresszuordnungstabelle.
Diese Frage braucht eindeutig mehr Überlegung, wenn sie als wichtig angesehen wird. Sie wird durch jedes adressauflösungsähnliche Protokoll verursacht.
🇮🇹 Italiano
Potrebbe essere desiderabile avere un invecchiamento delle tabelle e/o timeout. L'implementazione di questi è al di fuori dell'ambito di questo protocollo. Ecco una descrizione più dettagliata (grazie a MOON@SCRC@MIT-MC).
Se un host si sposta, qualsiasi connessione iniziata da quell'host funzionerà, supponendo che la propria tabella di risoluzione degli indirizzi venga cancellata quando si sposta. Tuttavia, le connessioni iniziate verso di esso da altri host non avranno alcun motivo particolare per sapere di scartare il loro vecchio indirizzo. Tuttavia, gli indirizzi Ethernet a 48 bit dovrebbero essere unici e fissi per sempre, quindi non dovrebbero cambiare. Un host potrebbe "spostarsi" se un nome host (e un indirizzo in qualche altro protocollo) fosse riassegnato a un pezzo di hardware fisico diverso. Inoltre, come sappiamo per esperienza, c'è sempre il pericolo che informazioni di routing errate vengano trasmesse accidentalmente attraverso errori hardware o software; non dovrebbe essere consentito che persistano per sempre. Forse il fallimento nell'iniziare una connessione dovrebbe informare il modulo di risoluzione degli indirizzi di eliminare le informazioni sulla base che l'host non è raggiungibile, possibilmente perché è inattivo o la vecchia traduzione non è più valida. O forse la ricezione di un pacchetto da un host dovrebbe reimpostare un timeout nell'ingresso di risoluzione degli indirizzi utilizzato per trasmettere pacchetti a quell'host; se non vengono ricevuti pacchetti da un host per un periodo di tempo adeguato, l'ingresso di risoluzione degli indirizzi viene dimenticato. Questo può causare un overhead aggiuntivo per scansionare la tabella per ogni pacchetto in arrivo. Forse un hash o un indice può rendere questo più veloce.
L'algoritmo suggerito per ricevere pacchetti di risoluzione degli indirizzi cerca di ridurre il tempo necessario per il recupero se un host si sposta effettivamente. Ricorda che se la coppia <tipo di protocollo, indirizzo di protocollo del mittente> è già nella tabella di traduzione, allora l'indirizzo hardware del mittente sostituisce l'ingresso esistente. Pertanto, su un Ethernet perfetto dove una RICHIESTA broadcast raggiunge tutte le stazioni sul cavo, ogni stazione otterrà il nuovo indirizzo hardware.
Un'altra alternativa è avere un daemon che esegue i timeout. Dopo un tempo adeguato, il daemon considera la rimozione di un ingresso. Invia prima (con un piccolo numero di ritrasmissioni se necessario) un pacchetto di risoluzione degli indirizzi con opcode RICHIESTA direttamente all'indirizzo Ethernet nella tabella. Se una RISPOSTA non viene vista in poco tempo, l'ingresso viene eliminato. La richiesta viene inviata direttamente per non disturbare ogni stazione sull'Ethernet. Dimenticare semplicemente gli ingressi causerà probabilmente la dimenticanza di informazioni utili, che devono essere riacquisite.
Poiché gli host non trasmettono informazioni su nessuno tranne se stessi, il riavvio di un host farà sì che la sua tabella di mappatura degli indirizzi sia aggiornata. Le informazioni errate non possono persistere per sempre venendo passate da macchina a macchina; le uniche informazioni errate che possono esistere sono in una macchina che non sa che qualche altra macchina ha cambiato il suo indirizzo Ethernet a 48 bit. Forse il ripristino manuale (o la cancellazione) della tabella di mappatura degli indirizzi sarà sufficiente.
Questa questione necessita chiaramente di maggiore riflessione se è ritenuta importante. È causata da qualsiasi protocollo simile alla risoluzione degli indirizzi.