Pourquoi est-ce fait de cette manière ? (Why is it done this way?)
La diffusion périodique n'est absolument pas souhaitable. Imaginez 100 postes de travail sur un seul Ethernet, chacun diffusant des informations de résolution d'adresse toutes les 10 minutes (comme un ensemble possible de paramètres). C'est 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 entre eux (et ont 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 (par exemple, pour des conversations interactives). Le protocole décrit dans ce document 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 d'effectuer plusieurs résolutions 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 des informations 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 requête, et plusieurs des champs sont identiques.
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 de paquets radio (Packet Radio Networks) également, ce qui nécessiterait une autre valeur, tout comme d'autres supports matériels futurs qui souhaiteraient 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 l'opcode (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 la loi de Murphy ne nous permet pas de faire une telle hypothèse.
Les champs de longueur (ar$hln et ar$pln) sont, en théorie, redondants, car 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). Ils sont inclus pour une vérification de cohérence facultative et pour la surveillance et le débogage du réseau (voir ci-dessous).
L'opcode est utilisé pour déterminer s'il s'agit d'une requête (qui peut provoquer une réponse) ou d'une réponse à une requête précédente. 16 bits pour cela sont excessifs, mais un indicateur (champ) est nécessaire.
L'adresse matérielle de l'émetteur et l'adresse de protocole de l'émetteur 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 requête du paquet afin qu'une machine puisse déterminer s'il faut entrer les informations de l'émetteur 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 requête. 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 l'opcode jusqu'à APRÈS avoir placé les informations de l'émetteur dans une table).
L'adresse matérielle cible est incluse pour la complétude et la surveillance du réseau. Elle n'a pas de sens dans la forme de requête, car 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 requête. Dans certaines implémentations (qui ont besoin de récupérer l'adresse matérielle cible), cela peut économiser un certain réarrangement de registre 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 considérées comme un flux d'octets dans lequel seulement 3 paires d'octets sont définies comme des mots (ar$hrd, ar$pro et ar$op) qui sont envoyés octet le plus significatif en premier (style d'octet Ethernet/PDP-10).