跳到主要内容

引言

我们认为 Meyer 提案 (Note #46) 是目前为止最可接受的, 理由正如他所列举的那样; 即简单, 足以满足网络大多数计划中的用途, 易于实现, 并且可以扩展。它并未涵盖最近提出的所有内容, 不过我们确实同意所提出的各项内容, 并且认为那些缺失的特性大概不值得为之争执, 从而拖延规范的制定。

我们对 Note #47 中提出的七个问题作如下评论。

  1. 我们同意 Steve 的看法, 即动态重连在以后会因网络更复杂的用途而有其必要。我们也同意 Project MAC 的人的看法, 即它在初期并不必要。在有了一些网络使用经验以及明确的使用需求之后, 动态重连可以做得更好。

  2. INT 易于实现, 而且有实际用途。

  3. 我们赞成加入实例标记标识符这一子字段。我们认为两种情况都需要; a) 多个进程应当显得无法区分, 以及 b) 拥有多个进程的某个用户必须将它们区分开。那些不应区分进程的程序部分, 直接忽略实例标记即可。Tom 建议使用用户号子字段的一部分, 这只不过把子字段的合计长度从 32 位减少到 24 位; 问题依然存在。

  4. 我们既不同意 Steve 也不同意 MAC 的意见, 即不应对所传输的数据施加特殊结构。我们更倾向于 E. I. Ancona 在 Note #42 第 1 页提到的 "message data type"。其用法的一个例子在 Note #39 第 2 页中被引用过, 即 transmit 与 broadcast。关于标准字符集, 我们强烈支持从一开始就采用一种字符集, 尤其是 ASCII。我们观察到, 大多数站点此前都建议过 ASCII。有谁反对吗?

  5. 字边界对齐比双重填充更有吸引力。

  6. Steve 关于对 RFC 作短期排队的建议, 作为一种选项是可以接受的。

  7. 我们支持 Note #46 中的 UCC, 理由主要有三:

    1. 一般而言, 用户不应当知道他想要通信的那个进程的远端套接字编码。

    2. 额外的双工连接可以对进程行为提供一些监视性控制, 也许可与中断过程结合使用。

    3. 其他被提议的方法大多需要排队。

    我们认为必须有一个标准 UCC, 但也鼓励并行的实验性 UCC。

我们还要就 Note #46 补充两点在 Note #47 中没有重述的评论。

BLK 与 RSM 比以前的建议更为直截了当, 而且它们并不否认在给定链路上进行多路复用。关于链路的使用, 我们引用 Bob Kahn 给出的一个例子: 某个中间 IMP 宕机并吞掉了某人的 RFNM。这不应需要重连。

在 Note #46 第 6 页, 关于 UCC 有能力关闭与死进程的连接的陈述取决于具体安装。在我们的特定情况下, NCP 会直接得到进程失败的通知, 因为所有进程 (包括 NCP) 都必须通过特定的软件接口进行通信。

JFH:hs

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