RFC59 日本語訳

                          Edwin W. Meyer, Jr.
                            MIT Project MAC
                              27 June 1970

エドウィン・W.マイヤー、Jr.MITプロジェクトMAC1970年6月27日

The method of flow control described in RFC 54, prior allocation of
buffer space by the use of ALL network commands, has one particular
advantage. If no more than 100% of an NCP's buffer space is allocated,
the situation in which more messages are presented to a HOST then it can
handle will never arise.

RFC54で説明されたフロー制御の方法(すべてのネットワークコマンドの使用によるバッファ領域の先の配分)には、1つの特定の利点があります。 NCPのバッファ領域の100%未満を割り当てると、より多くのメッセージがHOSTに提示されて、次にそれが扱われることができる、状況は決して起こらないでしょう。

However, this scheme has very serious disadvantages:

しかしながら、この計画には、非常に重大な損失があります:

(i)  chronic underutilization of resources,

(i) リソースの慢性の過少利用

(ii) highly restricted bandwidth,

(ii) 高く制限された帯域幅

(iii)considerable overhead under normal operation,

(iii)通常の操作でのかなりのオーバーヘッド

(iv) insufficient flexibility under conditions of increasing load,

(iv) 負荷を増加させるという条件での不十分な柔軟性

(v)  it optimizes for the wrong set of conditions, and

(v) そしてそれが間違ったセットの状態のために最適化される。

(vi) the scheme breaks down because of message length indeterminacy.

(vi) 計画はメッセージ長不確定で故障します。

Several people from Project MAC and Lincoln Laboratories have discussed
this topic, and we feel that the "cease on link" flow control scheme
proposed in RFC 35 by UCLA is greatly preferable to this new plan for
flow control.

Project MACからの数人とリンカーン研究所はこの話題について議論しました、そして、私たちはRFC35でUCLAによって提案された「リンクの上にやんでください」フロー制御計画がフロー制御のためのこの新しいプランより大いに望ましいと感じます。

The method of flow control proposed in RFC 46, using BLK and RSM control
messages, has been abandoned because it can not guarantee to quench flow
within a limited number of messages.

限られた数のメッセージの中で流れを冷却するのを保証できないので、BLKを使用して、RFC46で提案されたフロー制御とRSMコントロールメッセージの方法は捨てられました。

The advantages of "cease on link" to the fixed allocation proposal are
that:

固定配分提案への「リンクの上にやんでください」の利点は以下のことということです。

(i)  it permits greater utilization of resources,

(i) それはリソースの、より大きい利用を可能にします。

(ii) does not arbitrarily limit transmission bandwidth,

(ii) 任意に、トランスミッション帯域幅を制限しません。

(iii)is highly flexible under conditions of changing load,

(iii)変化するという非常にフレキシブルな下の条件は負荷です。

(iv) imposes no overhead on normal operation, and

(iv) そして通常の操作にオーバーヘッドを全く課さない。

(v)  optimizes for the situations that most often occur.

(v) たいてい起こる状況のために、最適化します。

Its single disadvantage is that under rare circumstances an NCP's input
buffers can become temporarily overloaded. This should not be a serious
drawback for network operation.

ただ一つの不都合はまれな状況で、NCPの入力バッファが一時積みすぎられるようになることができるということです。 これはネットワーク操作のための重大な欠点であるべきではありません。

The "cease on link" method of flow control operates in the following

フロー制御の「リンクの上にやんでください」方法は以下で作動します。

                                                                [Page 1]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation

[1ページ]NWG/RFC59フロー制御--要求に対して固定された配分

