10. Questioni correlate (Related Issues)

Potrebbero essere necessari meccanismi di invecchiamento (table aging) e/o di timeout della tabella. L'implementazione di tali meccanismi va oltre lo scopo di questo protocollo. Di seguito è riportata una descrizione più dettagliata (per gentile concessione di MOON@SCRC@MIT-MC).

Se un host si sposta, tutte le connessioni da esso originate funzioneranno correttamente, purché la propria tabella di risoluzione degli indirizzi sia stata cancellata al momento dello spostamento. Tuttavia, le connessioni verso l'host originate da altri host non avranno alcun motivo particolare per sapere di dover scartare il vecchio indirizzo. D'altra parte, gli indirizzi Ethernet a 48 bit dovrebbero essere univoci e permanentemente fissi, e quindi non dovrebbero cambiare. Un host può "spostarsi" se il nome host (e in alcuni altri protocolli l'indirizzo) viene riassegnato a hardware fisico diverso. Inoltre, per esperienza, esiste sempre il pericolo che informazioni di instradamento errate vengano trasmesse accidentalmente a causa di errori hardware o software; non si dovrebbe permettere che ciò permanga. Forse un fallimento di inizializzazione della connessione dovrebbe avvisare il modulo di risoluzione degli indirizzi di eliminare le informazioni correlate, col ragionamento che l'host è irraggiungibile, forse perché è spento o perché la vecchia conversione non è più valida. In alternativa, la ricezione di un pacchetto da un host dovrebbe ripristinare il timeout della voce di risoluzione degli indirizzi usata per trasmettere pacchetti a quell'host; se entro un tempo opportuno non viene ricevuto alcun pacchetto dall'host, la voce di risoluzione degli indirizzi viene dimenticata. Ciò potrebbe comportare l'overhead aggiuntivo di scansionare la tabella per ogni pacchetto in arrivo. Forse l'uso di hashing o di indici può velocizzare le cose.

L'algoritmo di ricezione dei pacchetti di risoluzione degli indirizzi proposto cerca di ridurre il tempo di recupero quando un host si sposta. Si ricordi che, se <tipo di protocollo, indirizzo di protocollo del mittente> è già presente nella tabella di conversione, l'indirizzo hardware del mittente sostituisce la voce esistente. Pertanto, su un Ethernet ideale, la REQUEST in broadcast raggiunge tutte le stazioni sul cavo e ciascuna ottiene il nuovo indirizzo hardware.

Un'altra possibilità è quella di far eseguire il timeout a un demone (daemon). Dopo un tempo opportuno, il demone prende in considerazione l'eliminazione di una voce. Invia innanzitutto direttamente all'indirizzo Ethernet della tabella (con alcune ritrasmissioni se necessario) un pacchetto di risoluzione degli indirizzi con codice operativo REQUEST. Se entro un breve periodo non riceve un REPLY, elimina la voce. La richiesta viene inviata direttamente per evitare di disturbare ogni stazione sull'Ethernet. Dimenticare semplicemente la voce potrebbe causare la perdita di informazioni utili che dovrebbero essere riacquisite.

Poiché un host non trasmette informazioni su alcun altro oltre a sé stesso, il riavvio di un host manterrà aggiornata la sua tabella di mappatura degli indirizzi. Le informazioni errate non possono permanere indefinitamente venendo propagate tra le macchine; l'unica informazione errata che può esistere è in una macchina che non sa che un'altra macchina ha cambiato il proprio indirizzo Ethernet a 48 bit. Forse un reset (o una cancellazione) manuale della tabella di mappatura degli indirizzi è sufficiente.

Se questo problema viene ritenuto importante, è necessaria un'ulteriore riflessione. Qualsiasi protocollo simile alla risoluzione degli indirizzi incontra questo problema.