RFC700 日本語訳
0700 Protocol experiment. E. Mader, W.W. Plummer, R.S. Tomlinson. August 1974. (Format: TXT=14600 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
NWG/RFC 700 August 1974 NIC 31020 INWG Experiments Note 1
NWG/RFC700 1974年8月のNIC31020INWGは注意1を実験します。
A Protocol Experiment
プロトコル実験
Eric R. Mader William W. Plummer Raymond S. Tomlinson
エリック・R.マーダー・ウィリアム・W.プラマー・レイモンド・S.トムリンスン
I. Introduction
I. 序論
In early February, 1974 the main line printer on BBN's TENEX system failed and it was decided to use the PDP-11 line printer via the ARPANET both for the direct purpose of obtaining listings and also the indirect purpose of studying network protocols.
1974年2月の上旬では、BBNのTENEXシステムの上の本線のプリンタは失敗しました、そして、それは、リストを入手するダイレクト目的とネットワーク・プロトコルを研究する間接的な目的のためにアルパネットでもPDP-11ラインプリンタを使用するために決められました。
II. The Basic Protocol
II。 基本プロトコル
The design was based on the protocol described by Cerf and Kahn in INWG Note #39. Familiarity with that document is assumed. The following is a brief sketch of the protocol. Not all features described in this section have been implemented. See Section VI.
デザインはINWG Note#39でサーフとカーンによって説明されたプロトコルに基づきました。 そのドキュメントへの親しみは想定されます。 ↓これはプロトコルの簡潔なスケッチです。 このセクションで説明されたというわけではないすべての特徴が実行されました。 セクションVIを見てください。
At any instant, the sender has two pointers into the stream of bytes to be sent. Bytes to the left of the LEFT pointer have already been sent and acknowledged. Bytes in the "window" between the LEFT and RIGHT pointers have been sent (zero or more times), but no indication of successful transmission has been received. Bytes to the right of RIGHT remain to be considered at some time in the future.
どんな瞬間にも、送付者は送られるバイトの流れの中に2個のポインタを持っています。 LEFTポインタの左へのバイトは、既に送られて、承認されました。 LEFTとRIGHTポインタの間の「窓」のバイトに(ゼロか、より多くの回)を送りましたが、うまくいっているトランスミッションのしるしを全く受け取っていません。 RIGHTの右へのバイトは、いつかこれから先考えられるために残っています。
In operation the sender is constantly sending bytes from the input data stream resulting in the RIGHT pointer advancing. Positive acknowledgements produced by the receiver cause the LEFT edge of the window to move towards the RIGHT edge.
稼働中であり、送付者は入力データ・ストリームからのバイトにRIGHTポインタ前進を絶えずもたらさせます。 受信機によって起こされた積極的な承認で、窓のLEFT縁はRIGHT縁へ向かいます。
LEFT and RIGHT are actually numerical byte positions within the data stream. The low order 16 bits of RIGHT are sent with each message as a sequence number so that the receiver can identify which part of the data stream it is receiving in case messages are not received in the same order they were transmitted. The receiver has a finite amount of buffer space available in which it can reassemble an image of the data in the transmitter's window. The receiver discards any messages which have sequence numbers outside of its buffer area. However, messages to the left of LEFT must be acknowledged even though they are discarded. Otherwise, a lost ACK would cause the sender to retransmit (and the receiver ingore) the message indefinitely. Messages received with bad checksums are also discarded.
LEFTとRIGHTはデータの中の見解が流す実際に数字のバイトです。 受信機が、それらがメッセージが同次で受け取られないといけないのでそれが受けているデータ・ストリームのどの部分であるかを伝えられた状態で特定できるようにRIGHTの16ビットが各メッセージと共に一連番号として送られる下位。 受信機には、それが送信機の窓でデータのイメージを組み立て直すことができる限られた額の利用可能なバッファ領域があります。 受信機は緩衝地帯の外に一連番号を持っているどんなメッセージも捨てます。 しかしながら、それらは捨てられますが、LEFTの左へのメッセージを承認しなければなりません。 さもなければ、無くなっているACKは送付者にメッセージを無期限に再送させるでしょう(そして、受信機「不-流血」)。 また、悪いチェックサムで受け取られたメッセージは捨てられます。
As "good" messages are received, the holes are filled in the receiver's buffer and continuous segments at the left edge are passed to the physical line printer (in our case). The receiver informs the sender of Page 2
「良い」メッセージが受信されているので、穴は受信機のバッファでふさがれます、そして、左の縁の連続したセグメントは物理行プリンタ(私たちの場合における)に通過されます。 受信機は2ページについて送付者に知らせます。
this action by sending an ACK (acknowledgement) message. This message specifies the sequence number of the byte it would like to receive next (the new value of LEFT in the sender) and the current amount of buffer space it has available (new maximum window width in the sender). The sender ignores ACK's to the left of LEFT and to the right of RIGHT. Thus, both the sender and receiver are prepared to handle multiple copies of messages.
ACK(承認)メッセージを送るのによるこの動作。 このメッセージはそれが次に受けたがっているバイトの一連番号(送付者のLEFTの新しい値)とそれが利用可能にする現在の量のバッファ領域(送付者の新しい最大のウィンドウ幅)を指定します。 送付者はLEFTの左と、そして、RIGHTの右にACKのものを無視します。 したがって、送付者と受信機の両方が複本に関するメッセージを扱うように準備されます。
Failures such as messages with bad checksums, messages lost during transmission (data and ACK's), and messages discarded due to sequences numbers which were apparently out of range, all manifest themselves to the sender as a dropped ACK. A dropped ACK will cause the sender's LEFT edge to stop advancing, leaving the unacknowledged message at the left of the sender's window, and possibly a corresponding hole at the left of the receiver's image of the window. Eventually, transmission will cease and a (10 second) timeout will trigger in the sender, causing retransmission of all data within the window. Note that at the instant of a timeout, there is no guarantee that the un-ACK'd message will be exactly at the left edge of the window or that it is the only unacknowledged message in the window. Retransmissions are likely to cause the receiver to see data that it has seen before, but duplicate messages will be discarded due to sequence number considerations.
悪いチェックサムがあるメッセージなどの失敗(トランスミッション(データとACKのもの)の間に失われたメッセージ、および明らかな範囲から脱していた系列番号のため捨てられたメッセージ)は、低下しているACKとして送付者にすべて現れます。 低下しているACKは送付者のLEFT縁に進むのを止めさせるでしょう、送付者の窓左側の不承認のメッセージ、および受信機の窓のイメージ左側ことによると対応する穴を残して。 結局、トランスミッションはやむでしょう、そして、(10秒)の間のタイムアウトは送付者で引き金となるでしょう、窓の中のすべてのデータの「再-トランスミッション」を引き起こして。 タイムアウトの瞬間に、不-ACKがそうしているだろうというメッセージがちょうど窓の左の縁にあるか、それが唯一の不承認のメッセージであるという保証が全く窓にないことに注意してください。 Retransmissionsは受信機がそれが以前見たことがあるデータを見ることを引き起こしそうですが、写しメッセージは一連番号問題のため捨てられるでしょう。
III. "Say Again"
III。 「もう一度言ってください」
An extension to the INWN #39 protocol which was implemented was the ability to let the receiver force retransmission of the entire window by turning on a flag in any message back to the sender. This is useful in cases where the receiver believes that a data message has been dropped and it wants to force retransmission rather than wait for a timeout in the sender. Clearly, this relies on the network to preserve ordering of the messages. Also, it is not useful if the error rate is high because the whole window is retransmitted in order to get retransmission of a single message or two.
実行されたINWN#39プロトコルへの拡大は受信機にどんなメッセージでも旗を送付者につけて戻すことによって全体の窓の「再-トランスミッション」を強制させる能力でした。 これは受信機がデータメッセージが落とされて、送付者のタイムアウトを待っているよりむしろ「再-トランスミッション」を強制したがっていると信じている場合で役に立ちます。 明確に、これは、メッセージの注文を保存するためにネットワークを当てにします。 また、全体の窓が1か2つのただ一つのメッセージの「再-トランスミッション」を手に入れるために再送されるので誤り率が高いなら、役に立ちません。
IV. Establishing an Association
IV。 協会を設立します。
In the experiment two flags were used to establish an association. FRST (FiRST flag) was the equivalent of SYN described in INWG Note #39 and served to identify the first message of an association. This instructed the receiver to accept the sequence number in the message as a definition of the starting point of sequence numbers for the association.
実験では、2個の旗が、協会を証明するのに使用されました。 FRST(FiRSTは弛む)は、INWG Note#39で説明されたSYNの同等物であり、協会の最初のメッセージを特定するのに役立ちました。 これは、協会のために一連番号の出発点の定義としてメッセージで一連番号を受け入れるよう受信機に命令しました。
The second flag is a receiver-to-sender flag called HUH which is a request by the receiver for a definition of the sequence numbers. Upon receipt of a message containing an HUH, the sender responds by turning on FRST in the next data message. Normally, HUH is sent only if the receiver had been restarted, or if it is replying to messages on a port Page 3
2番目の旗は受信機から送付者への一連番号の定義のために受信機によって要求であるHUHと呼ばれる旗です。 HUHを含むメッセージを受け取り次第、送付者は、次のデータメッセージでFRSTをつけることによって、応じます。 通常、受信機が単に再開されたか、またはそれがポート3ページでメッセージに答えているなら、HUHを送ります。
that it knows is not part of an association.
知るのは、協会の一部ではありません。
V. A Problem
V。 問題
A severe problem uncovered with the protocol was concerned with establishing an association. If the PDP-11 (receiver) was reloaded while the spooler (sender) was running, the first few pages of the data stream were printed about six times before normal operation was established. The cause was traced to the following sequence of actions:
プロトコルで発見された厳しい問題は協会を設立するのに関係がありました。 スプーラ(送付者)が走っていた間、PDP-11(受信機)が再び積まれたなら、通常の操作が確立される前にデータ・ストリームの最初の数ページがおよそ6回印刷されました。 原因は動作の以下の系列にたどられました:
1. The sender would be in a loop, timing out and retransmitting because the receiver had not responded.
1. 受信機が応じていなかったので、外で調節して、再送して、送付者は輪にいるでしょう。
2. Upon being restarted, the receiver would see a whole window's worth of messages, and respond to each with an HUH.
2. 再開されるとき、受信機は、全体の窓のメッセージの価値を見て、HUHと共にそれぞれに応じるでしょう。
3. For each HUH the sender would reset the window and include a FRST flag with the first message in each of the (six) retransmissions.
3. 各HUHに関しては、送付者は、それぞれの(6)「再-トランスミッション」における最初のメッセージで窓をリセットして、FRST旗を入れるでしょう。
4. The receiver would see the first message of the first retransmission containing a FRST, accept the sequence number, and print the data from that and the following messages. Then, another message containing the FRST flag would appear and the cycle would repeat (five more times). Note that the ACK's generated in the repetitions were ignored by the sender because they were to the left of the window.
4. 受信機は、それと以下のメッセージからFRSTを含む最初の「再-トランスミッション」の最初のメッセージを見て、一連番号を受け入れて、データを印刷するでしょう。 次に、FRST旗を含む別のメッセージが現れるでしょう、そして、サイクルは繰り返されるでしょう(もう5回)。 窓の左にはそれらがあったので、ACKが反復で発生したというメモは送付者によって無視されました。
As a "cure" for the above the receiver program was modified so that after sending an HUH, messages are ignored until one with a FRST flag appears. This solution is unacceptable in general because it leaves the receiver port useless if either the message containing the HUH or the response gets lost in transmission. Although a timeout was used to guard against this, the timeout cannot be trusted because it might cause two messages with FRST flags to be received -- just the problem which is being avoided!
上記の「療法」として受信機プログラムが変更されたので、HUHを送った後に、FRST旗をもっている人が現れるまで、メッセージは無視されます。 HUHを含むメッセージか応答のどちらかがトランスミッションで失せるなら役に立たない状態で受信機ポートを出るので、一般に、この解決策は容認できません。 タイムアウトはこれに用心するのに使用されましたが、それでFRST旗がある2つのメッセージを受け取るかもしれないので、タイムアウトを信じることができません--まさしく避けられている問題!
An alternate cure which does not depend on the network to be lossless would be to modify the sender to respond to a HUH by ignoring all messages for at least a round trip delay time before sending its response containing the FRST flag. This results in having to define what this time is. In general this cannot be done when messages can become trapped for indefinite amounts of time in network partitions. This will be discussed more fully in a subsequent document. Page 4
losslessになるようにネットワークに頼らない交互の療法はHUHにFRST旗を含む応答を送る前に少なくとも周遊旅行遅延時間の間のすべてのメッセージを無視することによって反応させる送付者を変更するだろうことです。 今回が何であるかを定義しなければならないのにこれは結果として生じます。 一般に、メッセージがネットワークパーティションにおける無期量の時間捕らえられるようになることができるなら、これができません。 その後のドキュメントでこれについて、より完全に議論するでしょう。 4ページ
VI. Features not Investigated
VI。 調査されなかった特徴
None of the programs to date have supported any of the following features:
これまでのプログラムのいずれも以下の特徴のいずれも支持していません:
1. Window size control. The window size was a constant (2048 bytes). In a future experiment the window size will be varied not only by indications of buffer space in the receiver, but also as a function of estimated transit time. (see below).
1. ウィンドウサイズコントロール。 ウィンドウサイズは定数(2048バイト)でした。 今後の実験では、ウィンドウサイズは受信機のバッファ領域のしるしとして変えられるだけではなく、およそトランジット時間の関数としても変えられるでしょう。 (以下を見ます。)
2. Reassembly. Since reassembly is conceptually easy, it is likely to be one of the first extensions. A message corrupter will be included in the receiver to test the functioning of the reassembly mechanism.
2. Reassembly。 再アセンブリが概念的に簡単であるので、それは最初の拡大の1つである傾向があります。 メッセージ堕落させる人は、再アセンブリメカニズムの機能をテストするために受信機に含まれるでしょう。
3. Expanded Internetwork Addresses
3. 拡張インターネットワークアドレス
4. Multiple Associations
4. 複数の協会
5. Reliable Making and Breaking of Associations
5. 信頼できる型と協会を矯正すること。
VII. Implementations Notes
VII。 実現注意
The sender involves approximately ten pages of assembly code for the network message interface. Two processes are involved: one which fills a buffer by reading the input data stream, and a second process which sends network messages from the buffer and processes replies from the receiver. The two processes are joined by a coroutine mechanism, but in the future will be two parallel TENEX processes.
送付者はおよそ10ページのアセンブリコードにネットワークメッセージインタフェースにかかわります。 2つの過程がかかわります: バッファをいっぱいにするものが、バッファと過程から受信機からデータ・ストリーム、およびネットワークメッセージを送る2番目の過程を入力に読み込むことによって、返答します。2つの過程が、コルーチンメカニズムによって接合されますが、将来、2つの平行なTENEXの過程になるでしょう。
The receiver program consists of approximately four pages of BCPL code in addition to IO device drivers and routines which implement queueing primitives.
受信機プログラムは待ち行列基関数を実行するIOデバイスドライバとルーチンに加えたおよそ4ページのBCPLコードから成ります。
Each message contained between zero and 255 bytes of data arranged (as a coding convenience) in a way which is directly compatible with the BCPL string handling routines. Messages contained a single byte of checksum which was the low eight bits of the twos complement negation of the twos complement sum of all other bytes in the message. We recommend that some more reliable checksum function be employed in the future; even using eight-bit ones complement arithmetic would be better.
ゼロと255バイトのデータの間に含まれた各メッセージは直接BCPLストリング取り扱いルーチンと互換性がある方法で手配されました(コード化便利として)。 メッセージはメッセージでの他のすべてのバイトの2補数合計の2補数否定の低8ビットであった1バイトのチェックサムを含みました。 私たちは、それ以上の信頼できるチェックサム機能が将来使われることを勧めます。 8ビットのもの補数の演算を使用してさえいるほうがよいでしょう。
Source files for the various programs are available from the authors at Bolt Beranek and Newman, 50 Moulton Street, Cambridge Mass., 02138. Page 5
様々なプログラムのためのソースファイルはBolt Beranekとニューマンの作者、50モールトン通り、ケンブリッジマサチューセッツ州02138から利用可能です。 5ページ
VIII. Simple Rate Calculations
VIII。 簡単なレート計算
If we assume that an active association has reached steady state, that processing delays are lumped into the transit time T, and that there are no errors, then the maximum data rate may be calculated as follows.
私たちが活動的な協会が定常状態に達して、処理遅れがトランジット時間Tまでひとまとめにされて、誤りが全くないと思うなら、最大のデータ信号速度は以下の通り計算されるかもしれません。
Assume the sequence numbers being passed by the RIGHT pointer are some function of time, R(t). Messages received by the receiver will be the same function of time but delayed T (a transit time) seconds. Since processing time is zero, the acknowledgments will bear this same function, R(t-T). Acknowlegements received by the sender will have sequence numbers R(t-2T).
R(t)、RIGHTポインタによって通過される一連番号が時間の何らかの関数であると仮定してください。 受信機によって受け取られたメッセージは時間にもかかわらず、遅れたT(トランジット時間)秒の同じ関数になるでしょう。 R、処理時間がゼロであるので、承認はこの同じ機能に堪えるでしょう(t-T)。 送付者によって受け取られたAcknowlegementsは一連番号R(t-2T)を持つでしょう。
Acknowledgements at the sender determine the LEFT pointer, L(t). Also, it is known that R(t) is ahead of L(t) by the width of the window which is a constant in steady state. Thus, we have the two relations:
送付者での承認はLEFTポインタ、L(t)を決定します。 また、定常状態において定数である窓の幅に従ってR(t)がL(t)の前にあるのが知られています。 したがって、私たちには、2つの関係があります:
L(t) = R(t-2T) L(t) = R(t) - W
L(t)はR(t-2T)L(t)=R(t)--Wと等しいです。
Now, let R(t) = Bt, i.e., sequence numbers are increasing linearly with time. (Microscopically, short bursts will alternate with longer periods of inactivity, but the average bandwidth will be B.) The result under the assumptions is that the bandwidth is:
今度は、R(t)にBtと等しくしさせてください、そして、すなわち、時間に従って、一連番号は直線的に増加しています。 (極めて微細に、短い炸裂は、より長い期間の不活発と交替するでしょうが、平均した帯域幅はB.になるでしょう) 仮定での結果は帯域幅が以下の通りということです。
B = W/2T .
BはW/2Tと等しいです。
That is, the bandwidth in bytes per second is just the steady state window width divided by the round trip delay time. Conversely, the aboe relation can be determine the buffer sized needed: in oreder for thee receiver to guarantee to accept information that was transmitted, it must supply buffering equal to (or greater than) the window size. The window size must be equal to or greater than the desired bandwidth times the round-trip delay time, i.e. equal to the number of messages in a round-trip "pipeline".
すなわち、1秒あたりのバイトにおける帯域幅はただ周遊旅行遅延時間が割られた定常状態ウィンドウ幅です。 逆に、aboe関係は必要な状態で大きさで分けられたバッファを決定することであるかもしれません: あなたのためのorederでは、保証する受信機が伝えられた情報を受け入れて、等しい状態でバッファリングを供給しなければならない、(よりすばらしい、)、ウィンドウサイズ。 ウィンドウサイズは必要な帯域幅より等しいかすばらしい回が往復の遅延時間であったならそうしなければなりません、すなわち、往復の「パイプライン」のメッセージの数への同輩。
The bandwidth in the presence of a relatively low error rate may be calculated. Assume that B and W are expressed in terms of (full) messages rather than byte numbers. Each error has two effects: a time out delay of D seconds and retransmission of W messages. So, the time Q(M,N) required to transmit M messages burdened by N errors is the sum of the time to transmit the data once, N*D seconds of time out delay, and the time to transmit the window N more times.
比較的低い誤り率があるとき帯域幅は計算されるかもしれません。 BとWがバイト番号よりむしろ(完全)のメッセージで言い表されると仮定してください。 各誤りには、2つの効果があります: D秒のタイムアウト遅れとWメッセージの「再-トランスミッション」。 それで、メッセージがN誤りで負ったMはQ(M、N)が伝わるのが必要である時の一度データを送る時間、N*D秒のタイムアウト遅れ、および、より多くの回窓Nを伝える現代の合計です。
Q(M,N) = (2T/W)*M + N*D + N*2T
Q(M、N)=(2T/W)*M+N*D+N*2T
Dividing by M to get time per message and multiplying the last term by (W/W):
1メッセージあたりの時間を得るためにM分割して、最後の学期間、掛けます(Wと共に):
Q(M,N)/M = (2T/W) + (N/M)*D + (2T/W)*(N/M)*W .
(2T/W)+(ニュートン毎メートル)*D+(2T/W)*(ニュートン毎メートル)Q(M、N)/M=*W。
But (M/N) is just the fraction of messages in error. Call this E. Page 6
しかし、(M/N)は間違いメッセージの部分です。 このE.6ページ人に電話をしてください。
Q(E) = (2T/W)*(1 + EW) + ED
Q(E)は*(1+EW)+エドと等しいです(2T/W)。
B(E) = 1/[(2T/W)(1+EW) + ED]
B(E)=1/(2T/W)(1+EW)+エド]
The advantage to using the "say again" mechanism (Section III.) can now be seen: it forces D to be zero, allowing a reasonable average data rate in the presence of errors. Note the effect of a 10 second time out on a network with an E of 0.01, assuming W to be 20 messages and T of 0.5 second. B(D=10) is 6.7, but with forced retransmission, B(D=0) is 20.
今、「もう一度言ってください」メカニズム(セクションIII)を使用する利点を見ることができます: 誤りがあるとき妥当な平均したデータ信号速度を許容して、それは、Dがゼロであることを強制します。 0.01Eで10秒のタイムアウトのネットワークへの効果に注意してください、Wが0.5秒が20メッセージとTであると仮定して。 B(D=10)は6.7ですが、無理矢理の「再-トランスミッション」で、B(D=0)は20です。
IX. A Sequence Number Consideration
IX。 一連番号の考慮
In order to reject duplicate messages, sequence numbers must contain a sufficient number of bits such that it is impossible to cycle through more than half the sequence number space in a message lifetime at maximum transmission rate. Assuming a 1 MegaByte per second network and a maximum lifetime of 500 seconds, the sequence number field of each message must be capable of holding the number 2*500*10**6 which is 10**9 or about 2**30. Thus, a 32-bit (4-byte) sequence number field is recommended.
一連番号が写しメッセージを拒絶するために十分な数のビットを含まなければならないので、メッセージ生涯一連番号スペースの半分以上を通して最大の通信速度で循環するのは不可能です。 2番目のネットワークあたり1MegaByteと最大500秒の生涯を仮定する場合、それぞれのメッセージの一連番号分野は10**9かおよそ2**30であるNo.2*500*10**6を保持できなければなりません。 したがって、32ビット(4バイト)の一連番号分野はお勧めです。
X. Additional Control Functions
X。 追加コントロール機能
In response to an attempt to establish an association (SYN) it is felt that the receiver should be able to deny the attempt (RELease) in one of the following three ways:
協会(SYN)を設立する試みに対応して、受信機が以下の3つの方法の1つで、試み(RELease)を否定するはずである場合があると感じられます:
REJECT. (I'm busy. Try again later.) ABORT. (I don't understand what you are sending. (Bad port, etc.)) ABNORMAL (SYN arrived on a established connection.) (Receiver breaks connection and issues this REL.)
拒絶します。 (私は忙しいです。 後でもう一度試みてください。) 中止になってください。 (私は、あなたが何を送るかを理解していません。 (悪いポートなど)) ABNORMAL(SYNは確立した接続に到達しました。) (受信機は、接続を調教して、このRELを発行します。)
During an established association, the sender should be able to RELease the association in either of these ways:
設立された協会の間、送付者がRELeaseにできるべきである、これらの方法のどちらかの協会:
DONE. (I'm done sending to you.) GAG. (Stop. You are sending garbage (ACK's).)
。 (私はあなたに発信し終わっています。) ギャグを言ってください。 (止まってください。 あなたはゴミ(ACKのもの)を送ります。)
These may be coded as combinations of bits in the FLAGS which are convenient for programming.
これらはプログラミングが都合がよいFLAGSのビットの組み合わせとしてコード化されるかもしれません。
一覧
スポンサーリンク