Warum wird es so gemacht? (Why is it done this way?)
Periodisches Broadcasting ist definitiv nicht erwünscht. Stellen Sie sich 100 Workstations auf einem einzigen Ethernet vor, die jeweils alle 10 Minuten Adressauflösungsinformationen broadcasten (als ein möglicher Satz von Parametern). Das ist ein Paket alle 6 Sekunden. Das ist fast vernünftig, aber wozu dient es? Die Workstations werden im Allgemeinen nicht miteinander sprechen (und haben daher 100 nutzlose Einträge in einer Tabelle); sie werden hauptsächlich mit einem Mainframe, Dateiserver oder einer Bridge sprechen, aber nur mit einer kleinen Anzahl anderer Workstations (z.B. für interaktive Gespräche). Das in diesem Dokument beschriebene Protokoll verteilt Informationen nach Bedarf und nur einmal (wahrscheinlich) pro Systemstart einer Maschine.
Dieses Format erlaubt nicht mehr als eine Auflösung im selben Paket. Dies dient der Einfachheit. Wenn Dinge gemultiplext würden, wäre das Paketformat erheblich schwieriger zu verdauen, und vieles der Informationen könnte überflüssig sein. Denken Sie an eine Bridge, die vier Protokolle spricht und einer Workstation alle vier Protokolladressen mitteilt, von denen die Workstation wahrscheinlich drei nie verwenden wird.
Dieses Format ermöglicht die Wiederverwendung des Paketpuffers, wenn eine Antwort generiert wird; eine Antwort hat dieselbe Länge wie eine Anfrage, und mehrere der Felder sind dieselben.
Der Wert des Hardware-Felds (ar$hrd) wird aus einer Liste für diesen Zweck entnommen. Derzeit ist der einzige definierte Wert für das 10Mbit-Ethernet (ares_hrd$Ethernet = 1). Es wurde darüber gesprochen, dieses Protokoll auch für Paketfunknetzwerke (Packet Radio Networks) zu verwenden, was einen anderen Wert erfordern würde, ebenso wie andere zukünftige Hardware-Medien, die dieses Protokoll verwenden möchten.
Für das 10Mbit-Ethernet wird der Wert im Protokollfeld (ar$pro) aus dem Set ether_type$ entnommen. Dies ist eine natürliche Wiederverwendung der zugewiesenen Protokolltypen. Die Kombination davon mit dem Opcode (ar$op) würde die Anzahl der Protokolle, die unter diesem Protokoll aufgelöst werden können, effektiv halbieren und würde einen Monitor/Debugger komplexer machen (siehe Netzwerküberwachung und Debugging unten). Es wird gehofft, dass wir niemals 32768 Protokolle sehen werden, aber Murphys Gesetz erlaubt es uns nicht, eine solche Annahme zu treffen.
Die Längenfelder (ar$hln und ar$pln) sind theoretisch redundant, da die Länge einer Protokolladresse durch den Hardware-Typ (in ar$hrd gefunden) und den Protokolltyp (in ar$pro gefunden) bestimmt werden sollte. Sie sind für optionale Konsistenzprüfungen und für Netzwerküberwachung und Debugging enthalten (siehe unten).
Der Opcode wird verwendet, um zu bestimmen, ob dies eine Anfrage ist (die eine Antwort verursachen kann) oder eine Antwort auf eine vorherige Anfrage. 16 Bit hierfür sind übertrieben, aber ein Flag (Feld) wird benötigt.
Die Absender-Hardware-Adresse und die Absender-Protokolladresse sind absolut notwendig. Es sind diese Felder, die in eine Übersetzungstabelle eingefügt werden.
Die Ziel-Protokolladresse ist in der Anforderungsform des Pakets notwendig, damit eine Maschine bestimmen kann, ob die Absenderinformationen in eine Tabelle eingetragen oder eine Antwort gesendet werden soll. Sie ist in der Antwortform nicht unbedingt erforderlich, wenn man annimmt, dass eine Antwort nur durch eine Anfrage ausgelöst wird. Sie ist aus Gründen der Vollständigkeit, der Netzwerküberwachung und zur Vereinfachung des oben beschriebenen vorgeschlagenen Verarbeitungsalgorithmus enthalten (der den Opcode erst NACH dem Einfügen der Absenderinformationen in eine Tabelle betrachtet).
Die Ziel-Hardware-Adresse ist aus Gründen der Vollständigkeit und der Netzwerküberwachung enthalten. Sie hat in der Anforderungsform keine Bedeutung, da dies die Nummer ist, die die Maschine anfordert. Ihre Bedeutung in der Antwortform ist die Adresse der Maschine, die die Anfrage stellt. In einigen Implementierungen (die die Ziel-Hardware-Adresse zurückerhalten müssen) kann dies durch Senden dieses Felds an den Hardware-Treiber als Hardware-Zieladresse des Pakets einige Register-Umgruppierungen oder Stack-Speicher sparen.
Es gibt keine Füllbytes zwischen Adressen. Die Paketdaten sollten als Byte-Stream betrachtet werden, in dem nur 3 Byte-Paare als Wörter definiert sind (ar$hrd, ar$pro und ar$op), die höchstwertiges Byte zuerst gesendet werden (Ethernet/PDP-10-Byte-Stil).