manner.  IMP messages for a particular "receive" link may be coming in
to the destination HOST faster than the attached process is reading them
out of the NCP's buffers. At some point the NCP will decide that the
input queue for that link is too large in relation to the total amount
of free NCP buffer space remaining. At this time the NCP initiates
quenching by sending a "cease on link" IMP message to its IMP. This does
nothing until the next message for that link comes in to the destination
IMP. The message still gets transmitted to the receiving HOST. However,
the RFNM returned to the transmitting HOST has a special bit set. This
indicates to the originating NCP that it should stop sending over that
link. As a way of confirming the suspension, the NCP sends an SPD <link>
"suspended" NCP control message to the receiving HOST, telling it that
it indeed has stopped transmitting. At a future time the receiving pro-
cess will have cut the input queue for the link down to reasonable size,
and the NCP tells the sending NCP to begin sending messages by issuing a
RSM <link> "resume" NCP control message.

方法。 「受信してください」という特定のリンクへのIMPメッセージを目的地HOSTに付属過程がNCPのバッファからそれらを読むことであるより速く入らせているかもしれません。 何らかのポイントでは、NCPは、そのリンクへの入力キューが自由なNCPバッファ領域の残りの総量と関連して大き過ぎると決めるでしょう。 このとき、NCPは、「リンクの上にやんでください」IMPメッセージをIMPに送ることによって、冷却を開始します。 これはそのリンクへの次のメッセージを目的地IMPに入らせるまで何もしません。 メッセージはまだ受信HOSTに伝えられています。しかしながら、伝わっているHOSTに返されたRFNMは特別な噛み付いているセットを持っています。 これは、そのリンクを移動するのを止めるべきであるのを由来しているNCPに示します。 サスペンションを確認する方法として、NCPはSPD<リンク>「吊した」NCPコントロールメッセージを受信HOSTに送ります、本当に、伝わるのを止めたとそれに言って。 将来の時間に、受信親課税はリンクに入力キューを妥当なサイズまで切ってしまうでしょう、そして、NCPはRSM<リンク>「履歴書」NCPコントロールメッセージを発行することによってメッセージを送り始めるように送付NCPに言います。

The flow control argument is based on the following premises:

フロー制御議論は以下の構内に基づいています:

(1)  Most network transmission falls into two categories:
     Type 1 - short messages (<500 bits) at intervals of several seconds
     or more. (console communication)
     Type 2 - a limited number (10 - 100) of full messages (8000 bits)
     in rapid succession. (file transmission)

(1) ほとんどのネットワーク送信が2つのカテゴリになります: 1をタイプしてください--数秒か以上ごとの短いメッセージ(<500ビット)。 (コンソールコミュニケーション) 2をタイプしてください--矢つぎばやな限られた数(10--100)の完全なメッセージ(8000ビット)。 (ファイルトランスミッション)

(2)  Most processes are ready to accept transmitted data when it arrives
     at the destination and will pick it up within a few seconds (longer
     for large files). Thus, at any particular instant the great major-
     ity of read links have no data buffered at the destination HOST.
     This assumes a sensible software system at both ends.

(2) 目的地に到着して、数秒以内にそれを拾うとき、ほとんどの過程が伝えられたデータを受け入れる準備ができています(大きいファイルには、より長い)。 したがって、読書のすばらしい主要なityがリンクされる特定の瞬間に、どんなどんなデータも目的地でHOSTをバッファリングしていませんか?これは両端で分別があるソフトウェア・システムを仮定します。

(3)  Flow control need be imposed only rarely on links transmitting Type
     1 messages, somewhat more frequently for Type 2 messages.

(3) フロー制御はめったにだけType1メッセージ、Typeのためのいくらか頻繁の2つのメッセージを送るリンクに課されなければなりません。

(4)  Both the total network load and that over a single connection fluc-
     tuate and can not be adequately predicted by either the NCP or the
     process attached to an individual connection.

(4) NCPによって予測されて、合計が、ともに、単独結合fluc- tuateの上で負荷とそれをネットワークでつないで、適切にネットワークであるはずがありません、または過程は個々の接続に付きました。

