RFC47 日本語訳
0047 BBN's Comments on NWG/RFC #33. J. Postel, S. Crocker. April 1970. (Format: TXT=5343 bytes) (Updates RFC0033) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Request for Comments #47 J. Postel S. Crocker UCLA 20 April 70
コメント#47J.ポステルS.医者UCLA1970年4月20日を求めるネットワークワーキンググループ要求
BBN's Comments on NWG/RFC #33
NWG/RFC#33のBBNのコメント
BBN has given us the attached comments on NWG/RFC 33, but wouldn't publish them being relectant to embarrass us. Embarrassment notwith- standing, we found the comments particularly useful and decided to share them with our friends. Bill Crowther is the author.
BBNは、NWG/RFC33の付属コメントを私たちに与えましたが、私たちを当惑させるrelectantであるのでそれらを発行しないでしょう。 困惑notwithが立って、私たちは、コメントが特に役に立つのがわかって、私たちの友人とそれらを共有すると決めました。 ビル・クラウザーは作者です。
[Page 1] RFC 47 BBN's Comments on NWG/RFC #33 April 1970
[1ページ] NWG/RFC#4月33日1970年のRFC47BBNのコメント
I found two substantial errors in the Host Protocol Paper, which was otherwise an excellent paper. Both concern a misunderstanding of the nature of the IMP as a communications device, and in particular the nature of buffering an IMP must do. The authors consider the network as a device into which one pushes a message which travels around some, waits in buffers for substantial lengths of times, and then emerges at the destination. In fact a better model would be that the message pops out again an instant after it is inserted. While it is true there is a delay, it is imposed by phone line hardware for the most part. The IMP buffering is minimal, and devoted to error control and momentary traffic surges.
私はHostプロトコルPaperで2つのかなりの誤りを見つけました。(そうでなければ、Paperは優れた論文でした)。 両方がコミュニケーション装置としてのIMPの自然の誤解、および特にIMPがしなければならないバッファリングの自然に関係があります。 装置がいくつか周りを移動するメッセージをどれに押すか、そして、かなりの長さの倍がバッファで待っていて、次に、目的地に現れるとき、作者はネットワークを考えます。 事実上、より良いモデルはそれが挿入された後にメッセージが再び瞬間から飛び出すということでしょう。 遅れがあるのが、本当である間、それは電話架線金具によってだいたい課されます。 IMPバッファリングは最小量の、そして、誤り制御に熱心で瞬間の交通大波です。
Since we cannot force a Host to take a message, we have built an elab- orate RFNM mechanism to suspend new input until he does. This mech- anism is an imperfect attempt to solve a very hard communications problem. The desire is to regulate traffic in such a way that as the Host takes its message from the IMP the next message is arriving on the phone line, and no buffering occurs at all.
Hostにメッセージで強制的に取らせることができないので、私たちは建てました。elabは、新しい入力を中断させるためにRFNMメカニズムを彼が演説するまで演説させます。 このmech- anismは非常に困難なコミュニケーション問題を解決する不完全な試みです。 願望はHostがIMPから伝言を受け取るのに従って次のメッセージが電話回線の上で到着していて、バッファリングでないのが全く起こるような方法で交通整理することです。
In fact we cannot achieve this, and therefore have included buffering to handle traffic surges. These buffers are useless for their intended purpose unless they are empty. Only empty buffers are available to soak up a traffic surge.
事実上、私たちは、これを達成できないで、したがって、交通大波を扱うためにバッファリングするのを入れました。 それらが空でない場合、これらのバッファはそれらの本来の目的のために役に立ちません。 空のバッファだけが、交通波動を吸収するために利用可能です。
The two specific errors occur on pages 5 and 23. On page 5 the authors say "Implicit in this purpose is the assumption that a user does not use multiple links to achieve a wide band." In fact one of the primary purposes of links is to achieve a wider band.
2つの特定の誤りが5と23ページに発生します。 5ページでは、作者は「この目的で暗黙であることは、ユーザが広いバンドを達成するのに複数のリンクを使用しないという仮定です」を言います。 事実上、リンクの第一の目的の1つはワイダー・バンドを達成することです。
[Page 2] RFC 47 BBN's Comments on NWG/RFC #33 April 1970
[2ページ] NWG/RFC#4月33日1970年のRFC47BBNのコメント
We wish to allow as much band width as possible. Our troubles occur not with wide band but with an imbalance of input and output. The authors have rightly noticed that multiple links subvert the RFNM mechanism, making our job harder, but have wrongly labeled the nature of the problem.
できるだけ多くのバンド幅を許したいと思います。 私たちの問題は広いバンドで起こるのではなく、入出力の不均衡で起こります。 作者は、複数のリンクが私たちの仕事をより困難にして、RFNMメカニズムを打倒しますが、誤って問題の性格をラベルしたのに正しく気付きました。
Again on page 5 "An even more basic assumption, of course, is that the network's load comes from some users transmitting sequences of messages rather than many users transmitting single messages coincidentally." We are in great shape against single message users when their messages are randomly related. The statistics are all in our favor and we have special procedures for the (rare) coincedences. Our problems come with the non-random coincidences, and we have taken special precautions against users transmitting bursts (sequences) of messages. We assume all kinds of users, and protect ourselves accordingly.
再び「さらに基本的な仮定はもちろんネットワークの負荷がただ一つのメッセージを一致して送る多くのユーザよりむしろメッセージの系列を伝える何人かのユーザから来るということです」という5ページで。 彼らのメッセージが手当たりしだいに話されるとき、独身のメッセージユーザに対して素晴らしい形には私たちがいます。 統計は当方を受益者としてすべてです、そして、私たちには、(まれ)のcoincedencesに、特別な手順があります。 私たちの問題は非偶然の計測と共に来ます、そして、私たちはメッセージの炸裂(系列)を伝えるユーザに対して特別な注意を払いました。 私たちは、すべての種類のユーザを思って、それに従って、我が身をかばいます。
On pages 23 and 24 there are 4 critical sentences which imply that the system design could have been improved by allowing the Host to specify which of several waiting inputs he might wish to accept. We grant that the Host needs to buffer these messages for its users, but violently disagree that the IMP has the capability to do this buffering.
23と24ページに、Hostが、彼がいくつかの待ち入力のどれを受け入れたがっているかもしれないかを指定するのを許容することによってシステム設計が改良されたかもしれないのを含意する4つの批判的な文があります。 私たちは、Hostが、ユーザへのこれらのメッセージをバッファリングする必要であるのを与えますが、IMPにはこのバッファリングをする能力があるのは乱暴に意見を異にしてください。
If we are operating in ideal mode, we would have at most one message for the Host at any time. If we have more than one we urgently need the Host to accept these messages, because our ability to handle traffic surges is now below standard. At present we allow three full
理想的なモードで働いているなら、私たちはいつでも、Hostへの1つのメッセージに最も攻撃するでしょう。 1つ以上があるなら、私たちは、緊急にHostがこれらのメッセージを受け入れる必要があります、交通大波を扱う私たちの能力が現在、規格の下にあるので。 現在のところ、私たちは3をいっぱいに許します。
[Page 3] RFC 47 BBN's Comments on NWG/RFC #33 April 1970
[3ページ] NWG/RFC#4月33日1970年のRFC47BBNのコメント
length messages in an IMP for its Host before we start backing traffic up in the network. "Three" is not enough to help the Host in addition to keeping a reserve for the traffic surges.
以前私たちがネットワークで交通を支援し始めるというHostのためのIMPの長さのメッセージ。 「3」は交通のための蓄えを保つことに加えてHostを助けることができるくらい波打つということではありません。
But if buffering is needed why not get more memory and do it in the IMP? Because buffering is a Host function, is different in each time share system, is hard to control over a busy serial channel, might not be needed at all in some places, and is better done where the extra memory can be efficiently shared by the Host operating system.
しかし、バッファリングが必要であるなら、なぜより多くのメモリを得て、IMPでそれをしませんか? Host機能であり、それぞれの時間シェアシステムにおいて異なって、忙しい連続のチャンネルの上に制御しにくくて、所々全く必要でないかもしれなく、Hostオペレーティングシステムで効率的に余分なメモリーを共有できるところでバッファリングするほうがよいので。
I repeat: the IMP's buffers must be empty or they are not serving their communication purpose.
私は繰り返します: IMPのバッファが空であるに違いありませんか、またはそれらは自己のコミュニケーション目的に役立っていません。
The offending sentences are:
怒っている文は以下の通りです。
Paragraph 2 sentence 3 " 3 all " 4 sentences 1 and 2 (80ms is hardware screw adjustable) " 4 sentence last
パラグラフ2文3、「3、」 「4文の最終」という4つの文1と2(80msは調整可能なハードウェアねじです)
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Jeff & Christy McClellan 2/98]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ジェフによるオンラインRFCアーカイブとクリスティマクレラン2/98への]
[Page 4]
[4ページ]
一覧
スポンサーリンク