RFC297 - TIP Message Buffers

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

NETWORK WORKING GROUP Dave Walden

REQUEST COMMENTS #297 BBN

NIC #8485 1/31/72

Categories: C or maybe D

Updates: none

Obsoletes: none

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.

Let's first consider messages going from a TIP to another Host.

The buffers have the following sizes:

device numbers buffer size (in 8 bit characters)

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.

Now let's consider messages going from another Host to a TIP.

The buffers have the following sizes:

device numbers buffer size (in 8 bit characters)

1 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.

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.

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.

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.

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by BBN Corp. under the ]

[ direction of Alex McKenzie. 12/96 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航