引言

第 3 页。取消标记。改为把所有常规消息都拆成两条消息: 第一条只含首部, 并指明数据随后在第二条 (下一条) 消息中传来。从源主机到其 IMP, 以及从目的 IMP 到其主机, 都要这样做。这样就不必再去搜寻数据的起始位置。做出这一调整后, 还能获得一项额外的简化。如果最大消息长度是网络中所有计算机字长的公倍数 (也许是 2880*2 位), 那么长文件的相继消息就可以原地丢弃, 无需移位。

第 4 页。控制消息应当在_控制套接字_之间收发 —— 而不是经由控制链路。控制链路这一概念造成了一个极其庞大且不必要的特例。

第 5 页。应当鼓励把套接字永久分配给某些网络资源, 并且套接字/资源对应关系的目录应当能在网络某处查到, 也许是在各站点以实体手册的形式提供。

第 6 页。链路除了标识一条连接 (使套接字号不必包含在所有消息中) 以及在 NCP 中简化表查找之外, 并无主机-主机的用途。然而, 由于可能有 512 条编号相同的链路*, 链路对表查找的帮助并不大。而且, 为特定目的地寻找下一条可用链路也非常难看。因此, 我建议把所有目的地的链路总数限制为 n 条 (其中 n = 32、64 或 256, 或某个其他合适的数)。换言之, 一条特定链路在同一时刻只用于一个目的地 (实际上是同一时刻只来自一个目的地, 因为接收方会挑选用于该连接的链路)。这一改动使挑选下一条可用链路变得非常简单, 而且我觉得, 仅凭这一点它也是值得的改动。简化表查找的问题要稍微复杂一些。由于接收方挑选链路, 在 NCP 的接收部分直接把链路用作表的索引是容易的。但在 NCP 的发送部分, 仍然需要哈希表或线性查找之类的办法。这也可以通过以下改动来解决。在 STR 中增加一条由发送方选定的_伪链路_。这条链路随所有非控制消息, 在首部中链路右侧的那 8 位里发送。IMP 必须保留这些位, 并在 RFNM 中一并返回; 接收方必须使用伪链路, 而不是 RET 和 INR 中的链路。在 NCP 接收表 (按链路索引) 中存储伪链路、在 NCP 发送表 (按伪链路索引) 中存储链路, 所需的额外内存肯定少于维护关联表所需的开销。

*目的编号为 9 位。

第 8 页。分配机制对 NCP 的接收部分来说似乎很不方便使用。接收方希望分配量按接收方缓冲区大小的单位来消耗, 而不是按发送方消息的单位 (其长度可能可变)。否则接收方就会面临内存紧凑化的问题。

第 9 页。为使 “cease” 机制生效而新增的不规则消息, 我认为并无必要。发送方可以 (大概用一个 1 位计数器) 跟踪 ALL 和 GVB, 并忽略那些已经收到恢复 ALL 的 GVB 0。这样接收方就不必知道 cease 是否已经发出。

第 15 页。如果我实现一个 NCP, 我会把所有 ERR 都当作 NOP 处理。作为一种差错控制机制, ERR 既复杂又不充分。谁愿意去调试一种只能捕捉因主要机制未经调试而出现的 bug 的复杂机制呢。我愿意提供的一种差错控制机制, 是让接收进程对每条消息都向发送进程发回确认。如果长时间收不到这个确认, 而发送进程一直保存着该消息, 它就可以重发。这种确认能捕捉到在进程/NCP、NCP/NCP、主机/IMP、IMP/IMP 等各层导致消息丢失的差错。目前主机/IMP 接口尤其缺乏有用的差错控制。我不会去操心那些校验和本来就是用来检出的差错。如果丢位和误拾位真的成了问题, 要么给更多接口加硬件, 要么让接收进程在软件校验和不通过时不发送进程到进程的确认。

第 3 页和第 6 页的评论涉及对 IMP 程序的改动。提议一些自己不必再实现的改动, 我略感愧疚。不过, 我相信 Crowther 和 Cosell 会一如既往地抵制糟糕的改动, 同时做出明智的改动。第 9 页的评论则意在避免改动 IMP 程序。

注: 本 RFC 由 Luke Hollins 于 8/99 转换为机读形式, 以录入在线 RFC 存档。