RFC176 日本語訳
0176 Comments on "Byte size for connections". A.K. Bhushan, R.Kanodia, R.M. Metcalfe, J. Postel. June 1971. (Format: TXT=7269 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Bhushan, MIT Request for Comments #176 R. Kanodia, MIT NIC #7100 R. Metcalfe, MIT Categories: C and D J. Postel, UCLA 14 June 1971
ワーキンググループA.Bhushan、コメント#176R.Kanodiaを求めるMITの要求、MIT NIC#7100R.メトカルフェ、MITカテゴリをネットワークでつないでください: CとD J.ポステル、UCLA1971年6月14日
Comments on Byte Size for Connections -------------------------------------
コネクションズのためのバイトサイズのコメント-------------------------------------
There are at least the following three views on the use of byte size for network connections*:
少なくとも3がバイトサイズの使用のときに見る以下がネットワーク接続*のためにあります:
1) Byte size should not be used at all.
1) バイトサイズを全く使用するべきではありません。
2) Byte size is solely for the convenience of NCP's.
2) バイトサイズが唯一NCPの都合のためにあります。
3) Byte size choice is a user-level prerogative.
3) バイトサイズ選択はユーザレベル特権です。
According to the first view, network connections are bit streams, and messages should contain bit counts (i.e., a byte size of 1). This view existed before the "Glitch Cleaning" of RFC 107, and was discarded in favour of byte stream because of stated reasons of efficiency in storage management and message concatenation.
最初の視点によると、ネットワーク接続はビットストリームです、そして、メッセージは噛み付いているカウント(すなわち、1のバイトサイズ)を含むべきです。 この視点は、RFC107の「不調掃除」の前に存在して、保管管理における効率とメッセージ連結の述べられた理由によるバイト・ストリームを支持して捨てられました。
The second view represents a special interpretation of RFC 107. According to this interpretation, byte size is entirely a 2nd level (i.e., NCP) issue. There is no require- ment that 3rd level user processes be able to specify byte size. This view is indicated in RFC 151 by Shoshani.
2番目の視点はRFC107の特別な解釈を表します。 この解釈によると、バイトサイズは完全に2番目の平らな(すなわち、NCP)問題です。 いいえがあります。バイトサイズを指定できる状態で3番目のレベルユーザ・プロセスがあるmentを必要としてください。 この視点はRFC151でShoshaniによって示されます。
---------------------- * Byte size for connection is the byte size selected by sending NCP, as explained in RFC 107 (Output of Host-Host Protocol Glitch Cleaning Committee).
---------------------- * 接続のためのバイトサイズはサイズがNCPを送ることによって選択したバイトです、RFC107(Host-ホストプロトコルGlitch Cleaning Committeeの出力)で説明されるように。
[Page 1] RFC #176 -2- NIC #7100
[1ページ] RFC#176 -2NIC#7100
According to the third view user processes are always allowed to choose byte size for connection, either explicitly (specify a specific byte size parameter) or implicitly (byte size depends on I/O mode). An NCP is allowed to use a default byte size, if the user does not specify it.
3番目の視点によると、ユーザ・プロセスはいつも明らか(特定のバイトサイズ・パラメータを指定する)にそれとなく接続のためのバイトサイズを選ぶことができます(バイトサイズを入出力モードに依存します)。 ユーザがそれを指定しないなら、NCPはデフォルトバイトサイズを使用できます。
The Correct View ________________
正当な見解________________
The third view should be considered the correct interpre- tation of RFC 107. In fact, RFC 107 states on page 2, "the choice of the byte size for a connection is a 3rd level protocol issue." To be consistent with TELNET, ICP, and other 3rd level protocols which require that a specific byte size be used for connection, it is imperative that corresponding 3rd level processes be able to specify (and_impose) a particular byte size to the NCP. NCP implementors should take note of it.
3番目の視点はRFC107の正しいinterpre- tationであると考えられるべきです。 事実上、「接続のためのバイトサイズの選択は3番目の平らなプロトコル問題です。」と、RFC107は2ページに述べます。 TELNET、ICP、および特定のバイトサイズが接続に使用されるのを必要とする他の3番目の平らなプロトコルと一致しているように、3番目の対応する平らにすることの過程が特定のバイトサイズをNCPに指定できるのは(_でしゃばってください)、必須です。 NCP作成者はそれに注目するべきです。
On Specifying Fixed Byte Sizes in 3rd Level Protocols -----------------------------------------------------
第3平らなプロトコルのバイトサイズが固定された指定に関して-----------------------------------------------------
Holding the view that byte size choice is a 3rd level issue, we are still faced with the following two questions. First, is it appropriate for 3rd level protocols to legislate a specific byte size for all connections using that protocol? Second, if it is appropriate to specify byte size, then what should this choice be?
バイトサイズ選択が3番目の平らな問題であるという意見を保持して、私たちはまだ以下の2つの質問に直面しています。 まず最初に、3番目の平らなプロトコルがすべての接続のためにそのプロトコルを使用することで特定のバイトサイズを制定するのは、適切ですか? 2番目に、バイトサイズを指定するのが適切であるなら、この選択は何であるべきですか?
[Page 2] RFC #176 -3- NIC #7100
[2ページ] RFC#176 -3NIC#7100
There are two arguments in favour of using specific byte size in 3rd level protocols. First is that a potential mismatch problem exists because RFC 107 does not require that NCPs be capable of handling all byte sizes 1 through 255. Using a fixed byte size of 8-bits or 8-bit multiples resolves the problem as this is acceptable to all hosts (including terminal IMPs).
3番目の平らなプロトコルに特定のバイトサイズを使用することを支持して2つの議論があります。 1番目はRFC107が、NCPがすべてのバイトが1〜255に大きさで分ける取り扱いができるのを必要としないので潜在的ミスマッチ問題が存在しているということです。 8ビットか8ビットの倍数の固定バイトサイズを使用すると、すべてのホストにとって、これが許容できるので(端末のIMPsを含んでいて)、問題は解決されます。
The second argument is one of efficiency. If it is agreed before hand that only a specific byte size would be used, it is possible to make programs more efficient (i.e., reduce program space, and possibly run time). The efficiency argument assumes that the byte size for connection represents the natural byte structure of data being transferred over the connection.
議論が1である効率の秒。 以前特定のバイトサイズだけが使用されるのに手で同意されるなら、プログラムをより効率的にするのは可能です(すなわち、プログラムスペース、およびことによるとランタイムを短縮してください)。 効率議論は、接続のためのバイトサイズが接続の上に移される自然なバイトデータ構造を表すと仮定します。
For TELNET and ICP, the byte size choice is straight forward as data is naturally in 8-bit multiples (8-bit ASCII characters in TELNET, and 32-bit socket numbers in ICP). But for data transfer protocols, the byte size choice is more complex, as data may be structured in a variety of byte sizes. Specifying a byte size for a data transfer connection reduces efficiency in instances where connection byte size does not correspond to data byte size. Further, filler fields will be required for data blocks which are not a multiple of the fixed byte size. This imposes an additional overhead.
データが自然にまっすぐであるようにTELNETとICP、バイトに、サイズ選択は前方で8ビットの倍数(TELNETの8ビットのASCII文字、およびICPの32ビットのソケット番号)でまっすぐです。 しかし、データ転送プロトコルには、バイトサイズ選択は、より複雑です、データがさまざまなバイトサイズで構造化されるとき。 バイトサイズをデータ転送コネクションに指定すると、接続バイトサイズがデータ・バイトサイズと食い違っている例における効率は減少します。 さらに、フィラー分野が固定バイトサイズの倍数でない何データ・ブロックも必要でしょう。 これは追加オーバーヘッドを課します。
[Page 3] RFC #176 -4- NIC #7100
[3ページ] RFC#176 -4NIC#7100
Even if all hosts were to accept arbitrary byte sizes, and the 3rd level protocol does not legislate a specific byte size, the inefficiency problem will not be solved entirely. Under current specifications "the byte size is fixed for the life of a connection".* This means that byte size cannot be varied during the life of a connection even if structure of data varies. The problem of inefficiency is solved only for instances in which data has a constant byte structure.
すべてのホストが、任意のバイトサイズ、および第3が平らであると受け入れるつもりであってもさえ、プロトコルは特定のバイトサイズを制定しないで、また非能率問題は完全に解決されないでしょう。 現在の仕様では、「バイトサイズは接続の人生に固定されています」。*これは、データ構造が異なっても接続の人生の間バイトサイズを変えることができないことを意味します。 非能率の問題はデータが一定のバイト構造を持っている例のためだけに解決されています。
Given the current state of the network, it appears that specifying fixed byte size in 3rd level protocols is a good idea. This eliminates the potential byte size mismatch problem, and improves efficiency at least for TELNET and ICP. In data transfer, the efficiency issue is more complex, as discussed earlier. It is not clear that overall efficiency would be degraded if a fixed byte size was required.
ネットワークの現状を考えて、3番目の平らなプロトコルのサイズが名案であるようにその指定の固定バイトに見えます。 これは、潜在的バイトサイズミスマッチ問題を解決して、少なくともTELNETとICPのために能率を増進します。 データ転送で、効率問題は、より早く議論するように、より複雑です。 サイズが固定バイト必要であるなら全体的効率が下げられるのは、明確ではありません。
On Reopening the Byte Size Issue --------------------------------
バイトサイズ問題を再開させることに関して--------------------------------
The above discussion exposes certain weaknesses in the efficiency arguments for having byte streams on network connec- tions. In moving from bit stream to byte stream, we may have lost generality, and it is not clear how much overall efficiency is gained. Sometimes, the gain in NCP efficiency may be at the expense of user process efficiencies.
上の議論はネットワークconnec- tionsにバイト・ストリームを持つための効率議論における、ある弱点を露出します。 ビットストリームからバイト・ストリームまで動く際に、私たちは一般性を失ったかもしれません、そして、どのくらいの全体的効率を獲得するかは明確ではありません。 時々、NCP効率における利得はユーザ・プロセス効率を犠牲にしているかもしれません。
--------------------
--------------------
* RFC 107, page 2
* RFC107、2ページ
[Page 4] RFC #176 -5- NIC #7100
[4ページ] RFC#176 -5NIC#7100
It is also clear that for efficiency arguments to hold, the byte size choice should not be an NCP prerogative. It is the combined efficiency, rather than NCP efficiency which should be our primary concern. Restricting byte size choice to NCPs has the further disadvantage of potential byte size mismatch not only between communicating NPCs but also at the user-NCP interface. Therefore, allowing a user process to specify byte size is a step in the right direction, given that we have adopted byte streams.
また、バイトサイズ選択が効率議論が成立するためには、NCP特権でないのも明確です。 それは私たちの第一の関心であるべきであるNCP効率よりむしろ総合効率です。 バイトサイズ選択をNCPに制限すると、潜在的バイトサイズミスマッチのさらなる不都合はNPCsを伝えることの間に持っているだけではなく、ユーザNCPインタフェースにも持たれています。 したがって、ユーザ・プロセスがバイトサイズを指定するのを許容するのは、正しい方向にステップです、私たちがバイト・ストリームを採用したなら。
It is our opinion that the issue of bit stream and byte stream be set aside until serious consideration can be given to a major Host-Host Protocol overhaul. At a later stage we will have a better idea of the relative efficiency merits.
ビットストリームとバイト・ストリームの問題が主要なHost-ホストプロトコルオーバーホールに真剣な考慮を与えることができるまでかたわらに置かれるのは、私たちの意見です。 後期段階に、私たちには、相対的効率長所の、より良い考えがあるつもりです。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 12/96 ]
[Page 5]
[5ページ]
一覧
スポンサーリンク