RFC297 日本語訳

NETWORK WORKING GROUP                     Dave Walden
REQUEST  COMMENTS #297                    BBN
NIC #8485                                 1/31/72
Categories: C or maybe D
Updates: none
Obsoletes: none

ワーキンググループデーヴウォルデンREQUESTコメント#297BBN NIC#8485の1/31/72のカテゴリをネットワークでつないでください: Cか多分D Updates: Obsoletesのいずれも:でない なし

                          TIP Message Buffers

チップメッセージ・バッファ

     We have recently heard some groaning about the size of the TIP's
message buffers.  While we realize these aren't as big as some Hosts
might desire, they aren't as small as the intensity of the groans
suggest either.

私たちは最近、TIPのメッセージ・バッファのサイズに関していくつかのうめき声を聞きました。 私たちが、これらがいくつかのHostsが望むかもしれないほど大きくないとわかりますが、彼らはうめき声の強度が示すほど小さくはありません。

     Let's first consider messages going from a TIP to another Host.
The buffers have the following sizes:

最初に、TIPから別のHostまで行くメッセージを考えましょう。 バッファには、以下のサイズがあります:

     device numbers           buffer size (in 8 bit characters)
         1-2                       64
         3-16                      32
        17-41                      16
        42-62                      8
         63                        6

装置番号バッファサイズ(8ビットのキャラクタの)1-2 64 3-16 32 17-41 16 42-62 8 63 6

The TIP user has the option of having his messages sent 1) every
character, 2) on line feeds and/or com's, 3) every nth character, or
4) the OR of 2) and 3). Selecting to have messages sent every large
number of characters, say 100, will result in the TIP sending the
longest messages it can for a given device.  Hosts which don't like to
receive very short messages might advise users accessing them from a
TIP to set the TIP's parameters to use the maximum length buffer.

TIPユーザには、3の)稼働中なすべての2歳のキャラクタが)食べさせる1、)そして/または、comのものを彼のメッセージに送らせるオプション、すべてのn番目のキャラクタ、または2と)3の)4)ORがあります。 100は、多くのキャラクタにメッセージを送らせる選択が送る中で与えられたデバイスのためにそうすることができる中でメッセージ最も長いTIPをもたらすと言います。 非常に短いメッセージを受け取るのが好きでないホストは、最大の長さのバッファを使用するためにTIPから彼らにアクセスするユーザがTIPのパラメタを設定するようにアドバイスするかもしれません。

     Now let's consider messages going from another Host to a TIP.
The buffers have the following sizes:

今、別のHostからTIPまで行くメッセージを考えましょう。 バッファには、以下のサイズがあります:

     device numbers           buffer size (in 8 bit characters)
        1                          96
        2                          64
        3                          48
       4-17                        24
      18-35                        16
      36-63                         8

装置番号は1サイズ(8ビットのキャラクタの)96 2 64 3 48 4-17 24 18-35 16 36-63 8をバッファリングします。

                                                                [Page 1]

The TIP double buffers its terminal output.  Thus, when a TIP terminal
makes a connection to a Host, the TIP sends off an allocation of
between 8 and 96 characters, depending on the terminals device number,
and when a message comes using up the allocation, the TIP immediately
sends another allocation for the same number of characters while it
prints the first buffer.

[1ページ] TIPは端末が出力したバッファを倍にします。 メッセージがすぐに配分を使いきりながら来るとき、したがって、端末装置番号によって、TIP端末がHostに接続を作ると、TIPは8〜96のキャラクタの配分を送って、それは最初のバッファを印刷しますが、TIPは同じ数のキャラクタのために別の配分を送ります。

     For traffic both to and from the TIP, lower numbered devices have
bigger buffers.  Therefore, users of line oriented systems, as well as
users of higher speed devices, should try to come in through the lower
numbered ports on the TIP's multi-line controller, if possible.

TIPとTIPからのトラフィックのために、下側の番号付のデバイスには、より大きいバッファがあります。 したがって、指向のシステムが、より高い速度デバイスのユーザと同様に下側を通って入ろうとするはずである系列のユーザはTIPのマルチ系列コントローラの上のポートに付番しました、できれば。

     The sizes of the TIP's message buffers and the number of each
size are not permanently fixed and can be changed if a better
distribution is suggested.  We didn't know what size buffers to
provide so we have provided a variety, What is fairly fixed is the
total amount of buffer space: two output buffers and one input buffer
for each of 63 devices must come out of this total buffer space.

より良い分配を示すなら、TIPのメッセージ・バッファのサイズとそれぞれのサイズの数を永久に、固定しないで、変えることができます。 私たちは、私たちがバラエティーを提供して、サイズが提供するために何をバッファリングするかを知らないで、Whatによる公正に修理されているのが、バッファ領域の総量であるということです: それぞれの63台のデバイスのための2つの出力バッファと1つの入力バッファがこの総バッファ領域から出て来なければなりません。

     The answer to your question "Why not dynamically allocate buffers
at run time?" is: It is a complicated job to do that.  It requires
memory compactions, a mechanism to reclaim space from current users
when a new user comes on, etc.  Our guess is that the code to
dynamically allocate buffers at run time would reduce the total space
available for buffers by about one-fifth.

「なぜランタイムのときにダイナミックにバッファを割り当てませんか?」というあなたの質問の答えは以下の通りです。 それをするのは、複雑な仕事です。 新しいユーザが来るのなどと、現在のユーザからスペースを取り戻すのがメモリ圧縮、メカニズムを必要とします。 私たちの推測はランタイムのときにダイナミックにバッファを割り当てるコードがバッファにおよそ1/5利用可能な総スペースを減少させるだろうということです。

       [ 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 2]

[2ページ]