引言

该协议提供了一套缓冲区分配方案。这套方案相当复杂, 因为它需要两套并行的机制。两套机制是否都必要, 并不显然。事实上, 有人提出, 这套方案大概可以用一种略有不同的“请求下一条消息”(RFNM) 构想取而代之。目前, RFNM 是在消息已被重新组装、并已把第一个分组传给主机之后, 由接收方 IMP 发回的。无法保证整条消息都已被主机接受并正确接收; 另外, 主机/IMP 接口的设计允许主机在任何长度的时间内停止从 IMP 接收数据; 由于发回 RFNM 已经解除了链路的阻塞, 发送方外部主机就可能再发来一条消息, 从而挤占 IMP 的内存。另一方面, 主机通常能以高于网络传输速率的速率从 IMP 接收数据, 例如 200k 比特/秒; 因此从 IMP 向主机传送一整条消息的时间约为 1/20 秒, 比消息在网络上的平均传输时延小 10 倍。这说明, 在主机收到整条消息之后再发回 RFNM, 并不会显著增加网络的响应时间。

在这种情况下, 没有理由不让 RFNM 由接收主机作为消息正确接收的确认 (ACK) 发起, 其形式既可以是主机/IMP 消息, 也可以是控制命令消息。这条 RFNM 可以有两种形式

         ACK  (CONTINUE)
or       ACK  (CEASE)

这样就可以为该消息加入某种差错检测冗余, 例如 [DELO 69] 中所建议的校验位。在目前的设计中, 无法保证正文的某一位或若干位没有被改动, 例如因干扰或某个主机/IMP 接口的缺陷而改动。这可能带来严重后果, 例如当该正文被用来更新某个集中式数据库时。另外, 如果用户有办法检测出错误, 却没有办法纠正它, 他就无法要求重发这条消息, 而这条消息在收到 RFNM 时很可能已在发送端被丢弃。事实上, 检测正文中的错误看来不该由用户来做, 而应由 NCP 来做: 用户进程必须尽可能表现得像是在与某个本地的其他进程通信。因此, 由 NCP 发出的第三种 RFNM 可以是:

            NAK(REPEAT)

在没有回复的情况下, 也会启动重发。

由此可见, 做出这些细小的改动看来是值得的: 它们可以让发送主机与接收主机之间采用一种非常简单的点对点传输过程, 从而保证端到端地控制所传输的数据。

它还可以取代内存分配机制: 只有当这条连接上还有空间容纳新消息时, 才发送 ACK (CONTINUE), 和/或当没有更多空间时, 发送 ACK (CEASE); 这正对应经典传输过程中的 WABT [USAS69]; 传输可以由接收端发出的 ACK (CONTINUE) 或 RESUME 恢复。用户进程完全不介入这种内存分配, 因为它是系统 (或 NCP) 的职责: 用户进程只看到自己在一条连接上发送数据的整体速度在变化。IMP 程序按照网络的分布式特性负责数据的路由, 用户和系统 (或 NCP) 都无需关心。在用过这套协议之后, 还可能发现其他改进之处。

最后要注意, 这一方案占用 IMP 内存的时间并不比现行方案更长, 因为需要重发消息的不是 IMP, 而是发送主机。

DELO 69 DELOCHE G.  Implementation of the Host-Host Software
        Procedures in GORDO Network Working Group RFC #11 Aug 1969

USAS 69 Proposed USA standard data communication control procedures
        for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178

注: 本 RFC 由 Kai Henningsen 于 6/97 转换为机读形式, 以录入在线 RFC 存档。