Implementation of Interrupt Keys
RFC 103

Document Type RFC - Unknown (February 1971; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 103 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
                                                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


    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 character

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 ( arbitrarilly 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.  Attempts to use them as
additional character codes will meet with resistance from PDP-10
systems that internally pack characters into seven bit fields.  Note
that this objection can not be made against the interrupt sync
character because it is filtered out by the system and never appears
in a user's input buffer.

5) Because of the possibility that there may be an insufficient
allocation to allow the user message containing the interrupt sync
character to be sent, the INR/INS mechanism currently defined must be
kept.  An INS control message should be sent at the time an interrupt
sync character is entered into a text stream. Upon its reception by
the foreign host, the attached process should be immediately suspended
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

Crocker                                                         [Page 2]
RFC 103            Implementation of Interrupt Keys             February 1971

should be switched to the newly activated supervisory process.  If it
is not possible to buffer all of the user process's input, it can be
thrown away, and a error message returned to the user by the
supervisory process.  In either event it must be guaranteed that
Show full document text