当前的协议规范在程序中断函数的实现方面有非常严重的逻辑错误。本文献对这一
问题加以讨论，并给出一个比较轻易实现的解决方案。
问题描述
大多数分时共享系统的程序中断键（或称为中断程序运行键（breakkey）、帮助
请求按钮）具有两个功能。它将当前用户进程挂起，并将键盘输入流转换到后台监控进
程。在中断请求之前未被接受的输入保存在缓冲器内等待挂起的用户进程处理。之后的
输入被送到监控例程。
目前的NCP协议只实现了上述功能的一部分。它通过INS和INR控制信息的使用为
远程过程的挂起做预备。但它并未提供向远程主机通知数据流转换时间的机制。INR和
INS消息通过控制链发送。由于这条链上的消息与用户的键盘输入链并发传送，接收主
机不能凭借相对到达时间来判定同步信息源。而缺乏这种信息，远程NCP不能判定输入
字符与用户进程和监控例程之间的对应关系。
一些系统中对于这一问题的解决方法是将中断信号映射到字符集中的一些代码，如
ASCII码control-C。但不幸的是，这一方法在ARPA网络中还不够普遍。一些系统，如
MULTICS，将所有可用的ASCII码用作其它用途，没有空余留给这一指派。即使可以实
现这样一个指派，还有使中断字符被远程主机所识别的问题。假如用户链的缓冲器已满，
发送端主机则不能传送包含中断码的消息。假如远程用户进程循环进行而不接收数据，
则其缓冲器可能永远不会空闲，消息也就永远不会传入。
一个有局限性的解决方案是在服务端提供一个报文扫描进程来捕捉输入。因为所有
的输入信息都被立即销毁，缓冲器可保持可用状态以使中断码进入。不幸的是，这意味
着时间特性必须被抛弃。因为在扫描过后，可能已经不存在供它们存放的空间。尽管这
对于终端交互而言并非至关重要，因为用户可以只在程序要求输入的情况下输入，但这
一缺陷使得扫描器不能实现文本驱动。
一种解决方案
以下定义了在ASCII数据流的情况下，这一问题的解决方案。
1） 字符消息的每个字符代码都应使用8位数域。
2） 对于所有定义过的ASCII字符代码，8位数域的左端应为0。
3） 在输入序列中，应在数据流的合适点处放置一个中断同步字符（任给8进
制代码200）
4） 8进制数201到377被接收主机忽略。它们被保留做在必要的时候当附加
控制信息使用。将其用作附加字符代码的尝试将碰到来自将字符内定为7
位数域的PDP-10系统的反抗。注重对中断同步代码不应拒收，因为它们已
经被系统过滤，永不会出现在用户输入缓冲器内。
5） 因为存在答应包含待发送中断同步字符的用户信息配额不足的可能性，必
须保留现有的INR/INS机制。当一个中断同步字符进入文本流的时候，应
该发送一个INS控制信息。外部主机在收到信息的时候，附加的进程应该
被立即挂起，并扫描相关的输入流。假如可能，所有到中断同步字符的输
入应被放如缓冲器等待挂起进程处理。一旦发现同步字符，流应被转换到
新激活的监控进程。假如不可能将所有用户进程的输入存入缓冲器，则可
将其丢弃，并由监控进程向用户发送出错信息。任何一种事件都必须保证
输入被销毁，且消息缓冲器被释放，以便发送未处理的字符消息。
6） 当一个中断同步字符先于匹配INS被收到时，用户进程应被挂起，NCP在
进一步处理前等候INS消息。
7） 当然，上述讨论的NCP功能可以由一个独立的功能模块表示，如TELNET
进程。假如完成这一步，则NCP的消息体可以是透明的。
注释
这里提出的对第二级协议的更改并不是一个普遍问题，而是出于修正要害错误的目
的，对目前具有NCP设计的一个特定的补丁包。
1） 它仅对7位代码字符流起作用。并不答应对EBCDIC，ASCII-8或更大的字
符集进行扩展。尽管作者知道这一概念意味着关闭连接，但并没有对不包
含字符流的进程则规定任何解释。
2） 它要求系统扫描来自可中断连接的所有数据。这意味着，当连接建立起来
的时候，必须告知接收主机扫描工作已完成。隐式或显式的方法都是可采
用的。
3） 这一技术对在一个消息体内丢失字符边界的情况并无法处理。同时，它允
许不包含匹配同步字符的INS控制消息，反之亦然。
4） 得到INS或包含中断同步字符的向远程主机发送的文本信息也许不大可
能。可能的原因包括用户控制台错误，本地主机故障，网络故障，控制链
阻塞，配额不足等。在这些情况下，远程过程可能进入死循环。
对当前NCP协议的小改动不能够满足对于中断同步问题唯一全面的那些避免上述
难点的解决方案的需要。假如没有提出更加简单的解答，它们的执行就必须推迟到下一
轮大的设计修订工作来完成。
[本RFC文档由GertDoering于97年4月]
[编为机器可读形式以便录入RFC在线档案]
