简单的 NCP 协议( 四 )


STOP
STOP消息告诉外部NCP在特定的链路上暂时停止发送消息 。不像CEASE-ON-LINK,在STOP消息生效前发送多少消息是没有保证的 。当地NCP收到该消息后就会发送一个查询消息:
LINQ
应答消息会给出链路外部端机中的箱子数 。LINQ消息不断被重复发送,直到外部端机中的箱子数与当地箱子数之和和链路带宽相等为止 。此刻链路中没有传送消息,链路的两端已经被同步了 。参照这个同步点,就能识别出每个消息 。例如,当地NCP能发送一个控制消息来要求发送第三个消息以后的所有消息 。外部NCP能识别出具体的消息,并且重新发送 。一旦所有的错误被恢复,一个格式与STOP类似的START控制消息就会发送给外部NCP,正常的操作就会被恢复 。整个错误恢复过程能够对接受、发送用户进程透明 。
人们希望较大的主机受最坏情况下的存储分配要求影响不大 。于是它们宁愿分配比自己实际拥有的缓冲数量大的缓冲,并且根据概率作应答来保证大部分时间能正常工作 。只要对外部主机透明,那么这种方法是很好的 。只要NCP本身没有被捕捉,协议是答应NCP谎报其存储分配的 。在侦查显得很紧迫的情况下,将需要实现以下的控制机制 。这些机制以力量的大小顺序列出,其中力量越大者越靠后 。
a)不发送任何用户RFNM消息或者其它的短消息 。使用更长的消息减少缓冲需要是一种很好的尝试 。
b)尽量不从IMP接收任何的新消息 。将企图发送消息的当地进程阻塞 。
c)发送DEC消息来释放缓冲空间 。分配给RFDL的缓冲不要超过一个,还要拒收INC消息 。
d)假如消息等待用户处理,就在消息中伪造错误 。只有在发送消息的主机上实现了错误恢复机制的情况下才能采用这种方法 。这种方法将会释放缓冲区的空间,答应用户以后恢复 。最后的这种措施被公认为最后的拯救方式,但是它应该有足够的能力去控制任何紧急情况 。
作者希望以上的协议能成为RFC54及其附件的一种有吸引力的实现 。虽然该协议提出比较晚,但是它的实现不需要很多的功夫 。它足够简单,实现起来会很快 。假如被采用,在夏天结束前当前的大部分站点就能实现智能式的通讯 。


推荐阅读