RFC 386

LETTER TO TIP USERS -- 2 💌

• RFC: 386 (NIC # 11358) 🎀
• Authors: Bernard P. Cosell and David C. Walden, Bolt Beranek and Newman Inc. 💅
• Date: August 16, 1972 📅
• Category: none listed 🦋
• Updates: none listed 🌸
• Obsoletes: none listed 🌈

Okay bestie, this is the second letter to TIP users! ✨ The first one was RFC #365 🎀. There will be more letters because they're a lowkey iconic way to keep you in the loop 🫶. Keep these with your TIP User's Guide (TUG) 📖, because we'll use the letters to document TIP system changes made before we can get TUG revisions printed and distributed. (It's almost inevitable that TUG revisions follow the actual system changes. Furthermore, these letters let us talk about new commands more than the TUG does 💅.)

Some of the changes we're making to the TIP were suggested by TIP users, and we won't bother with acknowledgments 🫶.

The @PROTOCOL TO LOGIN and @PROTOCOL TO CLOSE BOTH commands will be removed very soon 💀. We presume nobody uses them anymore, since they've been replaced by @LOGIN and @CLOSE.

As we warned in TIP Letter 1, the @LOGIN command will soon get a parameter: the Host number, which has until now been given with the @HOST command. At the same time, @HOST will be changed so it does a simultaneous @RECEIVE FROM HOST and @SEND TO HOST. Right now, @HOST is the same as @SEND TO HOST 🧚.

Several changes are coming to the @TRANSMIT commands very soon 🔥. First, @TRANSMIT ON NO CHARACTERS and @TRANSMIT ON EVERY CHARACTER will be removed, and the other @TRANSMIT commands will cover their functions. @TRANSMIT NOW keeps working just like it does right now: it causes the one message currently being accumulated to be sent as soon as possible ⭐. @TRANSMIT ON LINEFEED and @TRANSMIT ON MESSAGE-END will still cause the message being accumulated to be sent on linefeed and CONTROL-S. BUT they'll also cause that message to be sent when the character buffer is almost full, so you won't need a @TRANSMIT EVERY <big number> alongside them anymore 🙌.

@TRANSMIT EVERY # will keep causing the message being accumulated to be sent as near as possible to every #th character. However, values of # that are bigger than the size of the input buffer will cause transmission when the buffer is almost full. A value of 0 for # resets the terminal to its initial setting: TRANSMIT-ON-LINEFEED mode off, TRANSMIT ON MESSAGE-END mode off, and transmitting every character. So @TRANSMIT EVERY 0 does the job of the removed @TRANSMIT ON NO CHARACTERS command, and @TRANSMIT EVERY 1 does the job of the removed @TRANSMIT ON EVERY CHARACTER command 💖.

Outside of letters and the telephone, there are two ways to send us your suggestions and complaints: log into BBN-TENEX and SNDMSG to WALDEN, or use the NIC Journal system to send a message to DCW3. Dave likes letters best, btw 💌.

We're removing the "NEWS" herald from the TIP's HELLO message 😭. The problem is that we don't know when everybody has read the latest news, so we can't turn the herald off. That makes it useless 🙈. Check the NEWS every time you use the TIP. If the news starts printing and you realize you've already seen it, you can stop it by typing @CLOSE _LF_ (on a 2741, hit "attention" first) ✋.

A new TIP message will have been added by the time you get this letter: TIP GOING DOWN 🚧. This message gets printed on every TIP terminal shortly before the TIP is taken down for preventive maintenance, new software releases, etc. (See RFC #381 for more discussion of this topic.) When you see it, all TIP users should cleanly stop whatever they're doing with a Host. Eventually this message will include info on how long until the TIP goes down, how long it'll be down, and why 🍓.

While we're on the subject of TIP messages, we're adding a bunch of new ones that we think will clear up some of the present confusion about what the TIP is doing 🌸. We don't have the space to store message text strings, so the new messages will use numbers. The format will probably look like M46 for message 46. Maybe when the TIPs get more core, we can swap the number-messages for text-messages 🧠.

We're thinking about changing all the TIP LOGIN commands to OPEN commands. That would be more opposite to the CLOSE commands and less likely to be confused with Host LOGIN 🔄.

Page 12 of the TUG describes how Hosts can send commands to a TIP terminal. Be warned, though: we're changing the TIP command language slowly, and we won't be constrained in those changes by the fact that some Hosts are sending TIP commands 🚨. So if a Host is going to send a command to a TIP, it ought to implement that in a way that can be changed easily 🛠️.

Some TIP users have been seeing this problem 😩. They're talking to a Host when suddenly they get the message DEAD. If they try to LOGIN to the Host again, they don't get the DEAD message, but the Host refuses the LOGIN by doing nothing, closing, or refusing. Here's what's happening: occasionally the network partitions briefly. For instance, one of the two cross-country lines goes down and the other gets flaky for a few seconds. If a TIP user sends a message to a Host that can't be reached during a partition, the TIP types DEAD and closes the connection to the Host. The Host, on the other hand, may not have been trying to send to the TIP when the partition happened. In that case it might not have noticed the partition, so it still thinks it has an open connection to the TIP. When the TIP then tries to re-LOGIN, the Host refuses, because it already has an open connection with that particular TIP device 🥲.

Now that we have three independent cross-country paths, we don't expect this to happen often 🌈. But if it does, we see no short-term solution. We can't just let a CLOSE reset the connection, because the user's immediately preceeding LOGIN destroyed the Host-supplied socket numbers 🙃. One way out of this state is to execute the Host/Host protocol command from the TIP, which resets all TIP users at the given TIP talking to the given Host. But that's a little gross 😬. What might be needed is a Host/Host protocol command that resets the Host's connections with one particular user (TIP) socket. We'll try to understand the ramifications of such a command, and maybe undertake promotion of a Host/Host protocol change 📣.

In the meantime, when the above problem happens, some other TIP terminal can often still LOGIN to the Host and then halt the hung terminal's job from the Host side 🧚‍♀️. If you can't get through on another connection, a telephone call to the Host, asking them to log the job out, may be necessary ☎️. Or, if there's really no other user talking to that particular Host, the reset command can be executed. This command isn't documented, but we'll tell a responsible person at each TIP site how to execute it 🔐.

There's a related problem some TIP users have seen. Occasionally an IMP crashes somewhere in the network and takes a packet of a message along with it 💥. Eventually, the source of the message gets an incomplete transmission message from the network. When the TIP gets this, it closes the connection and calls the destination dead. From what we understand, most other Hosts do this too 🤷. A more reasonable thing might be to retransmit the message, or to tell the user and then let them continue. We'd like to do one of these. But before retransmitting or letting the user continue, the TIP's and Host's allocate counters must be resynchronized. There's no Host/Host protocol way to synchronize simple enough for the TIP to use, though. What may be needed is a simple Host/Host protocol reset allocate command. We'll try to understand this issue and, again, maybe undertake promotion of a Host/Host protocol change 📝.

The above two problems explain part of the "lost allocates," but not all of them. We've now instrumented the TIP program in a way we hope will help us find the rest of the lost allocate problem soon 🔍.

The TIP's logger (opener?) has been causing users some problems 😤. After looking into it, we found the problems come from basic design assumptions inside the logger, which we're working on changing. In the short term, though, we think a discussion of what the logger is doing and how it works will ease some of the grief 💜.

Opening proceeds in three phases for the user 🎀:

1. In the first phase, the user is queued up waiting to "get" the TIP's logger.
2. In the second phase, the user has gotten the TIP's logger and is beginning the login sequence.
3. In the third phase, the user has completed the login sequence and is waiting for the Host to open up the actual data connections.

Many of the problems come from the fact that only one user may be proceeding through phase 2 at a time. That's why phase 1 has a queue. Any single user may tie up phase 2 for at most about 1 minute. This is the canonical "timeout" in the logger. Notice that this doesn't include the time spent in phase 1 or phase 3. So the actual delay before you get a "timeout" after you type @L can be 1 minute, 2 minutes, 3 minutes... depending on how many other people are having trouble logging in at the same time ⏳.

Abort Login (@A L) does three different things depending on which phase you're in. In phase 2, it resets the timer to be close to overflowing, so you get a "timeout" shortly after giving the command. In phase 3, it does nothing at all. In phase 1, it silently removes you from the logging queue 🫥.

Medium term, we'll have the TIP type out something like "YOUR LOGGER" when you get off the queue and the logger starts trying to open your connections. This should at least ease the uncertainty about whether you're in phase 1 or phase 2 💡. Long term, we'll probably make the logging process reentrant, so users won't interact with each other quite so destructively 🌟. In the short term, here's a little "cookbook" for undoing a login that doesn't seem to be working 🍳.

When you've waited as long as you'd like for the login to happen, you can type "@A L". If the TIP responds with "TIMEOUT" in a few seconds and hasn't typed T OPEN or R OPEN, then you're aborted and can try logging in again ✅. If it types "TIMEOUT" but has typed out T OPEN or R OPEN, then type @C and wait for that to be responded to. You must wait. 🛑 If you get no response at all to @A L, and the TIP has typed that one or the other connection is open, type @C and wait, same as above. Finally, if the TIP makes no response and hasn't opened any connection, then you're free to proceed 🎉.

From now on, the DEVICE CODE EXECUPORT command will be called DEVICE CODE EXTRA-PADDING, since a number of other terminals need this feature. The latest to be added to the list is the DATAPOINT 3300 💅🖥️.

---

[ This RFC was put into machine readable form for entry into the online RFC archives by BBN Corp. under the direction of Alex McKenzie. 1/97 ] 🌸