Browse Prior Art Database

Implementation of Interrupt Keys (RFC0103) Disclosure Number: IPCOM000001834D
Original Publication Date: 1971-Feb-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 4 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.B. Kalin: AUTHOR

Related Documents

10.17487/RFC0103: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

NWG RFC 103 NIC 5764


R B Kalin MIT Lincoln Laboratory 24 Feb 1971

The current protocol specifications contain a serious logical error in the implementation of the program interrupt function. This paper discusses the problem and offers a solution that is simple to implement.


As found on most time-sharing systems the program interrupt key, elsewhere known as the break key, or help request button, has two functions. It suspends temporarily the user process being run, and it switches the keyboard input stream to a dormant supervisory process. Unaccepted input typed prior to the interrupt request remains buffered for the suspended user process. Subsequent typing is sent to a supervisory routine.

The current NCP protocol implements only half this function. It pprovides, through use of INS and INR control messages, for the suspension of a remote process, but it offers no mechanism for notifying the remote host at what time the data stream should be switched. INR and INS messages are sent via the control link and because messages on this link travel concurrently with those on the user’s keyboard input link, the receiving host can not rely on relative arrival times as a source of synchronizing information. Without such information the remote NCP can not know which input characters are meant for the user process and which are meant for the supervisory routine.

A solution found on some systems to this problem is that of mapping the interrupt signal into some code from the character set -- typically an ASCII control-C. Unfortunately, this is not general enough to be used within the ARPA network. Some systems, eg. MULTICS, make use of all available ASCII codes for other purposes, none are available for such an assignment. Even if such an assignment could be made, there is the problem of getting the interrupt character to be recognized by the remote host. Buffers on that user link may be full and the sending host may be unable to transmit the message containing

Crocker [Page 1]

RFC 103 Implementation of Interrupt Keys February 1971

the interrupt code. If the remote user process loops without accepting data, there is the possibility that its input buffers will never become free and that the message will never get through.

A partial answer is that of providing at the serving end a teletype scanner process that is always hungry for input. Because all input messages are immediately consumed, buffers remain available and interrupt codes can get through. Unfortunately, this implies that at times characters must be thrown away. After being scanned there may be no buffer space available for them. While not critical during console interactions -- users can type only when the program demands input -- this defect prevents the scanner from being driven from a text file.


The following defines a solution to this problem for the case of ASCII data streams.

1) Character messages should use eight bit fields for each c...