II. 主机停机与恢复

主机停机之后再试图重启时, 可能出现严重的问题。可以很容易地区分两种情形。第一种是“软”崩溃, 即系统事先已得知机器将要停机; 有足够的时间执行恢复前的处理流程。另一种情形可称为“硬”崩溃, 通常由系统故障导致, 一般几乎没有预警; 更重要的是, 机器在恢复后的状态往往难以预测。

当主机从硬崩溃中恢复回来时, 网络将处于未定义的状态。NCP 的数据结构很可能已被破坏或失去意义。网络已经宣告该主机死亡——但只对那些试图传输数据而被拒绝的进程如此宣告。崩溃主机唯一的选择是重新初始化它的表。那么, 对方主机又有哪些选择呢？

我们希望提议增加两个控制命令: RESET（RST）与 RESET REPLY（RSR）。二者都只由一个操作码构成, 不带任何参数。收到 RST 后, 主机应立即终止与发送主机的所有连接, 但不发出任何 CLS。RST 的接收方还应注意到 RST 的发起方仍然存活, 并随即向发送方回送一个 RSR。主机收到 RSR 后, 就应记下回送方主机仍然存活。（如果主机在发现另一台主机停机后立即关闭所有相关的表项, 也可以部分模拟 RST 的功能。）

这样, 在硬崩溃之后, 所有连接及连接请求都被终止。RST 还向所有其他主机宣告我们重新存活, 并且每一个正常运行的 NCP 都会回送一个 RSR。由此可以方便地组装出一张主机存活表（见 NWG/RFC #55）, 连接的建立也可以恢复。

当我们试图让网络——其中可能仍在传输崩溃之前生成的消息——与一台已完成初始化的 NCP 保持同步时, 也会出现相关的问题。我们缺乏解除链路阻塞、丢弃消息等所需的设施, 而本提案将使这些设施成为必需。与 BBN 的进一步交流应能解决这些困难。

与“软”崩溃相关的问题则远没有那么紧迫, 而且它们要求更精致（也就是更复杂）的解决方案。我们在网络上的初步实践表明, 一个良好的初始化与恢复协议远为必要。

本文提出的许多想法, 是在与 Steve Crocker 和 Jon Postel 的交谈中萌芽和/或定型的。我们还要感谢 UCLA 的 Jim Balter 和 Charles Kline, 他们为协助开发伪 Algol 程序投入了大量精力, 该程序是我们近期许多文档的前身。

注: 本 RFC 由 Katsunori Tanaka 于 1998 年 2 月转换为机器可读格式, 以收入在线 RFC 档案。