RFC19 日本語訳

0019 Two protocol suggestions to reduce congestion at swap boundnodes. J.E. Kreznar. October 1969. (Format: TXT=3392 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                 John E. Kreznar
Request For Comments:  19                             SDC
                                                      7 October 1969

Kreznarがコメントのために要求するワーキンググループジョンE.をネットワークでつないでください: 19 SDC1969年10月7日

Two Protocol Suggestions to Reduce Congestion at Swap-Bound Nodes

2は、スワッピング行きのノードで混雑を抑えるために提案について議定書の中で述べます。

There is a wide variance in swap rates between core and auxiliary store
among the HOST systems to be nodes in the ARPA IMP network.  The slower
of these, of which our 360/50 system with 2303 drump swap store is an
example, might improve the utility of the network not only for
themselves but for all nodes if the two protocol suggestions of this
note were to be adopted.

ARPA IMPネットワークにおけるノードになるように、HOSTシステムの中に広い変化がコアと補助記憶装置の間のスワップレートにあります。 これらの、より遅さ(2303年のdrumpスワッピング店がある私たちの360/50システムは例である)は自分たちのために改良するだけではなく、この注意の2つのプロトコル提案が採用されることであるならすべてのノードのためにもネットワークに関するユーティリティを改良します。

1. HOST control of ordering of IMP-to-HOST traffic.  IMP-HOST protocol
   now calls for delivery of messages from IMP to HOST in the order in
   which the IMP received them.  This may lead to wasted swapping if,
   for example, the IMP has messages for its HOST's timeshare users A
   and B, in that order, at a time when user B is in HOST core.  B
   would have to be swapped out, A in, and the first message accepted--
   only to discover that now A must be swapped out and B back in again.
   If the HOST could a) read the IMP's queue of waiting messages and b)
   accept them in the order it found most effective, then a new
   mechanism for improvement of network efficiency would be at hand.
   Clearly this change would have an impact on BBN's IMP software.

1. IMPからHOSTへの交通を注文するHOSTコントロール。 IMP-HOSTは現在、IMPがそれらを受けたオーダーでメッセージのIMPからHOSTまでの配送のための呼び出しについて議定書の中で述べます。 例えば、IMPにHOSTのタイムシェアユーザAとBへのメッセージがあるなら、これは無駄なスワッピングに通じるかもしれません、そのオーダーで、ユーザBがHOSTコアにいる時代に。 Bは中にAがあって、最初のメッセージを受け入れている外で交換されなければならないでしょう--再び外で現在Aを交換しなければならないと発見するために唯一とB後部。 HOSTがそれが最も効果的であることがわかったオーダーでそれらを受け入れることができるなら、a)が、IMPのメッセージとb)を待つ待ち行列を読んだネットワーク効率の改良のための新しいメカニズムは近いでしょうに。 明確に、この変化はBBNのIMPソフトウェアに影響を与えるでしょう。

2. Core-to-core transfers between HOSTS.  At another level, perhaps not
   involving HOST-IMP protocol or IMP software changes, is a HOST-HOST
   protocol wherein cooperating HOSTS agree to lock appropriate
   programs in core for the duration of a multi-message file transfer
   on an auxiliary connection.  This could greatly reduce the time to
   transfer such a file to and from a swap-bound HOST.  Unfortunately,
   the numbers mitigate possible advantages of this approach to some
   extent:  if we assume a 50 kilobit/sec line and support further that
   it is dedicated at 100% efficiency to this transfer (which may
   require slightly different handling of RFNMs in this case) this
   comes out to just over 6 8-kilobit messages per second.  It may be
   impolitic in a timeshare environment to lock a single program in
   core for more than about 2 seconds.  If this is the case, then the
   method would be applicable only for the rather limited range of file
   sizes of 2-16 messages.  Nevertheless, the time to move a large file
   could be so greatly enhanced by this approach that I think it
   deserves consideration.

2. コアからコアはHOSTSの間で移されます。 別のレベルでは、恐らくHOST-IMPプロトコルかIMPソフトウェア変化にかかわらないで、補助の接続のときに協力HOSTSがマルチメッセージファイルの持続時間のために適切なプログラムをコアに閉じ込めるのに同意するHOST-HOSTプロトコルは転送ですか? これはHOSTと、そして、スワッピング行きのHOSTからそのようなファイルを移す時間を大いに短縮するかもしれません。残念ながら、数はこのアプローチの可能な利点をある程度緩和します: 私たちが、それが線とサポートがそれを促進する50キロビット/秒のときに100%の効率でこの転送(この場合RFNMsのわずかに異なった取り扱いを必要とするかもしれない)に捧げられると思うなら、これは1秒あたりちょうど6以上の8キロビットのメッセージまで出て来ます。 およそ2秒以上間、単一のプログラムをコアに閉じ込めるのはタイムシェア環境で不得策であるかもしれません。 これがそうであるなら、かなり限られた範囲の2-16 メッセージのファイルサイズだけに、方法は適切でしょう。 大きいファイルを動かす時間はこのアプローチであまりに大いに充実できるでしょう、それにもかかわらず、したがって、私はそれが考慮に値すると思います。

1. Abhi Bhushan, Proj. MAC               10.  Jerry Cole,  SDC
2. Steve Crocker, UCLA                   11.  John Kreznar, "
3. Ron Stoughton, UCSB                   12.  Dick Linde,   "
4. Elmer Shapiro, SRI                    13.  Bob Long,     "

1. Abhi Bhushan、Proj。 Mac10。 ジェリー・コール、SDC2。 スティーブ・クロッカー、UCLA11。 ジョンKreznar、「3。」 ロンストートン、UCSB12。 ディック・リンデ、「4。」 エルマー・シャピロ、様13。 「長い間、たたいてください」

                                                                [Page 1]

5. Steve Carr, Utah                      14.  Reg Martin,   "
6. John Haefner, RAND                    15.  Hal Sackman,  "
7. Paul Rovner, LL                       16.  C. Weissman,  "
8. Bob Khan, BB & N                      17.  Marty Bleier, "
9. Larry Roberts, ARPA

[1ページ] 5。 14歳のスティーブ・ユタカー。 レッジ・マーチン、「6。」 ジョンHaefner、底ならし革15。 ハル・ザックマン、「7。」 ポールRovner、LL16。 C。 ワイズマン、「8。」 ボブカーン、掲示板、およびN17。 マーティBleier、「9。」 ラリー・ロバーツ、アルパ

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Alex Portnoy 1/97 ]

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

                                                                [Page 2]

[2ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ペンギンの平均寿命

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る