RFC442 日本語訳
0442 Current flow-control scheme for IMPSYS. V. Cerf. January 1973. (Format: TXT=16315 bytes) (Updated by RFC0449) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Cerf Request for Comments: 442 24 January 1973 NIC: 13774
コメントを求めるワーキンググループV.サーフの要求をネットワークでつないでください: 442 1973年1月24日NIC: 13774
The Current Flow-Control Scheme for IMPSYS
IMPSYSの現在のフロー制御計画
BB&N quarterly report #13 outlines part of the current flow control scheme in the IMP operating system. A meeting held March 16, 1972, at BB&N was devoted to the description of this new scheme for the benefit of interested network participants.
現在のフロー制御の掲示板とN四半期報告書#13アウトライン部分はIMPオペレーティングシステムで計画されます。 1972年3月16日に掲示板とNで行われた会合は関心があるネットワーク関係者の利益のこの新しい計画の記述にささげられました。
This note represents my understanding of the flow control mechanism. The essential goal is to eliminate unnecessary retransmissions when the load is heavy, eliminate the retransmission time-out period when the load is light, increase bandwidth, prevent re-assembly lock-up, control traffic from HOSTS into the net more strictly than the earlier link blocking method, and secure the rights of life, liberty, and the pursuit of happiness for ourselves and our posterity,...oops.
この注意は私のフロー制御メカニズムの理解を表します。 不可欠の目標は、負荷が重いときに、不要な「再-トランスミッション」を排除して、負荷が軽い「再-トランスミッション」タイムアウトの期間を排除して、帯域幅を増加させて、再アセンブリ留置所を防いで、HOSTSからネットに方法を妨げる以前のリンクより厳密に交通整理して、自分達と私たちの子孫の間、人生、自由、および幸福の追求の権利を保証することです…おっと。
Source IMP-to-Destination IMP Protocol
ソース悪童から目的地への悪童プロトコル
There are two different protocols depending on message length (i.e. single or multi-packet). We illustrate first the single packet case.
メッセージ長(すなわち、単一の、または、マルチパケットの)に依存する2つの異なったプロトコルがあります。 私たちは最初に、ただ一つのパケットケースを例証します。
Source Imp Destination Imp
---------- ---------------
ソース悪童目的地悪童---------- ---------------
case 1) message (1) + implicit req (1)--->
<--- RFNM (arrived ok)
[discard copy of msg]
ケース1) メッセージ(1) + 内在しているreq(1)---><。--- RFNM(OKに、到着します) [msgのコピーを捨てます]
case 2) message (1) + implicit req (1)---> no room, don't respond
<--- All (1) (room available)
message (1) --->
[discard copy of msg] <--- RFNM (arrived ok)
ケース2) メッセージ(1) + 内在しているreq(1)--->ノー、は同居して、<を反応させないでください。--- すべての(1) (利用可能な余地) メッセージ(1) --->[msgのコピーを捨てる]<。--- RFNM(OKに、到着します)
In the first case, a single packet message is sent to the destination IMP. This message acts as an implicit request for single packet buffer space. If there is room, as in case 1, the destination IMP responds with a RFNM. The source IMP, which has retained a copy of the message, deletes its copy and goes on.
前者の場合、ただ一つのパケットメッセージを目的地IMPに送ります。 このメッセージはただ一つのパケットバッファ領域を求める暗黙の要求として機能します。 余地がケース1のようにあれば、目的地IMPはRFNMと共に応じます。 ソースIMP(メッセージのコピーを保有した)はコピーを削除して、先へ進みます。
The second case illustrates what happens when the source IMP sends a message to a destination IMP at which there is no room for the one- packet message. The arrival of the single packet message constitutes a request for single packet buffer space, and is recorded as such by the destination IMP in a first-come-first-served buffer reservation
2番目のこの件は、ソースIMPが1つのパケットメッセージの余地が全くない目的地IMPにメッセージを送るとき、何が起こるかを例証します。 ただ一つのパケットメッセージの到着は、ただ一つのパケットバッファ領域に要求を構成して、目的地IMPによってそういうものとして先着順のバッファの予約に記録されます。
Cerf [Page 1] RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973
IMPSYS1973年1月のサーフ[1ページ]RFC442の現在のフロー制御計画
request queue. When space is available, the destination IMP will transmit an ALL (1) to the requesting source IMP which can then send the single packet message again, this time knowing that space has been reserved at the destination.
待ち行列を要求してください。 スペースが利用可能であるときに、スペースが目的地で予約されたのを知りながら、目的地IMPは次に再び、今回ただ一つのパケットメッセージを送ることができる要求しているソースIMPにすべての(1)を伝えるでしょう。
For multi-packet messages, the procedure is somewhat different. When a message enters an IMP from a HOST, and the "last bit" flag is not set when the number of bits in a maximum length single packet have arrived, the IMP halts the HOST->IMP transmission line while it determines whether space has been reserved at the dest. IMP. If space (8 packets worth) has been reserved, the HOST->IMP line is re- opened, and the message is sent out normally. If space has not been reserved, the HOST->IMP line is kept closed while the source IMP makes a request for multi-packet buffer storage at the destination IMP. When 8 buffers are available, the destination IMP responds with an ALL (8). The source IMP then transmits the message, and waits for a combination RFNM and ALL (8) from the destination IMP. The destination IMP will delay its RFNM, if necessary, until it has another 8 buffers available for the next multipacket message.
マルチパケットメッセージに関しては、手順はいくらか異なっています。 メッセージがHOSTからIMPに入って、最大の長さの単一のパケットのビットの数が到着したとき「最後のビット」旗が設定されないとき、IMPはHOST->を止めます。IMP伝送路は、それである間、スペースがdestで予約されたかどうか決定します。 悪童。 スペースである、(8つのパケット、価値)、予約されていて、IMPが裏打ちするHOST->を再開いて、通常、メッセージを出すということでした。 スペースが予約されていないなら、ソースIMPが目的地のマルチパケット緩衝記憶装置に関する要求をIMPにしている間、IMPが裏打ちするHOST->は閉じられるように保たれます。 8つのバッファが利用可能であるときに、目的地IMPはすべての(8)で応じます。 ソースIMPは次に、メッセージを送って、組み合わせRFNMと目的地IMPからのすべての(8)を待っています。 必要なら、それには次の「マルチ-パケット」メッセージに利用可能な別の8つのバッファがあるまで、目的地IMPはRFNMを遅らせるでしょう。
This sequence is illustrated below:
この系列は以下で例証されます:
Source IMP Destination IMP
---------- ---------------
ソース悪童目的地悪童---------- ---------------
H-> I line
----------> First packet of multipacket
arrives. Halt H->I line and
send REQ (8) -------------->
start 30 sec. Time-out
私が裏打ちするH->。----------「マルチ-パケット」の>最初のパケットは到着します。 H>I線を止めてください、そして、REQ(8)を送ってください。--------------30秒の>始め タイムアウト
If time-out, resend
REQ (8) and restart -------->
time-out.
<--------ALL (8) when available. Start
long term (2 min.) time-out.
On time-out, reset all
outstanding reservations.
タイムアウトであるなら、REQ(8)を再送してください、そして、再開してください。-------->タイムアウト。 <、-、-、-、-、-、-、--(8) すべて利用可能であるときに。 長期(2分)タイムアウトを始めてください。 外の時に、すべての傑出している予約をリセットしてください。
Send the message:
| ----------->
Start 30 sec. time-out
for INComplete transmission.
If time-out, send INC?----->
メッセージを送ってください: | -----------INCompleteトランスミッションのための>のスタートの30秒のタイムアウト。 タイムアウトであるなら、INCを送ってくれますか?----->。
Cerf [Page 2] RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973
IMPSYS1973年1月のサーフ[2ページ]RFC442の現在のフロー制御計画
<------On recept of message, send
RFNM + implicit ALL (8). On
receipt of INC? send RFNM +
ALL(8) if MSG(8) received,
or send INC! if MSG(8) not
received. Start 2 min. time-out
on ALL(8).
<。------メッセージのreceptに、RFNM+暗黙のすべてを送ってください。(8)。 INCを受け取り次第、MSG(8)が受信したなら、+ すべての(8)をRFNMに送るか、またはMSG(8)が受信しなかったなら、INC!を送ってください。 2分のタイムアウトをすべての(8)に始めてください。
Queue ALL(8); start 125 ms.
time-out when it reaches
head of queue. If time-out
on ALL(8), send GVB(8)----->
<----- Ack.
else send next message ----->
すべての(8)を列に並ばせてください。 それが待ち行列のヘッドに届いたら、125原稿タイムアウトを始めてください。 すべての(8)のタイムアウトであるなら、GVB(8)を送ってください。-----><。----- Ack、ほかに、次のメッセージを送ってください。----->。
A key point in this protocol is that a source IMP, after receipt of a RFNM and implicit ALL(8) from the destination IMP, has 125 msec. in which to initiate the transfer of at least the first packet of a multi-packet message to the destination IMP. The source IMP may have several allocate responses queued up in which case these time-outs occur one after the other (one has to time-out before the next 125 msec time-out starts).
このプロトコルの要所は、aがIMPの出典を明示して、RFNMと暗黙のすべての後領収書が目的地IMPからの(8)であるということであり、125msecを持っています。. 少なくともマルチパケットメッセージの最初のパケットの転送を目的地IMPに起こす。 ソースIMPは数個にこれらのタイムアウトがどの場合に次々と起こるかへ(1つは次の125msecタイムアウトの前にタイムアウトに始めを持っています)列に並ばせられた応答を割り当てさせるかもしれません。
Time-outs exist in the source IMP which cause it to send INC? messages to the destination IMP if it has received no response from some earlier message.
タイムアウトはそれが何らかの以前のメッセージから応答を全く受けていないならそれにINC?メッセージを目的地IMPに送らせるソースIMPに存在しています。
Buffer Allocation
バッファ配分
A total of 40 buffers are available for store/forward and re-assembly purposes. At most 32 can be allocated for re-assembly, and at most 24-25 can be allocated for store and forward use. This prevents either kind of traffic from completely shutting out the other kind.
合計40のバッファが店/フォワードと再アセンブリ目的に利用可能です。 32を高々、再アセンブリのために割り当てることができて、店と前進の使用のために高々24-25に割り当てることができます。 これは、ちょっと交通が完全にもう片方の種類入らないようにするのを防ぎます。
Message Ordering (Source IMP-to-Destination IMP).
メッセージ注文(ソース悪童から目的地への悪童)。
As an aid to congestion control, an IMP can have at most 4 messages outstanding (un-RFNMed) for each other IMP. Link numbers in the message leader are ignored by the IMPs. Instead, IMPs mark messages leaving for other destinations with an 8-bit message number. In addition, a 2-bit priority number is also used in case a HOST has marked a message as a priority message. The key notion here is that the IMPs treat all HOSTs on a given IMP as if they were a single HOST. A single sequence of message and priority numbers is used in each direction between each pair of sites.
輻輳制御への援助として、IMPはほとんどの4つのメッセージで互いにおいて、傑出している(不-RFNMed)IMPを持つことができます。 メッセージリーダーのリンク番号はIMPsによって無視されます。 代わりに、IMPsは、8ビットのメッセージ番号で他の目的地に向けて発ちながら、メッセージをマークします。 さらに、また、HOSTが至急メッセージとしてメッセージをマークしたといけないので、2ビットの優先順位番号は使用されます。 IMPsがまるで彼らが独身のHOSTであるかのように与えられたIMPの上のすべてのHOSTsを扱うという主要な概念がここにあります。メッセージと優先順位番号のただ一つの系列はそれぞれの組のサイトの間の各方向に使用されます。
Cerf [Page 3] RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973
IMPSYS1973年1月のサーフ[3ページ]RFC442の現在のフロー制御計画
The receiving IMP remembers the message number of the last message delivered, as well as the priority number of the last priority message delivered. It uses this information to correctly sequence messages out the IMP-HOST line (s). Since there is only one sequence of numbers for each pair of sites, messages for one HOST at a site may get in the way of messages for another HOST at the same site. In fact, if some message, m, is the next in line to go to some HOST, and that HOST delays receipt for 30 seconds, any messages for another HOST may be delayed that long also. However, only the first message is lost, since the second one could not even start into its destination HOST until the first one had been delivered. There is a tighter coupling between HOSTs sharing an IMP than before, but not much tighter.
受信IMPは、最後のメッセージのメッセージ番号が配送されたのを覚えています、最後の至急メッセージの数が送った優先権と同様に。 それは、IMP-HOST線からメッセージを正しく配列するのにこの情報を使用します。 それぞれの組のサイトへの1つの数列しかないので、サイトの1HOSTへのメッセージは同じサイトの別のHOSTへのメッセージの邪魔をするかもしれません。 事実上、また、何らかのメッセージ(m)が線でいくらかのHOSTに行く次であり、そのHOSTが30秒間、領収書を遅らせるなら、別のHOSTへのどんなメッセージもそんなに長い間、遅れるかもしれません。 しかしながら、最初のメッセージだけが無くなります、最初のものを送ったとき2番目のものが初めて目的地HOSTに始まることさえできたので。 IMPを共有するHOSTsの間には、はるかにきつくないのにもかかわらずの、以前よりきついカップリングがあります。
An example of the use of message and priority numbers is given below.
メッセージと優先順位番号の使用に関する例は以下に出されます。
Order sent by Order received by Order received by Source IMP Dest. IMP HOST ---------- --------- ----
Orderによって送られた注文はSource IMP Destによって受け取られたOrderによって受信されました。 悪童ホスト---------- --------- ----
11,12P(1),13P(2),14 --> 13P(2),12P(1),14,11 --> 12P(1),13P(2),11,14
11 12P(1)、13P(2)、14-->13P(2)、12P(1)、14、11-->12P(1)、13P(2)、11、14
11,12P(1),13P(2),14 --> 13P(2),11,14,12P(1) --> 11,12P(1),13P(2),14
11 13P(2)、14-->13P(2)、11、14、12P(1)--12P(1)、>11、12P(1)、13P(2)、14
where 13P(2) is interpreted to mean message #13, priority number(2).
13P(2)がメッセージ#13を意味するために解釈されるところでは、優先順位番号(2)です。
Note that there are only 2 classes of messages, priority and non- priority, and that the priority numbers simply allow ordering at the destination of multiple outstanding priority transmissions from the same site.
2つのクラスのメッセージ、優先権、および非優先権しかなくて、優先順位番号が、複数の傑出している優先権送信の目的地で同じサイトに注文するのを単に許容することに注意してください。
If HOSTs use link numbers to de-multiplex messages to processes, then it would be a mistake to arbitrarily assign short messages priority. If a file transmission were carried out such that the last short message had priority, the file might not enter the receiving HOST in the same order it was sent!
HOSTsが反-メッセージを過程に多重送信するのにリンク番号を使用するなら、任意に短いメッセージ優先権を割り当てるのは、誤りでしょう。 ファイルトランスミッションが行われたので最後の短いメッセージに優先権があるなら、ファイルはそれが送られた同次に受信HOSTを入れないでしょうに!
ACK Mechanism
ACKメカニズム
IMPs treat their physical channels (phone lines) as if they were pairs of simplex communications paths. Each IMPSYS has a sender and receiver module for each full duplex channel. Each module has an "ODD/EVEN" bit which is used to keep track of the state of the last packet on the line. The object is for the sender module to "block" a channel until the corresponding receiver has received a packet indicating that the send packet was received on the other end (i.e. an acknowledgment).
IMPsはまるでそれらが組のシンプレクスコミュニケーション経路であるかのように彼らの物理的なチャンネル(電話回線)を扱います。 各IMPSYSには、それぞれの全二重チャンネルのための送付者と受信機モジュールがあります。 各モジュールには、線の上で最後のパケットの状態の動向をおさえるのに使用される「変であるか同等」のビットがあります。 パケットを送ってください。「物が対応する受信機がそれを示すパケットを受けるまで送付者モジュールがチャンネルを妨げる」ことである、もう一方の端(すなわち、承認)では、受け取りました。
Cerf [Page 4] RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973
IMPSYS1973年1月のサーフ[4ページ]RFC442の現在のフロー制御計画
In the present system, acknowledgments are separate IMP-IMP packets. In the new system, they are a single bit in a packet flowing in the opposite direction on the reverse path of a full duplex channel.
現行制度では、承認は別々のIMP-IMPパケットです。 新しいシステムでは、それらは全二重チャンネルの逆の経路の逆方向に流れるパケットの1ビットです。
Every packet sent between IMPs has an ACK bit and an OE bit, as shown below.
IMPsの間に送られたあらゆるパケットが以下に示されるようにACKビットとOEビットを持っています。
P A
O C
E K
+-------+-----+------------------------+-----+----------+
typical packet | | | | | |
| | | | | |
+-------+-----+------------------------+-----+----------+
PはO C E K+です。-------+-----+------------------------+-----+----------+ 典型的なパケット| | | | | | | | | | | | +-------+-----+------------------------+-----+----------+
We need some terminology: Let POE be the packet OE bit, and SOE, ROE be the send module OE bit and Receive module OE bit respectively. For two IMPs, A and B, we distinguish SOE/A and SOE/B as the two send module OE bits at IMPs A and B respectively.
私たちは何らかの用語を必要とします: POEがパケットOEビットと、SOEであることをさせてください、ROE、モジュールOEビットとそれぞれ噛み付かれたReceiveモジュールOEを送ってください。 2IMPs、A、およびBに関しては、2がIMPs AとBでそれぞれOEビットをモジュールに送るとき、私たちはSOE/AとSOE/Bを区別します。
The rules of operation are as follow:
操作の規則が続くようにあります:
Sender ------ if ACK != SOE then do nothing -- else SOE <- !SOE (i.e. flip SOE bit) and free channel. ----
送付者------ ACK!がSOEと等しいなら、何もしないでください--ほかのSOE<!SOE(すなわち、軽いSOEは噛み付いた)と無料のチャンネル。 ----
Receiver -------- if POE = ROE then packet is a duplicate so throw it away. -- else ROE <- !ROE ----
受信機-------- POEがROEと等しいならパケットが写しであるので、それを捨ててください。 -- ほかのROE<!ROE----
Whenever a packet is sent by the sent module, its two bits, POE and ACK are set up by:
送られたモジュールでパケットを送るときはいつも、2ビット、POE、およびACKは以下によってセットアップされます。
POE <- SOE
ACK <- ROE
ポー<SOE ACK<魚卵
The mechanism is designed to use real traffic to accomplish the acknowledgment protocol by piggy-backing the ACK bits in the header of real packets. If there is no real packet waiting for transmission in the opposite direction, a fake packet is assembled which carries the ACK, but which is not acknowledged by the receiving side.
メカニズムは、本当のパケットのヘッダーでACKビットを背負うことによって承認プロトコルを達成するのに本当の交通を使用するように設計されています。 逆方向にトランスミッションを待つどんな本当のパケットもなければ、にせのパケットは組み立てられます(ACKを運びますが、受信側によって承認されません)。
Cerf [Page 5] RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973
IMPSYS1973年1月のサーフ[5ページ]RFC442の現在のフロー制御計画
We give an example of the operation of this mechanism between two IMPs.
私たちはこのメカニズムの操作に関する例を2IMPsの間に出します。
IMP A IMP B
----- -----
ROE | SOE ROE | SOE
| POE ACK |
| +-----------+ |
IMP A blocks send 1 | 0 (1)| 0 1 |-> 1 | 0 IMP B NOPS,
channel. | +-----------+ | flips ROE
| |
| POE ACK |
| +-----------+ |
IMP A frees send 0 | 1 <-| 0 0 |(2) 0 | 0 IMP B blocks
channel, | +-----------+ | channel for
Flips SOE | | new traffic
| POE ACK |
IMP A blocks send | +-----------+ crashes|
channel | (3)| 1 0 |->or gets|
| +-----------+ lost |
| |
| POE ACK |
IMP A detects packet | +-----------+ |
duplicate (POE=ROE) 0 | 1 <-| 0 0 |(2) 0 | 0 IMP B
so does not change | +-----------+ | retransmits no
SOE bit. | | ACK received
| POE ACK |
IMP A retransmits | +-----------+ | IMP B flips
packet 3 | (3)| 1 0 |-> 1 | 1 SOE, unblocks
| +-----------+ | channel, and
| | flips ROE.
| POE ACK |
IMP A flips ROE, | +-----------+ |
flips SOE 1 | 0 <-| 1 1 |(4) |
| +-----------+ |
| |
悪童は悪童Bです。----- ----- 魚卵| SOE魚卵| SOE| ポーACK| | +-----------+ | IMP Aブロックは1を送ります。| 0 (1)| 0 1 |->1| 0IMP B NOPS、精神を集中してください。 | +-----------+ | ROEをはじき出します。| | | ポーACK| | +-----------+ | IMP Aが解放する、0を送ってください。| 1 <。| 0 0 |(2) 0 | 0 IMP Bはチャンネルを妨げます。| +-----------+ | Flips SOEには、精神を集中してください。| | 新しい交通| ポーACK| IMP Aブロックは発信します。| +-----------+ クラッシュ| チャンネル| (3)| 1 0 |->、得る。| | +-----------失われた+| | | | ポーACK| IMP Aはパケットを検出します。| +-----------+ | (POE=ROE)0をコピーしてください。| 1 <。| 0 0 |(2) 0 | 0 したがって、IMP Bは変化しません。| +-----------+ | SOEビットを全く再送しません。 | | ACKは受信しました。| ポーACK| IMP Aは再送します。| +-----------+ | IMP Bはパケット3をはじき出します。| (3)| 1 0 |->1| 1 SOE、非ブロック| +-----------+ | チャンネル| | ROEをはじき出します。 | ポーACK| IMP AはROEをはじき出します。| +-----------+ | SOE1をはじき出します。| 0 <。| 1 1 |(4) | | +-----------+ | | |
In fact each send/receive module has 8 OE bits, so up to 8 packets can be outstanding in either direction.
事実上、それぞれが、モジュールを送るか、または受けます。持っています。
How things really work
いろいろなことは本当にどう働いているか。
Actually, a single send module is responsible for trying to transmit packets out on the 8 pseudo-channels. Each channel has a two-bit state (in addition to an OE bit). Each channel is either FREE or IN USE and if IN USE, it may be sending OLD or NEW packet.
実際に、シングルがモジュールを送るaは8個の疑似チャンネルの外にパケットを伝えようとするのに責任があります。 各チャンネルには、安っぽい状態(OEビットに加えた)があります。 それぞれのチャンネルが無料である、IN USEとIN USE、それは発信OLDであるかもしれませんかNEWがパケットです。
Cerf [Page 6] RFC 442 The Current Flow-Control Scheme for IMPSYS January 1973
IMPSYS1973年1月のサーフ[6ページ]RFC442の現在のフロー制御計画
start state F = free
| I = in use
V X = don_t care
+-----+ +------+ N = new packet
| FX | --------------> | I, N | O = old packet
+-----+ +------+
^ |
| |
| |
| |
ACK | |
received | |
| V
| +------+
+-------------------| I, O |---+
+------+ |
^ | re-transmissions
+------+
=から無料で状態Fを始めてください。| 私=は中で氏_t V X=注意+を働かせます。-----+ +------新しい+ N=パケット| FX| -------------->| I、N| Oは古いパケット+と等しいです。-----+ +------+ ^ | | | | | | | ACK| | 受信します。| | | V| +------+ +-------------------| I、O|---+ +------+ | ^ | 再トランスミッション+------+
Between IMPs, packets are sent repeatedly, until they are acknowledged. However, the choice of what to send is ordered by priority as follows:
IMPsの間に、それらが承認されるまで、繰り返してパケットを送ります。 しかしながら、送るべきものの選択は優先的に以下の通り注文されます:
1. Priority Packets (as marked by HOST)
1. プリオリティ・パケット(HOSTによってマークされるように)
2. Non-Priority Packet
2. 非プリオリティ・パケット
3. Unacknowledged packets (on I,O state channels)
3. 不承認のパケット(IのO国営放送チャンネル)
4. Others
4. 他のもの
It was pointed out that a heavy load of type (1) and (2) traffic might prevent retransmissions from occurring at all, and W. Crowther responded that the bug would be fixed by a 125 ms time-out which forces retransmission of old packets in class (3).
タイプ(1)と(2)交通の重量物が、「再-トランスミッション」が全く現れるのを防ぐかもしれなくて、W.クラウザーが、バグがクラス(3)で古いパケットの「再-トランスミッション」を強制する125msタイムアウトによって修理されていると応答したと指摘されました。
Note that each packet must carry a "pseudo-channel" number to identify the POE-to-channel association, and 8 ACK bits (which are positionally associated with the pseudo-channels). Thus a single packet can ACK up to 8 packets at once.
各パケットがPOEからチャンネルへの協会、および8ACKビット(疑似チャンネルに関連している位置である)を特定するために「疑似チャンネル」番号を運ばなければならないことに注意してください。 したがって、a単一のパケット缶のACKはすぐに、8つのパケットへ上昇します。
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Helene Morin, Via Genie, 12/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、Via GenieによるオンラインRFCアーカイブへの12/99]
Cerf [Page 7]
サーフ[7ページ]
一覧
スポンサーリンク
