RFC 103

NWG RFC 103: Implementation of Interrupt Keys 🎀

Okay bestie, let's do the paperwork first 📋✨ This one is NWG RFC 103 (also filed as NIC 5764), and it's called Implementation of Interrupt Keys.

• Author: R B Kalin, MIT Lincoln Laboratory 🧚
• Date: 24 Feb 1971 📅
• Category or status: not stated in the original 🤷
• Obsoletes: not stated 🤷
• Updates: not stated 🤷

Quick tea: the current protocol specs have a seriously broken logic bug in how the program interrupt function gets implemented 😭 This paper digs into the problem and offers a fix that's simple to implement 💅

THE PROBLEM 🔥

On most time-sharing systems, the program interrupt key (aka the break key, or the help request button 🆘) does two jobs. First, it temporarily suspends the user process that's running. Second, it switches the keyboard input stream over to a dormant supervisory process. Any input you typed before the interrupt that hasn't been accepted yet stays buffered for the suspended user process. Anything you type after that goes to the supervisory routine.

The current NCP protocol only does half of this 💀 It provides for suspending a remote process using INS and INR control messages, but it has no way of telling the remote host when the data stream should be switched. INR and INS messages travel over the control link, and they move at the same time as the user's keyboard input on its own link. So the receiving host can't rely on relative arrival times to figure out the timing. Without that info, the remote NCP has no way of knowing which input characters are for the user process and which are for the supervisory routine 🙈

A solution some systems use is to map the interrupt signal to a code from the character set, usually an ASCII control-C. Unfortunately, that isn't general enough for the ARPA network 😤 Some systems, e.g. MULTICS, use every available ASCII code for other things, so none are free for this. Even if one could be assigned, the interrupt character still has to be recognized by the remote host. The buffers on that user link may be full, so the sending host may not be able to send the message carrying the interrupt code. And if the remote user process loops without accepting data, its input buffers may never free up, so the message may never get through.

A partial answer is to put a teletype scanner process at the serving end that's always hungry for input 🍓 Since every input message gets consumed right away, buffers stay free and interrupt codes can get through. The catch is that characters sometimes have to be thrown away, and by the time they've been scanned there may be no buffer space left for them. That's not a big deal during console interactions, since users can only type when the program asks for input. But it stops the scanner from being driven from a text file 📄

A SOLUTION ✨

This is a fix for the problem above, for ASCII data streams 💖

1. Character messages SHOULD use eight bit fields for each character code.
2. For all of the defined ASCII character codes, the left most bit in the eight bit field SHALL be zero.
3. An interrupt sync character (arbitrarily given the code octal 200) SHOULD be placed in the data stream at the correct point in the typing sequence.
4. All codes from octal 201 to octal 377 are officially to be ignored by a receiving host. Their use is reserved for additional control information, should it become necessary. Trying to use them as extra character codes will get pushback from PDP-10 systems, which pack characters internally into seven bit fields. Note that this objection can not be made against the interrupt sync character, because the system filters it out and it never shows up in a user's input buffer 🙅‍♀️
5. Because there might not be enough allocation to send the user message containing the interrupt sync character, the INR/INS mechanism as currently defined MUST be kept. An INS control message SHOULD be sent at the moment an interrupt sync character is entered into a text stream. When the foreign host receives it, the attached process SHOULD be suspended immediately, and the associated input stream SHOULD be scanned. If possible, all input up to the interrupt sync character SHOULD be buffered for the suspended process. Once the sync character is found, the stream SHOULD be switched to the newly activated supervisory process. If it isn't possible to buffer all of the user process's input, it can be thrown away, and the supervisory process can return an error message to the user. Either way, it MUST be guaranteed that outstanding input gets consumed and message buffers get freed, so pending character messages can be sent 🧹
6. If an interrupt sync character arrives before the matching INS, the user process SHOULD be suspended, and the NCP SHOULD wait for the INS before going any further 🛑
7. The NCP's function in the discussion above can, of course, be handed off to a separate module, e.g. a TELNET process. If that's done, the NCP can be transparent to message content 🦋

COMMENTARY 🌸

This proposed change to the second level protocol is not meant as a general solution. It's a specific patch to the current NCP design, meant to fix a critical error. Its more obvious deficiencies are...

1. It only works with seven bit code character streams. No extensions are allowed for EBCDIC, ASCII-8, or other large character sets. There's also no provision for interrupting a process that has no character stream, though the author knows of no case where that concept means more than closing the connection.
2. It requires the system to scan all data coming over an interruptable connection. Presumably that means that when the connection is created, the receiving host MUST be told the scan is to be done. Various techniques, both implicit and explicit, could be used 🧐
3. The technique is not immune to lost character boundaries within a message, and it can't handle INS control messages that lack matching sync characters, or vice versa 😬
4. It may not be possible to get either the INS or the text message containing the interrupt sync character to a remote host. Possible reasons include user console failure, local host failure, network failure, a blocked control link, insufficient allocation, etc. In those cases, the remote process may loop indefinitely 🌀

The only comprehensive solutions known to the interrupt synchronization problem (the ones that avoid the difficulties above) need more than minor changes to the current NCP protocol. Unless simpler answers turn up, their implementation MUST be postponed until the next major design revision 🗓️👑

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gert Doering 4/97 ]