Perché si fa in questo modo? (Why is it done this way?)
Il broadcasting periodico non è assolutamente desiderabile. Immaginate 100 workstation su un singolo Ethernet, ciascuna che trasmette in broadcast informazioni di risoluzione degli indirizzi una volta ogni 10 minuti (come un possibile insieme di parametri). Questo è un pacchetto ogni 6 secondi. Questo è quasi ragionevole, ma a cosa serve? Le workstation in genere non parleranno tra loro (e quindi avranno 100 voci inutili in una tabella); parleranno principalmente con un mainframe, un file server o un bridge, ma solo con un piccolo numero di altre workstation (ad esempio, per conversazioni interattive). Il protocollo descritto in questo documento distribuisce le informazioni secondo necessità e solo una volta (probabilmente) per avvio di una macchina.
Questo formato non consente di eseguire più di una risoluzione nello stesso pacchetto. Questo è per semplicità. Se le cose fossero multiplexate, il formato del pacchetto sarebbe considerevolmente più difficile da digerire e gran parte delle informazioni potrebbe essere gratuita. Pensate a un bridge che parla quattro protocolli che dice a una workstation tutti e quattro gli indirizzi di protocollo, tre dei quali la workstation probabilmente non userà mai.
Questo formato consente il riutilizzo del buffer del pacchetto se viene generata una risposta; una risposta ha la stessa lunghezza di una richiesta e diversi campi sono gli stessi.
Il valore del campo hardware (ar$hrd) è preso da un elenco per questo scopo. Attualmente l'unico valore definito è per l'Ethernet 10Mbit (ares_hrd$Ethernet = 1). Si è parlato di utilizzare questo protocollo anche per le reti radio a pacchetti (Packet Radio Networks), che richiederebbero un altro valore, così come altri futuri mezzi hardware che desiderano utilizzare questo protocollo.
Per l'Ethernet 10Mbit, il valore nel campo protocollo (ar$pro) è preso dall'insieme ether_type$. Questo è un riutilizzo naturale dei tipi di protocollo assegnati. Combinando questo con l'opcode (ar$op) si dimezzerebbe effettivamente il numero di protocolli che possono essere risolti sotto questo protocollo e renderebbe un monitor/debugger più complesso (vedere Monitoraggio e debug della rete di seguito). Si spera di non vedere mai 32768 protocolli, ma la legge di Murphy non ci consente di fare tale assunzione.
I campi di lunghezza (ar$hln e ar$pln) sono, in teoria, ridondanti, poiché la lunghezza di un indirizzo di protocollo dovrebbe essere determinata dal tipo di hardware (trovato in ar$hrd) e dal tipo di protocollo (trovato in ar$pro). Sono inclusi per il controllo opzionale della coerenza e per il monitoraggio e il debug della rete (vedere di seguito).
L'opcode è utilizzato per determinare se si tratta di una richiesta (che può causare una risposta) o di una risposta a una richiesta precedente. 16 bit per questo sono eccessivi, ma è necessario un flag (campo).
L'indirizzo hardware del mittente e l'indirizzo di protocollo del mittente sono assolutamente necessari. Sono questi campi che vengono inseriti in una tabella di traduzione.
L'indirizzo di protocollo di destinazione è necessario nella forma di richiesta del pacchetto in modo che una macchina possa determinare se inserire le informazioni del mittente in una tabella o inviare una risposta. Non è necessariamente necessario nella forma di risposta se si assume che una risposta sia provocata solo da una richiesta. È incluso per completezza, monitoraggio della rete e per semplificare l'algoritmo di elaborazione suggerito descritto sopra (che non guarda l'opcode fino a DOPO aver inserito le informazioni del mittente in una tabella).
L'indirizzo hardware di destinazione è incluso per completezza e monitoraggio della rete. Non ha significato nella forma di richiesta, poiché questo è il numero che la macchina sta richiedendo. Il suo significato nella forma di risposta è l'indirizzo della macchina che effettua la richiesta. In alcune implementazioni (che hanno bisogno di recuperare l'indirizzo hardware di destinazione), questo può risparmiare un po' di riorganizzazione dei registri o spazio dello stack inviando questo campo al driver hardware come indirizzo di destinazione hardware del pacchetto.
Non ci sono byte di riempimento tra gli indirizzi. I dati del pacchetto dovrebbero essere visti come un flusso di byte in cui solo 3 coppie di byte sono definite come parole (ar$hrd, ar$pro e ar$op) che vengono inviate con il byte più significativo per primo (stile byte Ethernet/PDP-10).