home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc103.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  7.6 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                                                 NWG RFC 103
  8.                                                 NIC 5764
  9.  
  10.  
  11. IMPLEMENTATION OF INTERRUPT KEYS
  12.  
  13.  
  14. R B Kalin
  15. MIT Lincoln Laboratory
  16. 24 Feb 1971
  17.  
  18.  
  19.     The current protocol specifications contain a serious logical
  20. error in the implementation of the program interrupt function.  This
  21. paper discusses the problem and offers a solution that is simple to
  22. implement.
  23.  
  24. THE PROBLEM
  25.  
  26.     As found on most time-sharing systems the program interrupt key,
  27. elsewhere known as the break key, or help request button, has two
  28. functions.  It suspends temporarily the user process being run, and it
  29. switches the keyboard input stream to a dormant supervisory process.
  30. Unaccepted input typed prior to the interrupt request remains buffered
  31. for the suspended user process.  Subsequent typing is sent to a
  32. supervisory routine.
  33.  
  34.     The current NCP protocol implements only half this function.  It
  35. pprovides, through use of INS and INR control messages, for the
  36. suspension of a remote process, but it offers no mechanism for
  37. notifying the remote host at what time the data stream should be
  38. switched.  INR and INS messages are sent via the control link and
  39. because messages on this link travel concurrently with those on the
  40. user's keyboard input link, the receiving host can not rely on
  41. relative arrival times as a source of synchronizing information.
  42. Without such information the remote NCP can not know which input
  43. characters are meant for the user process and which are meant for the
  44. supervisory routine.
  45.  
  46.     A solution found on some systems to this problem is that of
  47. mapping the interrupt signal into some code from the character set --
  48. typically an ASCII control-C.  Unfortunately, this is not general
  49. enough to be used within the ARPA network.  Some systems, eg. MULTICS,
  50. make use of all available ASCII codes for other purposes, none are
  51. available for such an assignment.  Even if such an assignment could be
  52. made, there is the problem of getting the interrupt character to be
  53. recognized by the remote host.  Buffers on that user link may be full
  54. and the sending host may be unable to transmit the message containing
  55.  
  56.  
  57.  
  58. Crocker                                                         [Page 1]
  59.  
  60. RFC 103            Implementation of Interrupt Keys             February 1971
  61.  
  62.  
  63. the interrupt code.  If the remote user process loops without
  64. accepting data, there is the possibility that its input buffers will
  65. never become free and that the message will never get through.
  66.  
  67.     A partial answer is that of providing at the serving end a
  68. teletype scanner process that is always hungry for input.  Because all
  69. input messages are immediately consumed, buffers remain available and
  70. interrupt codes can get through.  Unfortunately, this implies that at
  71. times characters must be thrown away.  After being scanned there may
  72. be no buffer space available for them.  While not critical during
  73. console interactions -- users can type only when the program demands
  74. input -- this defect prevents the scanner from being driven from a
  75. text file.
  76.  
  77.  
  78. A SOLUTION
  79.  
  80.     The following defines a solution to this problem for the case of
  81. ASCII data streams.
  82.  
  83. 1) Character messages should use eight bit fields for each character
  84. code.
  85.  
  86. 2) For all of the defined ASCII character codes the left most bit in
  87. the eight bit field shall be zero.
  88.  
  89. 3) An interrupt sync character ( arbitrarilly given the code octal 200
  90. ) should be placed in the data stream at the correct point in the
  91. typing sequence.
  92.  
  93. 4) All codes from octal 201 to octal 377 are officially to be ignored
  94. by a receiving host.  Their use is reserved for additional control
  95. information, should it become necessary.  Attempts to use them as
  96. additional character codes will meet with resistance from PDP-10
  97. systems that internally pack characters into seven bit fields.  Note
  98. that this objection can not be made against the interrupt sync
  99. character because it is filtered out by the system and never appears
  100. in a user's input buffer.
  101.  
  102. 5) Because of the possibility that there may be an insufficient
  103. allocation to allow the user message containing the interrupt sync
  104. character to be sent, the INR/INS mechanism currently defined must be
  105. kept.  An INS control message should be sent at the time an interrupt
  106. sync character is entered into a text stream. Upon its reception by
  107. the foreign host, the attached process should be immediately suspended
  108. and the associated input stream should be scanned.  If possible, all
  109. input up to the interrupt sync character should be buffered for the
  110. suspended process.  Once the sync character is found, the stream
  111.  
  112.  
  113.  
  114. Crocker                                                         [Page 2]
  115.  
  116. RFC 103            Implementation of Interrupt Keys             February 1971
  117.  
  118.  
  119. should be switched to the newly activated supervisory process.  If it
  120. is not possible to buffer all of the user process's input, it can be
  121. thrown away, and a error message returned to the user by the
  122. supervisory process.  In either event it must be guaranteed that
  123. outstanding input will be consumed and message buffers will be freed
  124. so that pending character messages can be sent.
  125.  
  126. 6) In the event that an interrupt sync character is received before
  127. the matching INS, the user process should be suspended and the NCP
  128. should wait for the INS before proceeding.
  129.  
  130. 7) The function of the NCP is the above discussion can, of course, be
  131. delegated a separate modulo, eg. a TELNET process.  If this is done,
  132. the NCP can be transparent to message content.
  133.  
  134.  
  135. COMMENTARY
  136.  
  137.     The proposed change to the second level protocol described herein
  138. is not meant as a general solution, but rather as a specific patch to
  139. the current NCP design with the intent of correcting a critical error.
  140. Its more obvious deficiencies are...
  141.  
  142. 1) It only works with seven bit code character streams.  No extensions
  143. are allowed for EBCDIC, ASCII-8, or other large character sets.  No
  144. provision is made for interrupting a process to which there is no
  145. character stream, although the author knows of no case in which the
  146. concept means more than closing the connection.
  147.  
  148. 2) It requires the system to scan all data coming over an
  149. interruptable connection.  Presumably this means that at the time the
  150. connection is created, the receiving host must be told that this scan
  151. is to be done.  Various techniques, both implicit and explicit, could
  152. be used.
  153.  
  154. 3) The technique is not immune to loss character boundaries within a
  155. message nor can it tolerate INS control messages that do not have
  156. matching sync characters, or vis versa.
  157.  
  158. 4) It may not possible to get either the INS or the text message
  159. containing the interrupt sync character to a remote host.  Possible
  160. reasons include user console failure, local host failure, network
  161. failure, blocked control link, insufficient allocation etc.  Under
  162. such circumstances the remote process may loop indefinitely.
  163.  
  164.  
  165.     The only comprehensive solution known to the interrupt
  166. synchronization problem, those that avoid the above difficulties,
  167.  
  168.  
  169.  
  170. Crocker                                                         [Page 3]
  171.  
  172. RFC 103            Implementation of Interrupt Keys             February 1971
  173.  
  174.  
  175. require more than minor changes to the current NCP protocol.  Unless
  176. simpler answers are suggested, their implementation must be postponed
  177. until the next major design revision.
  178.  
  179.        [ This RFC was put into machine readable form for entry ]
  180.          [ into the online RFC archives by Gert Doering 4/97 ]
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Crocker                                                         [Page 4]
  227.  
  228.