TIP Message Buffers
Explaining why TIP message buffers vary by device and how to use them
Walden, D.C., "TIP Message Buffers", RFC 297, DOI 10.17487/RFC0297, January 1972, <https://www.rfc-editor.org/info/rfc297>.
@misc{rfc297,
series = {Request for Comments},
number = 297,
howpublished = {RFC 297},
publisher = {RFC Editor},
doi = {10.17487/RFC0297},
url = {https://www.rfc-editor.org/info/rfc297},
author = {D.C. Walden},
title = {{TIP Message Buffers}},
pagetotal = 2,
year = 1972,
month = jan,
} RFC text
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
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 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 ]
AI ELI5
On this page
§1Buffer Sizing on the TIP
The Terminal Interface Processor (TIP) receives complaints about message buffer size, but the actual buffer sizes are not as extreme as the complaints suggest. For messages from a TIP to another host, buffer sizes range from 64 characters for device ports 1-2 down to 6 characters for port 63. For messages from a host back to a TIP, sizes range from 96 characters for port 1 down to 8 characters for ports 36-63.
The TIP double buffers its terminal output, so when a connection is made, it allocates an initial buffer amount and immediately prepares a second buffer of the same size while printing the first one.
Different network ports have different sized message containers, with the smaller port numbers getting bigger containers.
§2Configuring TIP Parameters
Users have four options for when the TIP sends messages: every single character, on line feeds or carriage returns, every nth character (where n is configurable), or the combination of the latter two. Selecting a large n value (such as 100) allows the TIP to send the longest possible messages for a given device port, filling the allocated buffer completely.
Hosts that prefer not to receive very short messages can advise their users to configure the TIP to maximize buffer length. This requires users to set parameters appropriately when connecting through the TIP.
You can tell the TIP to wait and gather characters into bigger messages instead of sending them right away.
§3Design Constraints
The sizes and quantities of each buffer in the TIP are not permanently fixed and can be changed if better distributions are suggested. However, the total amount of buffer space available is fairly fixed, as each of the 63 devices requires two output buffers and one input buffer that must come from this total.
Dynamic buffer allocation at runtime would require memory compaction and mechanisms to reclaim space from current users when new users connect. The developers estimated that implementing dynamic allocation would reduce total available buffer space by about one-fifth, making fixed allocation more practical.
Instead of dynamically resizing containers, the TIP uses fixed-size bags, which is simpler and wastes less space overall.