7. Why is it done this way (设计原理)
🇨🇳 中文
绝对不希望进行周期性广播。想象一下单根以太网上有100个工作站，每个工作站每10分钟广播一次地址解析信息（作为一组可能的参数）。这是每6秒一个数据包。这几乎是合理的，但有什么用呢？工作站通常不会相互通信（因此在表中有100个无用的条目）；它们主要与大型机、文件服务器或网桥通信，但只与少数其他工作站通信（例如用于交互式对话）。本文描述的协议根据需要分发信息，并且（可能）每次机器启动只分发一次。
此格式不允许在同一数据包中完成多个解析。这是为了简化。如果将多个解析复用，数据包格式将更难理解，并且大部分信息可能是无关的。想想一个使用四种协议的网桥告诉工作站所有四种协议地址，而工作站可能永远不会使用其中三种。
此格式允许在生成回复时重用数据包缓冲区；回复与请求的长度相同，并且有几个字段是相同的。
硬件字段（ar$hrd）的值取自用于此目的的列表。目前唯一定义的值是10Mbit以太网（ares_hrd$Ethernet = 1）。已经有人谈论将此协议用于分组无线电网络，这将需要另一个值，其他希望使用此协议的未来硬件介质也将需要另一个值。
对于10Mbit以太网，协议字段（ar$pro）中的值取自集合 ether_type$。这是对分配的协议类型的自然重用。将其与操作码（ar$op）组合将有效地将可在此协议下解析的协议数量减半，并将使监视器/调试器更复杂（参见下面的网络监控和调试）。希望我们永远不会看到32768种协议，但墨菲制定了一些法则，不允许我们做出这种假设。
理论上，长度字段（ar$hln 和 ar$pln）是冗余的，因为协议地址的长度应该由硬件类型（在 ar$hrd 中找到）和协议类型（在 ar$pro 中找到）确定。包含它是为了可选的一致性检查，以及用于网络监控和调试（见下文）。
操作码用于确定这是请求（可能导致回复）还是对先前请求的回复。16位对此来说是多余的，但需要一个标志（字段）。
发送者硬件地址和发送者协议地址是绝对必要的。正是这些字段被放入转换表中。
请求形式的数据包中需要目标协议地址，以便机器可以确定是否在表中输入发送者信息或发送回复。如果假设回复仅由请求引发，则在回复形式中不一定需要它。包含它是为了完整性、网络监控，以及简化上述建议的处理算法（该算法在将发送者信息放入表中之后才查看操作码）。
包含目标硬件地址是为了完整性和网络监控。它在请求形式中没有意义，因为这是机器正在请求的编号。它在回复形式中的含义是发出请求的机器的地址。在某些实现中（例如无法查看14字节以太网头的实现），这可以通过将此字段发送到硬件驱动程序作为数据包的硬件目标地址来节省一些寄存器切换或堆栈空间。
地址之间没有填充字节。数据包数据应被视为字节流，其中只有3个字节对被定义为字（ar$hrd、ar$pro 和 ar$op），它们以最高有效字节优先（以太网/PDP-10字节风格）发送。
🇬🇧 English
Periodic broadcasting is definitely not desired. Imagine 100 workstations on a single Ethernet, each broadcasting address resolution information once per 10 minutes (as one possible set of parameters). This is one packet every 6 seconds. This is almost reasonable, but what use is it? The workstations aren't generally going to be talking to each other (and therefore have 100 useless entries in a table); they will be mainly talking to a mainframe, file server or bridge, but only to a small number of other workstations (for interactive conversations, for example). The protocol described in this paper distributes information as it is needed, and only once (probably) per boot of a machine.
This format does not allow for more than one resolution to be done in the same packet. This is for simplicity. If things were multiplexed the packet format would be considerably harder to digest, and much of the information could be gratuitous. Think of a bridge that talks four protocols telling a workstation all four protocol addresses, three of which the workstation will probably never use.
This format allows the packet buffer to be reused if a reply is generated; a reply has the same length as a request, and several of the fields are the same.
The value of the hardware field (ar$hrd) is taken from a list for this purpose. Currently the only defined value is for the 10Mbit Ethernet (ares_hrd$Ethernet = 1). There has been talk of using this protocol for Packet Radio Networks as well, and this will require another value as will other future hardware mediums that wish to use this protocol.
For the 10Mbit Ethernet, the value in the protocol field (ar$pro) is taken from the set ether_type$. This is a natural reuse of the assigned protocol types. Combining this with the opcode (ar$op) would effectively halve the number of protocols that can be resolved under this protocol and would make a monitor/debugger more complex (see Network Monitoring and Debugging below). It is hoped that we will never see 32768 protocols, but Murphy made some laws which don't allow us to make this assumption.
In theory, the length fields (ar$hln and ar$pln) are redundant, since the length of a protocol address should be determined by the hardware type (found in ar$hrd) and the protocol type (found in ar$pro). It is included for optional consistency checking, and for network monitoring and debugging (see below).
The opcode is to determine if this is a request (which may cause a reply) or a reply to a previous request. 16 bits for this is overkill, but a flag (field) is needed.
The sender hardware address and sender protocol address are absolutely necessary. It is these fields that get put in a translation table.
The target protocol address is necessary in the request form of the packet so that a machine can determine whether or not to enter the sender information in a table or to send a reply. It is not necessarily needed in the reply form if one assumes a reply is only provoked by a request. It is included for completeness, network monitoring, and to simplify the suggested processing algorithm described above (which does not look at the opcode until AFTER putting the sender information in a table).
The target hardware address is included for completeness and network monitoring. It has no meaning in the request form, since it is this number that the machine is requesting. Its meaning in the reply form is the address of the machine making the request. In some implementations (which do not get to look at the 14.byte ethernet header, for example) this may save some register shuffling or stack space by sending this field to the hardware driver as the hardware destination address of the packet.
There are no padding bytes between addresses. The packet data should be viewed as a byte stream in which only 3 byte pairs are defined to be words (ar$hrd, ar$pro and ar$op) which are sent most significant byte first (Ethernet/PDP-10 byte style).
🇯🇵 日本語
定期的なブロードキャストは絶対に望ましくありません。単一のイーサネット上に100台のワークステーションがあり、それぞれが10分ごとにアドレス解決情報をブロードキャストすると想像してください（可能なパラメータセットの1つとして）。これは6秒ごとに1パケットです。これはほぼ合理的ですが、何の役に立つでしょうか？ワークステーションは一般的に互いに通信することはなく（したがってテーブルに100個の無用なエントリを持つことになります）、主にメインフレーム、ファイルサーバー、またはブリッジと通信しますが、他のワークステーションとは少数のみ（例えば、対話的な会話のため）通信します。この論文で説明されているプロトコルは、必要に応じて情報を配布し、おそらくマシンの起動ごとに1回だけ配布します。
この形式では、同じパケット内で複数の解決を行うことはできません。これは簡素化のためです。多重化された場合、パケット形式は消化するのがかなり難しくなり、情報の多くが不要なものになる可能性があります。4つのプロトコルを話すブリッジがワークステーションに4つのプロトコルアドレスすべてを伝えることを考えてください。そのうち3つはワークステーションがおそらく使用することはないでしょう。
この形式では、応答が生成される場合、パケットバッファを再利用できます。応答はリクエストと同じ長さであり、いくつかのフィールドは同じです。
ハードウェアフィールド（ar$hrd）の値は、この目的のためのリストから取得されます。現在、唯一定義されている値は10Mbitイーサネット（ares_hrd$Ethernet = 1）です。このプロトコルをパケット無線ネットワークでも使用することについて議論されており、これには別の値が必要になります。このプロトコルを使用したい他の将来のハードウェアメディアも同様です。
10Mbitイーサネットの場合、プロトコルフィールド（ar$pro）の値はセット ether_type$ から取得されます。これは割り当てられたプロトコルタイプの自然な再利用です。これをオペコード（ar$op）と組み合わせると、このプロトコルの下で解決できるプロトコルの数が事実上半分になり、モニター/デバッガがより複雑になります（以下のネットワーク監視とデバッグを参照）。32768のプロトコルを見ることは決してないと期待されていますが、マーフィーはこの仮定を許さないいくつかの法則を作りました。
理論的には、長さフィールド（ar$hln と ar$pln）は冗長です。プロトコルアドレスの長さは、ハードウェアタイプ（ar$hrd で見つかる）とプロトコルタイプ（ar$pro で見つかる）によって決定されるべきだからです。これはオプションの一貫性チェック、およびネットワーク監視とデバッグのために含まれています（以下を参照）。
オペコードは、これがリクエスト（応答を引き起こす可能性がある）か、以前のリクエストに対する応答かを判断するためのものです。このために16ビットは過剰ですが、フラグ（フィールド）が必要です。
送信者ハードウェアアドレスと送信者プロトコルアドレスは絶対に必要です。これらのフィールドが変換テーブルに入れられます。
ターゲットプロトコルアドレスは、マシンが送信者情報をテーブルに入力するか応答を送信するかを判断できるように、パケットのリクエスト形式で必要です。応答がリクエストによってのみ引き起こされると仮定する場合、応答形式では必ずしも必要ではありません。完全性、ネットワーク監視、および上記で説明した推奨処理アルゴリズムを簡素化するために含まれています（このアルゴリズムは、送信者情報をテーブルに入れた後にオペコードを見ます）。
ターゲットハードウェアアドレスは、完全性とネットワーク監視のために含まれています。リクエスト形式では意味がありません。なぜなら、これはマシンがリクエストしている番号だからです。応答形式での意味は、リクエストを行っているマシンのアドレスです。一部の実装（例えば、14バイトのイーサネットヘッダーを見ることができない実装）では、このフィールドをパケットのハードウェア宛先アドレスとしてハードウェアドライバに送信することで、レジスタのシャッフリングやスタックスペースを節約できる可能性があります。
アドレス間にパディングバイトはありません。パケットデータは、3つのバイトペアのみがワード（ar$hrd、ar$pro、ar$op）として定義されるバイトストリームとして見るべきで、最上位バイトが最初に送信されます（イーサネット/PDP-10バイトスタイル）。
🇫🇷 Français
La diffusion périodique n'est définitivement pas souhaitée. Imaginez 100 postes de travail sur un seul Ethernet, chacun diffusant des informations de résolution d'adresse une fois toutes les 10 minutes (comme un ensemble possible de paramètres). Cela fait un paquet toutes les 6 secondes. C'est presque raisonnable, mais à quoi cela sert-il ? Les postes de travail ne vont généralement pas se parler (et auront donc 100 entrées inutiles dans une table) ; ils parleront principalement à un ordinateur central, un serveur de fichiers ou un pont, mais seulement à un petit nombre d'autres postes de travail (pour des conversations interactives, par exemple). Le protocole décrit dans cet article distribue les informations au fur et à mesure des besoins, et seulement une fois (probablement) par démarrage d'une machine.
Ce format ne permet pas de faire plus d'une résolution dans le même paquet. C'est pour la simplicité. Si les choses étaient multiplexées, le format de paquet serait considérablement plus difficile à digérer, et une grande partie de l'information pourrait être gratuite. Pensez à un pont qui parle quatre protocoles en disant à un poste de travail les quatre adresses de protocole, dont trois que le poste de travail n'utilisera probablement jamais.
Ce format permet de réutiliser le tampon de paquet si une réponse est générée ; une réponse a la même longueur qu'une demande, et plusieurs des champs sont les mêmes.
La valeur du champ matériel (ar$hrd) est tirée d'une liste à cet effet. Actuellement, la seule valeur définie est pour l'Ethernet 10Mbit (ares_hrd$Ethernet = 1). Il a été question d'utiliser ce protocole pour les réseaux radio par paquets également, et cela nécessitera une autre valeur, tout comme d'autres futurs supports matériels qui souhaitent utiliser ce protocole.
Pour l'Ethernet 10Mbit, la valeur dans le champ de protocole (ar$pro) est tirée de l'ensemble ether_type$. Il s'agit d'une réutilisation naturelle des types de protocole attribués. La combinaison de cela avec le code d'opération (ar$op) réduirait effectivement de moitié le nombre de protocoles qui peuvent être résolus sous ce protocole et rendrait un moniteur/débogueur plus complexe (voir Surveillance et débogage du réseau ci-dessous). On espère que nous ne verrons jamais 32768 protocoles, mais Murphy a fait quelques lois qui ne nous permettent pas de faire cette hypothèse.
En théorie, les champs de longueur (ar$hln et ar$pln) sont redondants, puisque la longueur d'une adresse de protocole devrait être déterminée par le type de matériel (trouvé dans ar$hrd) et le type de protocole (trouvé dans ar$pro). Il est inclus pour une vérification facultative de la cohérence, et pour la surveillance et le débogage du réseau (voir ci-dessous).
Le code d'opération sert à déterminer s'il s'agit d'une demande (qui peut provoquer une réponse) ou d'une réponse à une demande précédente. 16 bits pour cela sont excessifs, mais un indicateur (champ) est nécessaire.
L'adresse matérielle de l'expéditeur et l'adresse de protocole de l'expéditeur sont absolument nécessaires. Ce sont ces champs qui sont placés dans une table de traduction.
L'adresse de protocole cible est nécessaire dans la forme de demande du paquet afin qu'une machine puisse déterminer s'il faut entrer les informations de l'expéditeur dans une table ou envoyer une réponse. Elle n'est pas nécessairement nécessaire dans la forme de réponse si l'on suppose qu'une réponse n'est provoquée que par une demande. Elle est incluse pour la complétude, la surveillance du réseau et pour simplifier l'algorithme de traitement suggéré décrit ci-dessus (qui ne regarde pas le code d'opération avant d'avoir mis les informations de l'expéditeur dans une table).
L'adresse matérielle cible est incluse pour la complétude et la surveillance du réseau. Elle n'a aucune signification dans la forme de demande, puisque c'est ce numéro que la machine demande. Sa signification dans la forme de réponse est l'adresse de la machine qui fait la demande. Dans certaines implémentations (qui ne peuvent pas voir l'en-tête Ethernet de 14 octets, par exemple), cela peut économiser un peu de brassage de registres ou d'espace de pile en envoyant ce champ au pilote matériel comme adresse de destination matérielle du paquet.
Il n'y a pas d'octets de remplissage entre les adresses. Les données du paquet doivent être vues comme un flux d'octets dans lequel seules 3 paires d'octets sont définies comme des mots (ar$hrd, ar$pro et ar$op) qui sont envoyés octet de poids fort en premier (style octet Ethernet/PDP-10).
🇩🇪 Deutsch
Periodisches Broadcasting ist definitiv nicht erwünscht. Stellen Sie sich 100 Workstations auf einem einzigen Ethernet vor, die jeweils einmal alle 10 Minuten Adressauflösungsinformationen senden (als ein möglicher Parametersatz). 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 daher 100 nutzlose Einträge in einer Tabelle haben); 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 Papier beschriebene Protokoll verteilt Informationen nach Bedarf und nur einmal (wahrscheinlich) pro Maschinenstart.
Dieses Format erlaubt es nicht, mehr als eine Auflösung im selben Paket durchzuführen. Dies dient der Einfachheit. Wenn Dinge multiplexiert wären, wäre das Paketformat erheblich schwieriger zu verstehen, und viele Informationen könnten unnötig sein. Denken Sie an eine Bridge, die vier Protokolle spricht und einer Workstation alle vier Protokolladressen mitteilt, von denen drei die Workstation wahrscheinlich nie verwenden wird.
Dieses Format ermöglicht die Wiederverwendung des Paketpuffers, wenn eine Antwort generiert wird; eine Antwort hat die gleiche Länge wie eine Anfrage, und mehrere Felder sind identisch.
Der Wert des Hardware-Feldes (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 Packet Radio Networks zu verwenden, und dies wird einen weiteren Wert erfordern, ebenso wie andere zukünftige Hardware-Medien, die dieses Protokoll verwenden möchten.
Für das 10Mbit-Ethernet wird der Wert im Protokoll-Feld (ar$pro) aus der Menge ether_type$ entnommen. Dies ist eine natürliche Wiederverwendung der zugewiesenen Protokolltypen. Die Kombination 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 Murphy hat einige Gesetze gemacht, die uns nicht erlauben, diese Annahme zu treffen.
Theoretisch sind die Längenfelder (ar$hln und ar$pln) redundant, da die Länge einer Protokolladresse durch den Hardware-Typ (gefunden in ar$hrd) und den Protokolltyp (gefunden in ar$pro) bestimmt werden sollte. Es ist für optionale Konsistenzprüfung und für Netzwerküberwachung und Debugging enthalten (siehe unten).
Der Opcode dient dazu, zu bestimmen, ob dies eine Anfrage ist (die eine Antwort verursachen kann) oder eine Antwort auf eine frühere Anfrage. 16 Bit dafür sind übertrieben, aber ein Flag (Feld) wird benötigt.
Die Absender-Hardware-Adresse und die Absender-Protokoll-Adresse sind absolut notwendig. Es sind diese Felder, die in eine Übersetzungstabelle eingefügt werden.
Die Ziel-Protokoll-Adresse ist in der Anfrageform des Pakets notwendig, damit eine Maschine bestimmen kann, ob sie die Absenderinformationen in eine Tabelle eintragen oder eine Antwort senden soll. Sie ist nicht unbedingt in der Antwortform erforderlich, wenn man annimmt, dass eine Antwort nur durch eine Anfrage provoziert 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 Netzwerküberwachung enthalten. Sie hat keine Bedeutung in der Anfrageform, 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 z.B. den 14-Byte-Ethernet-Header nicht sehen können) kann dies durch das Senden dieses Feldes an den Hardware-Treiber als Hardware-Zieladresse des Pakets etwas Register-Shuffling oder Stack-Platz sparen.
Es gibt keine Füllbytes zwischen den Adressen. Die Paketdaten sollten als Bytestrom betrachtet werden, in dem nur 3 Bytepaare als Wörter definiert sind (ar$hrd, ar$pro und ar$op), die höchstwertiges Byte zuerst gesendet werden (Ethernet/PDP-10-Byte-Stil).
🇮🇹 Italiano
La trasmissione periodica non è definitivamente desiderata. Immaginate 100 workstation su un singolo Ethernet, ognuna che trasmette 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 generalmente 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 (per conversazioni interattive, ad esempio). Il protocollo descritto in questo articolo distribuisce le informazioni man mano che sono necessarie, e solo una volta (probabilmente) per avvio di una macchina.
Questo formato non consente di fare 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 molte delle informazioni potrebbero essere gratuite. 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 una lista per questo scopo. Attualmente l'unico valore definito è per l'Ethernet 10Mbit (ares_hrd$Ethernet = 1). Si è parlato di usare questo protocollo anche per le reti radio a pacchetti, e questo richiederà 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. Combinare questo con l'opcode (ar$op) dimezzerebbe effettivamente il numero di protocolli che possono essere risolti sotto questo protocollo e renderebbe un monitor/debugger più complesso (vedere Monitoraggio e debugging di rete di seguito). Si spera che non vedremo mai 32768 protocolli, ma Murphy ha fatto alcune leggi che non ci permettono di fare questa ipotesi.
In teoria, i campi di lunghezza (ar$hln e ar$pln) sono 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). È incluso per il controllo opzionale della coerenza e per il monitoraggio e il debug della rete (vedi sotto).
L'opcode serve a determinare se questa è una richiesta (che può causare una risposta) o 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 target è 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 presume che una risposta sia provocata solo da una richiesta. È incluso per completezza, monitoraggio di 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 target è incluso per completezza e monitoraggio di rete. Non ha significato nella forma di richiesta, poiché è questo 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 non riescono a vedere l'intestazione Ethernet di 14 byte, ad esempio) questo può risparmiare un po' di mescolamento di registri o spazio nello 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 byte più significativo per primo (stile byte Ethernet/PDP-10).