Browse Prior Art Database

Implementation of Interrupt Keys (RFC0103)

IP.com Disclosure Number: IPCOM000001834D
Original Publication Date: 1971-Feb-24
Included in the Prior Art Database: 2002-Jan-29
Document File: 5 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.B. Kalin: AUTHOR

Abstract

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.

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

                                                NWG RFC 103

                                                NIC 5764

IMPLEMENTATION OF INTERRUPT KEYS

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.

THE PROBLEM

    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.

A SOLUTION

    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...