(5)  Assuming adequate control of wide bandwidth transmission (Type 2),
     the probability that an NCP will be unable to accept messages from
     the IMP due to full buffers is quite small, even if the simultane-
     ous receipt of moderately small messages over all active links
     would more than fill the NCP's input buffers.

(5) 広い帯域幅トランスミッション(2をタイプする)の適切なコントロールを仮定して、NCPが完全なバッファのためIMPからメッセージを受け入れることができないという確率はかなりわずかです、すべてのアクティブなリンクの上の適度に小さいメッセージのsimultane- ous領収書がさらにそうしてもNCPの入力バッファをいっぱいにしているより。

(6)  In the event that an NCP's buffers do fill completely, it may
     refuse to accept any transmission from the IMP for up to a minute
     without utter catastrophe.

(6) NCPのバッファが完全にいっぱいになる場合、それは、全くのカタストロフィーのない1分までIMPからどんなトランスミッションも受け入れるのを拒否するかもしれません。

                                                                [Page 2]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation

[2ページ]NWG/RFC59フロー制御--要求に対して固定された配分

(7)  Under cases of extreme input load, if an NCP has large amounts of
     data buffered for input to a local process, AND that process has
     not read data over that connection for more than a minute, the NCP
     may delete that data to make space for messages from the IMP. This
     is expected to happen extremely rarely, except in cases where the
     process is the main contributor to the overload by maintaining
     several high volume connections which it is not reading.

(7) 入力のためにNCPで多量のデータをローカルの過程にバッファリングして、その過程が1分間以上その接続の上でデータを読んでいないなら、極端な入力負荷の場合の下ではNCPは、IMPからメッセージのためのスペースを作るためにそのデータを削除するかもしれません。 これが非常にめったに起こらないと予想されます、ケースを除いて中過程がそれが読んでいないいくつかの高いボリューム接続を維持するのによるオーバーロードへの主な貢献者である。

Based on the preceding premises, I see the following disadvantages in
the flow control proposed in RFC 54:

前の構内に基づいて、私はRFC54で提案されたフロー制御で以下の損失を見ます:

(1)  Chronic Underutilization of Resources - A fixed allocation of
     buffer space dedicated to a single Type 1 connection will go
     perhaps 90% unused if we actually achieve responsive console
     interaction through the network. This is because it is empty most
     of the time and is very seldom more than partially filled. Stated
     conversely, a scheme of demand allocation might be expected to han-
     dle several times as many console connections using the same buffer
     resources. (It has been suggested that this problem of underutili-
     zation could be alleviated by allocating more than 100% of the
     available buffer space. This is in fact no solution at all, because
     it defeats the basic premise underlying this method of flow con-
     trol: guaranteed receptivity. True, it might fail in less than one
     case in 1000, but that is exactly the case for which flow control
     exists.)

Resourcesの(1)の慢性のUnderutilization--私たちが実際にネットワークを通した敏感なコンソール相互作用を達成するなら、バッファ領域の固定配分は意志順調な恐らく90%を独身のType1接続に未使用で捧げました。 これはそれがたいてい空であり、部分的にいっぱいにされるほど非常にめったに多くないからです。 逆に述べられていて、要求配分の計画は、多くのコンソール接続として同じバッファ資源を使用することでhan- dleに何度か予想されるかもしれません。 (利用可能なバッファ領域の100%以上を割り当てることによってunderutili- zationのこの問題を軽減できるだろうことが提案されました。 事実上、これは全く解決策ではありません、流れまやかしtrolのこの方法の基礎となりながら根本的な前提を破るので: 保証された感受性。 本当に、1000年に1つ未満のケースに失敗するかもしれませんが、それはまさにフロー制御が存在するそうです。)

