6. Packet Reception (数据包接收)
🇨🇳 中文
当接收到地址解析数据包时，接收以太网模块将数据包交给地址解析模块，该模块执行类似于以下的算法。否定条件表示处理结束并丢弃数据包。
算法流程:
? 我是否拥有 ar$hrd 中的硬件类型？
是: (几乎肯定)
[可选择检查硬件长度 ar$hln]
? 我是否使用 ar$pro 中的协议？
是:
[可选择检查协议长度 ar$pln]
Merge_flag := false
如果 <协议类型, 发送者协议地址> 对已经在我的转换表中，
用数据包中的新信息更新条目的发送者硬件地址字段，
并将 Merge_flag 设置为 true。
? 我是目标协议地址吗？
是:
如果 Merge_flag 为 false，将三元组 <协议类型,
发送者协议地址, 发送者硬件地址> 添加到
转换表中。
? 操作码是 ares_op$REQUEST 吗？ (现在查看操作码!!)
是:
交换硬件和协议字段，将本地硬件和协议地址
放入发送者字段。
将 ar$op 字段设置为 ares_op$REPLY
将数据包发送到（新的）目标硬件地址，
在接收到请求的同一硬件上。
注意，<协议类型，发送者协议地址，发送者硬件地址>三元组在查看操作码之前就合并到表中。这是基于通信是双向的假设；如果A有理由与B通信，那么B可能也有理由与A通信。还要注意，如果 <协议类型，发送者协议地址> 对的条目已经存在，则新的硬件地址将取代旧的。相关问题部分给出了这样做的一些动机。
泛化: ar$hrd 和 ar$hln 字段允许此协议和数据包格式用于非10Mbit以太网。对于10Mbit以太网，<ar$hrd, ar$hln> 取值为 <1, 6>。对于其他硬件网络，ar$pro 字段可能不再对应于以太网类型字段，但它应该与正在寻求地址解析的协议相关联。
🇬🇧 English
When an address resolution packet is received, the receiving Ethernet module gives the packet to the Address Resolution module which goes through an algorithm similar to the following. Negative conditionals indicate an end of processing and a discarding of the packet.
Algorithm Flow:
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair ``<protocol type, sender protocol address>`` is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
Notice that the <protocol type, sender protocol address, sender hardware address> triplet is merged into the table before the opcode is looked at. This is on the assumption that communciation is bidirectional; if A has some reason to talk to B, then B will probably have some reason to talk to A. Notice also that if an entry already exists for the <protocol type, sender protocol address> pair, then the new hardware address supersedes the existing entry. Related Issues gives some motivation for this.
Generalization: The ar$hrd and ar$hln fields allow this protocol and packet format to be used for non-10Mbit Ethernets. For the 10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For other hardware networks, the ar$pro field may no longer correspond to the Ethernet type field, but it should be associated with the protocol whose address resolution is being sought.
🇯🇵 日本語
アドレス解決パケットが受信されると、受信イーサネットモジュールはパケットをアドレス解決モジュールに渡し、以下のようなアルゴリズムを実行します。否定条件は処理の終了とパケットの破棄を示します。
アルゴリズムフロー:
? ar$hrd のハードウェアタイプを持っているか？
はい: (ほぼ確実)
[オプションでハードウェア長 ar$hln をチェック]
? ar$pro のプロトコルを使用しているか？
はい:
[オプションでプロトコル長 ar$pln をチェック]
Merge_flag := false
`<プロトコルタイプ、送信者プロトコルアドレス>`ペアが
既に変換テーブルにある場合、エントリの送信者
ハードウェアアドレスフィールドをパケット内の新しい
情報で更新し、Merge_flag を true に設定する。
? 私はターゲットプロトコルアドレスか？
はい:
Merge_flag が false の場合、トリプレット`<プロトコルタイプ、
送信者プロトコルアドレス、送信者ハードウェアアドレス>`を
変換テーブルに追加する。
? オペコードは ares_op$REQUEST か？ (今、オペコードを見る!!)
はい:
ハードウェアとプロトコルフィールドを交換し、ローカルの
ハードウェアとプロトコルアドレスを送信者フィールドに入れる。
ar$op フィールドを ares_op$REPLY に設定する
リクエストが受信されたのと同じハードウェア上で、
（新しい）ターゲットハードウェアアドレスにパケットを送信する。
<プロトコルタイプ、送信者プロトコルアドレス、送信者ハードウェアアドレス>トリプレットは、オペコードを見る前にテーブルにマージされることに注意してください。これは、通信が双方向であるという仮定に基づいています。AがBと通信する理由があれば、BもおそらくAと通信する理由があるでしょう。また、<プロトコルタイプ、送信者プロトコルアドレス>ペアのエントリが既に存在する場合、新しいハードウェアアドレスが既存のエントリを置き換えることにも注意してください。関連問題はこれについてのいくつかの動機を提供します。
汎化: ar$hrd と ar$hln フィールドにより、このプロトコルとパケット形式を非10Mbitイーサネットで使用できます。10Mbitイーサネットの場合、<ar$hrd, ar$hln> は <1, 6> の値を取ります。他のハードウェアネットワークの場合、ar$pro フィールドはイーサネットタイプフィールドに対応しなくなる可能性がありますが、アドレス解決が求められているプロトコルに関連付けられるべきです。
🇫🇷 Français
Lorsqu'un paquet de résolution d'adresse est reçu, le module Ethernet récepteur donne le paquet au module de résolution d'adresse qui exécute un algorithme similaire à ce qui suit. Les conditions négatives indiquent une fin de traitement et un rejet du paquet.
Flux de l'algorithme :
? Ai-je le type de matériel dans ar$hrd ?
Oui : (presque certainement)
[vérifier éventuellement la longueur du matériel ar$hln]
? Est-ce que je parle le protocole dans ar$pro ?
Oui :
[vérifier éventuellement la longueur du protocole ar$pln]
Merge_flag := false
Si la paire <type de protocole, adresse de protocole de l'expéditeur> est
déjà dans ma table de traduction, mettre à jour le champ
d'adresse matérielle de l'expéditeur de l'entrée avec les nouvelles
informations du paquet et définir Merge_flag à true.
? Suis-je l'adresse de protocole cible ?
Oui :
Si Merge_flag est false, ajouter le triplet <type de protocole,
adresse de protocole de l'expéditeur, adresse matérielle de l'expéditeur>
à la table de traduction.
? Le code d'opération est-il ares_op$REQUEST ? (MAINTENANT regarder le code d'opération !!)
Oui :
Échanger les champs matériel et protocole, en mettant les adresses
matérielle et de protocole locales dans les champs expéditeur.
Définir le champ ar$op à ares_op$REPLY
Envoyer le paquet à l'adresse matérielle cible (nouvelle)
sur le même matériel sur lequel la demande a été reçue.
Notez que le triplet <type de protocole, adresse de protocole de l'expéditeur, adresse matérielle de l'expéditeur> est fusionné dans la table avant que le code d'opération ne soit examiné. Cela repose sur l'hypothèse que la communication est bidirectionnelle ; si A a une raison de parler à B, alors B aura probablement une raison de parler à A. Notez également que si une entrée existe déjà pour la paire <type de protocole, adresse de protocole de l'expéditeur>, alors la nouvelle adresse matérielle remplace l'entrée existante. Les problèmes connexes donnent une certaine motivation pour cela.
Généralisation : Les champs ar$hrd et ar$hln permettent à ce protocole et à ce format de paquet d'être utilisés pour des Ethernets non 10Mbit. Pour l'Ethernet 10Mbit, <ar$hrd, ar$hln> prend la valeur <1, 6>. Pour d'autres réseaux matériels, le champ ar$pro peut ne plus correspondre au champ de type Ethernet, mais il devrait être associé au protocole dont la résolution d'adresse est recherchée.
🇩🇪 Deutsch
Wenn ein Adressauflösungspaket empfangen wird, übergibt das empfangende Ethernet-Modul das Paket an das Adressauflösungsmodul, das einen Algorithmus ähnlich dem folgenden durchläuft. Negative Bedingungen zeigen ein Ende der Verarbeitung und ein Verwerfen des Pakets an.
Algorithmusfluss:
? Habe ich den Hardware-Typ in ar$hrd?
Ja: (fast definitiv)
[optional die Hardware-Länge ar$hln prüfen]
? Spreche ich das Protokoll in ar$pro?
Ja:
[optional die Protokoll-Länge ar$pln prüfen]
Merge_flag := false
Wenn das Paar <Protokolltyp, Absender-Protokolladresse>
bereits in meiner Übersetzungstabelle ist, aktualisiere das
Absender-Hardware-Adressfeld des Eintrags mit den neuen
Informationen im Paket und setze Merge_flag auf true.
? Bin ich die Ziel-Protokolladresse?
Ja:
Wenn Merge_flag false ist, füge das Tripel <Protokolltyp,
Absender-Protokolladresse, Absender-Hardware-Adresse> zur
Übersetzungstabelle hinzu.
? Ist der Opcode ares_op$REQUEST? (JETZT auf den Opcode schauen!!)
Ja:
Tausche Hardware- und Protokollfelder aus und setze die lokalen
Hardware- und Protokolladressen in die Absenderfelder.
Setze das ar$op-Feld auf ares_op$REPLY
Sende das Paket an die (neue) Ziel-Hardware-Adresse auf
derselben Hardware, auf der die Anfrage empfangen wurde.
Beachten Sie, dass das Tripel <Protokolltyp, Absender-Protokolladresse, Absender-Hardware-Adresse> in die Tabelle eingefügt wird, bevor der Opcode betrachtet wird. Dies basiert auf der Annahme, dass die Kommunikation bidirektional ist; wenn A einen Grund hat, mit B zu sprechen, wird B wahrscheinlich einen Grund haben, mit A zu sprechen. Beachten Sie auch, dass, wenn bereits ein Eintrag für das Paar <Protokolltyp, Absender-Protokolladresse> existiert, die neue Hardware-Adresse den bestehenden Eintrag ersetzt. Verwandte Themen geben einige Motivationen dafür.
Verallgemeinerung: Die Felder ar$hrd und ar$hln ermöglichen es, dieses Protokoll und Paketformat für Nicht-10Mbit-Ethernets zu verwenden. Für das 10Mbit-Ethernet nimmt <ar$hrd, ar$hln> den Wert <1, 6> an. Für andere Hardware-Netzwerke entspricht das ar$pro-Feld möglicherweise nicht mehr dem Ethernet-Typfeld, sollte aber mit dem Protokoll assoziiert sein, dessen Adressauflösung gesucht wird.
🇮🇹 Italiano
Quando viene ricevuto un pacchetto di risoluzione degli indirizzi, il modulo Ethernet ricevente passa il pacchetto al modulo di risoluzione degli indirizzi che esegue un algoritmo simile al seguente. I condizionali negativi indicano una fine dell'elaborazione e uno scarto del pacchetto.
Flusso dell'algoritmo:
? Ho il tipo di hardware in ar$hrd?
Sì: (quasi certamente)
[opzionalmente controllare la lunghezza hardware ar$hln]
? Parlo il protocollo in ar$pro?
Sì:
[opzionalmente controllare la lunghezza protocollo ar$pln]
Merge_flag := false
Se la coppia <tipo di protocollo, indirizzo di protocollo del mittente> è
già nella mia tabella di traduzione, aggiorna il campo
indirizzo hardware del mittente dell'ingresso con le nuove
informazioni nel pacchetto e imposta Merge_flag a true.
? Sono io l'indirizzo di protocollo target?
Sì:
Se Merge_flag è false, aggiungi la tripletta <tipo di protocollo,
indirizzo di protocollo del mittente, indirizzo hardware del mittente>
alla tabella di traduzione.
? L'opcode è ares_op$REQUEST? (ORA guarda l'opcode!!)
Sì:
Scambia i campi hardware e protocollo, mettendo gli indirizzi
hardware e protocollo locali nei campi mittente.
Imposta il campo ar$op a ares_op$REPLY
Invia il pacchetto all'indirizzo hardware target (nuovo)
sullo stesso hardware su cui è stata ricevuta la richiesta.
Si noti che la tripletta <tipo di protocollo, indirizzo di protocollo del mittente, indirizzo hardware del mittente> viene unita nella tabella prima che l'opcode venga esaminato. Questo si basa sul presupposto che la comunicazione sia bidirezionale; se A ha qualche motivo per parlare con B, allora B probabilmente avrà qualche motivo per parlare con A. Si noti anche che se esiste già un ingresso per la coppia <tipo di protocollo, indirizzo di protocollo del mittente>, allora il nuovo indirizzo hardware sostituisce l'ingresso esistente. I problemi correlati forniscono qualche motivazione per questo.
Generalizzazione: I campi ar$hrd e ar$hln consentono a questo protocollo e formato di pacchetto di essere utilizzati per Ethernet non 10Mbit. Per l'Ethernet 10Mbit <ar$hrd, ar$hln> assume il valore <1, 6>. Per altre reti hardware, il campo ar$pro potrebbe non corrispondere più al campo tipo Ethernet, ma dovrebbe essere associato al protocollo di cui si cerca la risoluzione dell'indirizzo.