Question connexe (Related Issue)
Il peut être souhaitable d'avoir un vieillissement et/ou des délais d'expiration de table. L'implémentation de ceux-ci est hors du cadre 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'il faut rejeter l'ancienne adresse. Cependant, les adresses Ethernet 48 bits sont censées être uniques et fixées pour toujours, donc elles ne devraient pas changer. Un hôte peut « se déplacer » si son nom d'hôte (et son adresse dans un autre protocole) est réaffecté à un matériel physique différent. De plus, comme nous le savons par expérience, il existe 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 indéfiniment. Peut-être que l'échec de l'établissement d'une connexion devrait informer le module de résolution d'adresse de supprimer les informations au motif que l'hôte n'est pas joignable, peut-être parce qu'il est en panne 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 le 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 que l'utilisation d'un hachage ou d'un index peut rendre cela plus rapide.
L'algorithme suggéré pour la réception de paquets de résolution d'adresse tente de réduire le temps nécessaire à 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'émetteur> est déjà dans la table de traduction, la nouvelle adresse matérielle remplace l'entrée existante. Par conséquent, sur un Ethernet parfait où une REQUEST de diffusion atteint toutes les stations sur le câble, chaque station obtiendra la nouvelle adresse matérielle.
Une alternative serait d'avoir un démon effectuer 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 l'opcode REQUEST directement à l'adresse Ethernet dans la table. Si une REPLY n'est pas vue dans un court laps de temps, l'entrée est supprimée. La requête est envoyée directement afin de ne pas déranger chaque station sur l'Ethernet. Oublier simplement les entrées entraînera probablement l'oubli d'informations utiles, qui doivent être regagnées.
Étant donné que les hôtes ne transmettent pas d'informations sur quelqu'un d'autre qu'eux-mêmes, le redémarrage d'un hôte fera en sorte que sa table de mappage d'adresses soit à jour. Les mauvaises informations ne peuvent pas persister indéfiniment en étant transmises de machine en machine ; la seule mauvaise information qui peut exister est dans une machine qui ne sait pas qu'une autre machine a changé son adresse Ethernet 48 bits. Peut-être que la réinitialisation manuelle (ou l'effacement) de la table de mappage d'adresses suffira.
Si l'on pense que ce problème est important, il est important que le démon expire et pose à nouveau la question au lieu de simplement supprimer l'entrée. Le démon pourrait également faire un meilleur travail de retransmissions que ce protocole, car une machine cible qui est physiquement connectée mais inaccessible (par exemple, en raison d'une défaillance logicielle) ne devrait pas avoir à répondre à la requête. Ce protocole sera utilisé pour déterminer l'adresse Ethernet de la passerelle du prochain saut, et cette passerelle ne devrait pas avoir à répondre à tous les paquets de résolution d'adresse sur l'Ethernet. Ce n'est pas un problème significatif, car le démon pourrait utiliser le protocole de résolution d'adresse pour poser la question, plutôt que de faire utiliser son propre protocole par le module de résolution d'adresse.