RFC103 - Implementation of Interrupt Keys

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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

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

outstanding input will be consumed and message buffers will be freed

so that pending character messages can be sent.

6) In the event that an interrupt sync character is received before

the matching INS, the user process should be suspended and the NCP

should wait for the INS before proceeding.

7) The function of the NCP is the above discussion can, of course, be

delegated a separate modulo, eg. a TELNET process. If this is done,

the NCP can be transparent to message content.

COMMENTARY

The proposed change to the second level protocol described herein

is not meant as a general solution, but rather as a specific patch to

the current NCP design with the intent of correcting 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. No

provision is made for interrupting a process to which there is no

character stream, although the author knows of no case in which the

concept means more than closing the connection.

2) It requires the system to scan all data coming over an

interruptable connection. Presumably this means that at the time the

connection is created, the receiving host must be told that this scan

is to be done. Various techniques, both implicit and eXPlicit, could

be used.

3) The technique is not immune to loss character boundaries within a

message nor can it tolerate INS control messages that do not have

matching sync characters, or vis versa.

4) It may not 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, blocked control link, insufficient allocation etc. Under

such circumstances the remote process may loop indefinitely.

The only comprehensive solution known to the interrupt

synchronization problem, those that avoid the above difficulties,

require more than minor changes to the current NCP protocol. Unless

simpler answers are suggested, their implementation must be postponed

until the next major design revision.

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Gert Doering 4/97 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航