RFC 297

RFC 297: TIP Message Buffers 🎀

bestie, the title block tea ☕: this is RFC 297, also filed as NIC #8485, written by Dave Walden at BBN on 1/31/72 🧚. It's categorised as C or maybe D 💅. It updates: none and obsoletes: none 🌸.

so people have been groaning about how small the TIP's message buffers are 😭. Like, fair, they aren't as big as some Hosts would love 💖, but they're also not as tiny as the groans make it sound 🙈.

okay so let's start with messages going from a TIP to another Host 🦋. The buffers come in these sizes (in 8 bit characters):

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 gets to pick how their messages get sent: 1) every character, 2) on line feeds and/or com's, 3) every nth character, or 4) the OR of 2) and 3) ✨. If you pick a big number like 100, the TIP sends the longest messages it can for a given device 🫶. Hosts that don't love getting super short messages might tell users coming in from a TIP to set the TIP's parameters to use the maximum length buffer 👑.

Now let's look at messages going from another Host to a TIP 🍓. The buffers are:

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 🔥. So 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 terminal's device number 🌈. When a message comes in and uses 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, lowkey the main character of the whole setup 👑. So 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 they can be changed if a better distribution is suggested 🦋. We didn't know what size buffers to provide, so we 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 "Why not dynamically allocate buffers at run time?" is: it's 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   ]