Movatterモバイル変換

                                                NWGRFC 103                                                NIC 5764IMPLEMENTATION OF INTERRUPT KEYSR B KalinMIT Lincoln Laboratory24 Feb 1971The current protocol specifications contain a serious logicalerror in the implementation of the program interrupt function.  Thispaper discusses the problem and offers a solution that is simple toimplement.THE PROBLEM    As found on most time-sharing systems the program interrupt key,elsewhere known as the break key, or help request button, has twofunctions.  It suspends temporarily the user process being run, and itswitches the keyboard input stream to a dormant supervisory process.Unaccepted input typed prior to the interrupt request remains bufferedfor the suspended user process.  Subsequent typing is sent to asupervisory routine.    The current NCP protocol implements only half this function.  Itpprovides, through use of INS and INR control messages, for thesuspension of a remote process, but it offers no mechanism fornotifying the remote host at what time the data stream should beswitched.  INR and INS messages are sent via the control link andbecause messages on this link travel concurrently with those on theuser's keyboard input link, the receiving host can not rely onrelative arrival times as a source of synchronizing information.Without such information the remote NCP can not know which inputcharacters are meant for the user process and which are meant for thesupervisory routine.    A solution found on some systems to this problem is that ofmapping the interrupt signal into some code from the character set --typically an ASCII control-C.  Unfortunately, this is not generalenough to be used within the ARPA network.  Some systems, eg. MULTICS,make use of all available ASCII codes for other purposes, none areavailable for such an assignment.  Even if such an assignment could bemade, there is the problem of getting the interrupt character to berecognized by the remote host.  Buffers on that user link may be fulland the sending host may be unable to transmit the message containingCrocker                                                         [Page 1]

RFC 103            Implementation of Interrupt Keys             February 1971the interrupt code.  If the remote user process loops withoutaccepting data, there is the possibility that its input buffers willnever become free and that the message will never get through.    A partial answer is that of providing at the serving end ateletype scanner process that is always hungry for input.  Because allinput messages are immediately consumed, buffers remain available andinterrupt codes can get through.  Unfortunately, this implies that attimes characters must be thrown away.  After being scanned there maybe no buffer space available for them.  While not critical duringconsole interactions -- users can type only when the program demandsinput -- this defect prevents the scanner from being driven from atext file.A SOLUTION    The following defines a solution to this problem for the case ofASCII data streams.1) Character messages should use eight bit fields for each charactercode.2) For all of the defined ASCII character codes the left most bit inthe 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 thetyping sequence.4) All codes from octal 201 to octal 377 are officially to be ignoredby a receiving host.  Their use is reserved for additional controlinformation, should it become necessary.  Attempts to use them asadditional character codes will meet with resistance from PDP-10systems that internally pack characters into seven bit fields.  Notethat this objection can not be made against the interrupt synccharacter because it is filtered out by the system and never appearsin a user's input buffer.5) Because of the possibility that there may be an insufficientallocation to allow the user message containing the interrupt synccharacter to be sent, the INR/INS mechanism currently defined must bekept.  An INS control message should be sent at the time an interruptsync character is entered into a text stream. Upon its reception bythe foreign host, the attached process should be immediately suspendedand the associated input stream should be scanned.  If possible, allinput up to the interrupt sync character should be buffered for thesuspended process.  Once the sync character is found, the streamCrocker                                                         [Page 2]

RFC 103            Implementation of Interrupt Keys             February 1971should be switched to the newly activated supervisory process.  If itis not possible to buffer all of the user process's input, it can bethrown away, and a error message returned to the user by thesupervisory process.  In either event it must be guaranteed thatoutstanding input will be consumed and message buffers will be freedso that pending character messages can be sent.6) In the event that an interrupt sync character is received beforethe matching INS, the user process should be suspended and the NCPshould wait for the INS before proceeding.7) The function of the NCP is the above discussion can, of course, bedelegated 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 hereinis not meant as a general solution, but rather as a specific patch tothe 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 extensionsare allowed for EBCDIC, ASCII-8, or other large character sets.  Noprovision is made for interrupting a process to which there is nocharacter stream, although the author knows of no case in which theconcept means more than closing the connection.2) It requires the system to scan all data coming over aninterruptable connection.  Presumably this means that at the time theconnection is created, the receiving host must be told that this scanis to be done.  Various techniques, both implicit and explicit, couldbe used.3) The technique is not immune to loss character boundaries within amessage nor can it tolerate INS control messages that do not havematching sync characters, or vis versa.4) It may not possible to get either the INS or the text messagecontaining the interrupt sync character to a remote host.  Possiblereasons include user console failure, local host failure, networkfailure, blocked control link, insufficient allocation etc.  Undersuch circumstances the remote process may loop indefinitely.    The only comprehensive solution known to the interruptsynchronization problem, those that avoid the above difficulties,Crocker                                                         [Page 3]

RFC 103            Implementation of Interrupt Keys             February 1971require more than minor changes to the current NCP protocol.  Unlesssimpler answers are suggested, their implementation must be postponeduntil 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 ]Crocker                                                         [Page 4]