(2)  Highly Restricted Bandwidth - At the same time that all that buffer
     space dedicated to low volume connections is being wasted (and it
     can't be deallocated - see below), high volume communication is
     unnecessarily slowed because of inadequate buffer allocation.
     (Because of the inability to deallocate, it is unwise to give a
     large allocation.) Data is sent down the connection to the alloca-
     tion limit, then stops. Several seconds later, after the receiving
     process picks up some of the data, a new allocation is made, and
     another parcel of data is sent. It seems clear that even under only
     moderately favorable conditions, a demand allocation scheme will
     allow several times the bandwidth that this one does.

(2) 非常に、Restricted Bandwidth--同時に、低いボリューム接続に捧げられたそのすべてのバッファ領域が浪費されていて(それを「反-割り当て」ることができません--以下を見てください)、高いボリュームコミュニケーションは不十分なバッファ配分のために不必要に遅くされます。 (deallocateへの無能のために、大きい配分を与えるのは賢明ではありません。) データは、alloca- tion限界との接続の下側に送られて、次に、止まります。 何秒も後に数個です、受信の過程がいくつかのデータを受信した後に新しい配分をします、そして、データの別の小包を送ります。 適度に好ましい条件だけさえのもとで、要求配分体系がこれがする帯域幅について何度かを許容するのは明確に見えます。

(3)  Considerable Overhead During Normal Operation - It can be seen that
     flow control actually need be imposed relatively rarely. However,
     this plan imposes a constant overhead for all connections due to
     the continuing need to send new allocations. Under demand alloca-
     tion, only two RFC's, two CLS's, and perhaps a couple of SPD and
     RSM control messages need be transmitted for a single connection.
     Under this plan, a large fraction of the NCP control messages will
     be ALL allocation requests. There will probably be several times as
     many control messages to be processed by both the sending and
     receiving NCP's, as under a demand allocation scheme.

(3)のかなりのOverhead During Normal Operation--フロー制御が実際に比較的めったに課される必要はないのを見ることができます。 しかしながら、続行による接続が新しい配分を送るのに必要である限り、このプランは一定のオーバーヘッドを課します。 要求alloca- tionの下では、恐らく2、3の2RFCのものだけ、2CLSのもの、SPD、およびRSMコントロールメッセージが単独結合のために送られなければなりません。 このプランの下では、NCPコントロールメッセージの大きい部分は配分要求にすべてなるでしょう。 同じくらい多くの発信していて受信しているNCPのものによって処理されるべきコントロールメッセージがたぶん何度かあるでしょう、要求配分体系のように。

                                                                [Page 3]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation

[3ページ]NWG/RFC59フロー制御--要求に対して固定された配分

(4)  Inflexibility Under Increasing Load Conditions - Not only is this
     plan inflexible as to different kinds of load conditions on a sin-
     gle link, there is potential inflexibility under increasing total
     load. The key problem here is that an allocation can not be arbi-
     trarily revoked. It can be taken back only if it is used. As an
     example of the problem that can be caused, assume the case of a
     connection made at 9 AM. The HOST controlling the receiving socket
     senses light load, and gives the connection a moderately large
     allocation. However, the process attached to the send socket
     intends to use it only to report certain special events, and
     doesn't normally intend to send much at all down this connection.
     Comes 12 noon, and this connection still has 90% of its original
     allocation left. Many other processes are now using the network,
     and the NCP would dearly love to reduce its allocation, if only it
     could. Of course it can't. If the NCP is to keep its part of the
     flow control bargain, it must keep that space empty waiting for the
     data it has agreed to receive.

(4)不屈Under Increasing Load Conditions--罪のgleリンクの上に異種の負荷状態に関して堅いこのプランがあるだけではなく、潜在的不屈が増加する総合負荷の下にあります。 配分が取り消されたarbi- trarilyであるはずがないという主要な問題がここにあります。 それが使用されている場合にだけ、それを取り戻すことができます。 引き起こされる場合がある問題に関する例として、午前9時に作られた接続に関するケースを仮定してください。 受信ソケットを制御するHOSTは軽い荷を感じて、適度に大きい配分を接続に与えます。 ソケットを送ってください。しかしながら、過程が付いた、それを使用するつもりですが、ある特別なイベントを報告して、通常、すべて下にこの接続はたくさん送らないつもりです。 来る、スチール写真があとオリジナルの配分を90%持っている正午、およびこの接続。 他の多くの過程が現在ネットワークを使用します、そして、NCPは配分を抑えるのを心から好むでしょう、そうすることができるなら。 もちろん、それはそうすることができません。 NCPがフロー制御掘り出し物の一部を保つことであるなら、それはそれが持っているデータの空の待ちなら受けるのに同意したそのスペースを保たなければなりません。

     This problem can't really be solved by basing future allocations on
     past use of the connection, because future use may not correlate
     with past use. Also, the introduction of a deallocation command
     would cause synchrony problems.

本当に今後の配分を接続の過去の使用に基礎づけることによって、この問題を解決できません、今後の使用が過去の使用と互いに関連しないかもしれないので。 また、反配分コマンドの導入は同期問題を引き起こすでしょう。

     The real implication of this problem is that an NCP must base its
     allocation to a link on conditions of heavy load, even if there is
     currently only light network traffic.

この問題の本当の含意はNCPがリンクへの配分を重量物の状態に基礎づけなければならないということです、軽いネットワークトラフィックしか現在なくても。

(5)  Wrong Type of Optimization - This type of flow control optimizes
     for the case where every connection starts sending large amounts of
     data almost simultaneously, exactly the case that just about never
     occurs. As a result the NCP operates almost as slowly under light
     load as it does under heavy load.

Optimizationの(5)の間違ったType--このタイプのフロー制御はすべての接続がほとんど同時に多量のデータを送り始めるケースのために最適化されます、まさにほとんど決して現れないケース。 その結果、NCPは重量物の下でそうするのとほとんど同じくらい軽い荷の下でゆっくり作動します。

(6)  Loss of Allocation Synchrony Due to Message Length Indeterminacy -
     If this plan is to be workable, the allocation must apply to the
     entire message, including header, padding, text, and marking, oth-
     erwise, a plethora of small messages could overflow the buffers,
     even though the text allocation had not been exceeded. Thomas Bar-
     kalow of Lincoln Laboratories has pointed out that this also fails,
     because the sending HOST can not know how many bits of padding that
     the receiving HOST's system will add to the message. After several
     messages, the allocation counters of the sending and receiving
     HOSTs will get seriously out of synchrony. This will have serious
     consequences.

Message Length IndeterminacyへのAllocation Synchrony Dueの(6)の損失--配分はこのプランが実行可能であることであるなら、全体のメッセージに適用されなければなりません、ヘッダー、詰め物、テキスト、およびマーク、oth- erwiseを含んでいて小さいメッセージの過剰をバッファからはみ出させるかもしれません、テキスト配分は超えられていませんでしたが。 リンカーン研究所のトーマスBar- kalowは、また、これが失敗すると指摘しました、発信しているHOSTが、受信HOSTのシステムがそれを水増しするいくつのビットをメッセージに追加するかを知ることができないので。 いくつかのメッセージの後に、送受信HOSTsの配分カウンタは重大に同期を出るでしょう。 これは重大な結果を生むでしょう。

     It has been argued that the allocation need apply only to the text
     portion, because the header, padding, and marking are deleted soon
     after receipt of the message. This imposes an implementation res-
     triction on the NCP, that it must delete all but the text part of
     the message just as soon as it gets it from the IMP. In both the
     TX2 and Multics implementations it is planned to keep most of the
     message in the buffers until it is read by the receiving process.

配分がテキスト部分だけに適用されなければならないと主張されました、ヘッダー、詰め物、およびマークがメッセージの領収書のすぐ後に削除されるので。 これは実現res- trictionをNCPに課して、それがそれのすぐ次第メッセージのテキスト部分以外のすべてを削除しなければならないのがIMPからそれを得ます。 TX2とMultics実現の両方では、それが受信工程で読まれるまで、バッファのメッセージの大部分を保つのは計画されています。

                                                                [Page 4]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation

[4ページ]NWG/RFC59フロー制御--要求に対して固定された配分

The advantages of demand allocation using the "cease on link" flow con-
trol method are pretty much the converse of the disadvantages of fixed
allocation. There is much greater resource utilization, flexibility,
bandwidth, and less overhead, primarily because flow control restric-
tions are imposed only when needed, not on normal flow.

「リンクの上にやんでください」流れまやかしtrol方法を使用する要求配分の利点はほとんど固定配分の損失の逆です。 はるかに大きいリソース利用、柔軟性、帯域幅、および、より少ないオーバーヘッドがあります、主として必要である場合にだけフロー制御restric- tionsが標準を流れるのではなく、課されるので。

One would expect very good performance under light and moderate load,
and I won't belabor this point.

人は非常に良い軽くて適度の負荷の下での性能を予想するでしょう、そして、私はこのポイントを長々とするつもりではありません。

The real test is what happens under heavy load conditions. The chief
disadvantage of this demand allocation scheme is that the "cease on
link" IMP message can not quench flow over a link soon enough to prevent
an NCP's buffers from filling completely under extreme overload.

本当のテストは重量物条件のもとで起こることです。 この要求配分体系の主要な不都合は「リンクの上にやんでください」IMPメッセージがNCPのバッファが極端なオーバーロードの完全下でいっぱいになるのを防ぐことができるくらいすぐリンクの上に流れを冷却できないということです。

This is true. However, it is not a critical disadvantage for three rea-
sons:

これは本当です。 しかしながら、それは3人のrea息子のためのあらゆる重大でない不都合です:

(i)  An overload that would fill an NCP's buffers is expected to occur
     at infrequent intervals.

(i) NCPのバッファをいっぱいにするオーバーロードがときたま起こると予想されます。

(ii) When it does occur, the situation is generally self-correcting and
     lasts for only a few seconds. Flow over individual connections may
     be temporarily delayed, but this is unlikely to be serious.

(ii) 起こると、状況は、一般に、自動修正であり、ほんの数秒間、続きます。 個々の接続の上の流れは一時遅れるかもしれませんが、これは重大でありそうにはありません。

(iv) In a few of these situations radical action by the NCP may be
     needed to unblock the logjam. However, this will have serious
     consequences only for those connections directly responsible for
     the tie-up.

(iv) これらの状況のいくつかでは、NCPによる急進的な動きが、行き詰まりを「非-妨げ」るのに必要であるかもしれません。 しかしながら、これは直接タイアップに責任があるそれらの接続のためだけに重大な結果を生むでしょう。

Let's examine the operation of an NCP employing demand allocation and
using "cease on link" for flow control. The following discussion is
based on a flow control algorithm in which the maximum permissible queue
length (MQL) is calculated to be a certain fraction (say 10%) of the
total empty buffer space currently available. The NCP will block a con-
nection if the input queue length exceeds the MQL. This can happen
either due to new input to the queue or a new calculation of the MQL at
a lower value. Under light load conditions, the MQL is reasonably high,
and relatively long input queues can be maintained without the connec-
tion being blocked.

フロー制御に要求配分を使って、「リンクの上にやんでください」を使用することでNCPの操作を調べましょう。 以下の議論は最大の許されている待ち行列の長さ(MQL)が現在利用可能な総人影のないバッファ領域のある部分(10%を言う)になるように計算されるフロー制御アルゴリズムに基づいています。 入力キューの長さがMQLを超えていると、NCPはまやかしnectionを妨げるでしょう。 待ち行列への新しい入力かMQLの新しい計算のため、これは下側の値で起こることができます。 軽荷状態の下では、MQLはかなり高いです、そして、妨げられるconnec- tionなしで比較的長い入力キューは維持できます。

As load increases, the remaining available buffer space goes down, and
the MQL is constantly recalculated at a lower value. This hardly affects
console communications with short queues, but more queues for high
volume connections are going above the MQL. As they do, "cease on link"
messages are being sent out for these connections.

負荷が増加するのに従って、残っている利用可能なバッファ領域は落ちます、そして、MQLは下側の値で絶えず再計算されます。 これは短い待ち行列とのコンソールコミュニケーションにほとんど影響しませんが、高いボリューム接続における、より多くの待ち行列がMQLの上を行っています。 出すように、これらの接続のために「リンクの上にやんでください」メッセージを出しています。

If the flow control algorithm constants are set properly, there is a
high probability that flow over the quenched links will indeed cease
before the scarcity of buffer space reaches critical proportions.

フロー制御アルゴリズム定数が適切に設定されるなら、バッファ領域への不足が重要な割合に達する前に本当に、冷却リンクの上の流れがやむという高い確率があります。

                                                                [Page 5]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation

[5ページ]NWG/RFC59フロー制御--要求に対して固定された配分

However, there is a finite probability that the data still coming in
over the quenched links will fill the buffers. This is most likely under
already heavy load conditions when previously inactive links start
transmitting at at once at high volume.

しかしながら、冷却リンクの上にまだ入っているデータがバッファをいっぱいにするという有限確率があります。 以前に不活発なリンクがすぐに高いボリュームで伝わり始めるとき、これは既にたぶん重量物状態であります。

Once the NCP's buffers are filled it must stop taking all messages from
its IMP. This is serious because now the NCP can no longer receive con-
trol messages sent by other NCP's, and because the IMP may soon be
forced to stop accepting messages from the NCP. (Fortunately, the NCP
already has sent out "cease on link" messages for virtually all of the
high volume connections before it stopped taking data from the IMP.)

NCPのバッファがいったんいっぱいにされると、それは、IMPからすべての伝言を受け取るのを止めなければなりません。 今、NCPがもうNCPの他のものによって送られたまやかしtrolメッセージを受け取ることができないで、IMPが、すぐNCPからメッセージを受け入れるのをやむを得ず止めるかもしれないので、これは重大です。 (幸い、IMPからデータを取るのを止める前にNCPは高いボリューム接続のほとんどすべてのために既に「リンクの上にやんでください」メッセージを出しました。)

In most cases input from the IMP remains stopped for only a few seconds.
After a very short interval, some process with data queued for input is
likely to come in and pick it up from the NCP's buffers. The NCP immedi-
ately starts taking data from the IMP again. The IMP output may stop and
start several times as the buffers are opened and then refilled. How-
ever, more processes are now reading data queued for their receive sock-
ets, and the NCP's buffers are emptying at an accelerating rate. Soon
the reading processes make enough buffer space to take in all the mes-
sages still pending for blocked links, and normal IMP communications
resume.

多くの場合、ほんの数秒とどまって待たれたIMPの残りから、入力します。 非常に短い間隔の後に、データが入力のために列に並ばせられている何らかの過程が、NCPのバッファから入って、それを拾いそうです。 NCP immedi- atelyは再びIMPからデータを取り始めます。 バッファが開かれて、次に、詰め替えられるとき、IMP出力は何度か休みながら進むかもしれません。 どのように、-、現在今までにより多くの過程がデータが列を作った読書であるか、それら、ソックスetsを受けてください。そうすれば、NCPのバッファは加速レートで空になっています。 すぐ、読書の過程は妨げられたリンクには、まだ未定のすべてのmes賢人を中に入れることができるくらいのバッファ領域を作ります、そして、正常なIMPコミュニケーションは再開します。

As the reading processes catch up with the sudden burst of data, the MQL
becomes lower, and more and more links become unblocked. The crisis can
not immediately reappear, because each link generally becomes unblocked
at a different time. If new data suddenly shoots through, the link
immediately goes blocked again. The MQL goes up, with the result that
other links do not become unblocked.

読書の過程がデータの突然の炸裂に追いつくのに従って、MQLは低くなります、そして、ますます多くのリンクが「非-妨げ」られるようになります。 各リンクがいろいろな時間に一般に「非-妨げ」られるようになるので、危機はすぐに、再現できません。 新しいデータが突然去るなら、リンクはすぐに、再び妨げられるのに行きます。 MQLは上がります、その結果、他のリンクが「非-妨げ」られるようになりません。

The worst case appears at a HOST with relatively small total buffer
space (less than 8000 bits per active receive link) under heavy load
conditions. Suppose that high volume transmission suddenly comes in over
more than a half-dozen links simultaneously, and the processes attached
to the receive links take little or none of the input. The input buffers
may completely fill, and the NCP must stop all input from the IMP. If
some processes are reading links, buffer space soon opens up. Shortly it
is filled again, this time with messages over links which are not being
read. At this point the NCP is blocked, and could remain so indefin-
itely. The NCP waits for a time, hoping that some process starts reading
data. If this happens, the crisis may soon ease.

重量物状態の下に比較的小さい総バッファ領域(1アクティブであるのあたり8000ビット未満はリンクを受ける)がある状態で、最悪の場合はHOSTに現れます。 受信してください。その高いボリューム送信が同時に、半ダース個のリンクの上に突然入って、過程が付いたと仮定してください、リンクは少しも取りません。 入力バッファは完全にいっぱいになるかもしれません、そして、NCPはIMPからのすべての入力を止めなければなりません。 いくつかの過程がリンクを読むことであるなら、バッファ領域はすぐ、開きます。 まもなく、それは再び、今回、読まれていないリンクの上のメッセージでいっぱいにされます。 ここに、NCPは、妨げられて、そのように、indefin- itelyのままで残ることができました。 何らかの過程がデータを読み始めることを望んでいて、NCPは時間、待っています。 これが起こるなら、危機はすぐ、軽くなるかもしれません。

If buffer space does not open up of its own accord, after a limited
interval the NCP must take drastic action to get back into communication
with its IMP. It selects the worst offending link on the basis of amount
of data queued and interval since data was last read by this process,
and totally deletes the input queue for this link. This should break the
logjam and start communications again.

バッファ領域が独りでに開かないなら、限られた間隔の後に、NCPは、IMPとのコミュニケーションに戻るために思い切った行動を取らなければなりません。 データが最後にこの工程で読み込まれて、このリンクに入力キューを完全に削除するので、それは列に並ばせられたデータ量と間隔に基づいて最も悪い怒っているリンクを選択します。 これは、行き詰まりを壊して、再びコミュニケーションを始めるべきです。

This type of situation is expected to occur most often when a process
deliberately tries to block an NCP in this manner. The solution has
serious consequences only for "bad" processes: those that flood the net-
work with high volume transmission over multiple links which are not
being read by the receiving processes.

たいてい過程が故意にこの様にNCPを妨げようとするとき、このタイプの状況が起こると予想されます。 解決策は「悪い」過程のためだけに重大な結果を生みます: 受信工程で読まれていない複数のリンクの上に高いボリューム送信がある状態で、ネットをあふれさせるものが働いています。

                                                                [Page 6]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation

[6ページ]NWG/RFC59フロー制御--要求に対して固定された配分

Because of the infrequency and tolerability of this situation, the
overall performance of the network using this scheme of demand alloca-
tion should still be much superior to that of a network employing a
fixed allocation scheme.

この状況のまれなことと持久力のために、要求alloca- tionのこの計画を使用するネットワークの総合的な性能はまだ固定配分体系を使うネットワークのものへの多くの上司であるべきです。

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by William Lewis 6/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ウィリアム・ルイス6/97によるオンラインRFCアーカイブへの]

                                                                [Page 7]

[7ページ]