From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc103.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc103.txt (limited to 'doc/rfc/rfc103.txt') diff --git a/doc/rfc/rfc103.txt b/doc/rfc/rfc103.txt new file mode 100644 index 0000000..6a76431 --- /dev/null +++ b/doc/rfc/rfc103.txt @@ -0,0 +1,227 @@ + + + + + + + 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 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 + + + +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 +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, + + + +Crocker [Page 3] + +RFC 103 Implementation of Interrupt Keys February 1971 + + +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 RFC was put into machine readable form for entry ] + [ into the online RFC archives by Gert Doering 4/97 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crocker [Page 4] + -- cgit v1.2.3