引言

要让经由 Network 的通信显得只是输入/输出的一种特例——至少就用户编程而言——有许多好的理由，也许还有一两个坏的理由。例如，哈佛在实现 HOST-HOST 协议与 Network Control Program 时所采取的做法，就是把每条链路都当作 PDP-10 术语中的一个“逻辑设备”。建立连接类似于本地设备分配，而经由链路的通信将使用标准的系统输入/输出 UUO。这使得现有程序无需修改即可与 Network 配合使用——至少在与别的 PDP-10 打交道时是如此。

然而，这只能带我们走到这一步。“逻辑设备”这一概念在 PDP-10 上并不存在；它在 IBM 360 上存在（我这里说的是操作系统——用户程序接口这一层次）。此外，在缺少要求整数、实数等采用固定表示法的 Network 标准的情况下（我会反对这样的标准），任意一对用户进程都必须达成某种本地约定，并且其中一方或双方必须在必要时承担数据转换的负担。任何标准协议都应当允许此类约定得到表达，并且至少应当容纳使这些约定在实践中得以运作所需的最少量控制信息。最后，我们必须指出，IMP-IMP 与 HOST-HOST 协议并不提供这样一种检查：用户进程所请求的动作是否真的由其他进程完成；这类问题一向被认为应在 USER-USER 协议一级处理。

本提案只打算在一定程度上应对上述三类问题。要说明这个程度，最好的办法是列出我用来评判任何 USER-USER 协议提案的判据：

（逻辑）_记录_这一概念应当存在，而_消息_这一概念应当被抑制。（对 FORTRAN 程序员来说，用一条不带 FORMAT 的 WRITE 语句写出的东西就是一条记录；对 OS/360 机器语言程序员来说，PUT 写出的就是一条记录。）
应当能够以这样的方式在 HOST 系统和/或库例程中实现该协议：使现存的用户程序无需修改程序即可访问 Network 中任何位置的文件。（至少在初期，这一能力必须限于同一类型的 HOST 系统。）
该协议应当能够在任何 HOST 系统中于 SVC 或 UUO 一级实现（不一定要求已经实现）。应当无需了解所涉及的对端 HOST 的具体特性。

应当指出，上述内容意味着某些用户程序必须了解对端 HOST 的性质——至少在第二条判据不成立的每一种情形下都是如此。随着我们在目前发生这种失败的情形上取得进展（或者放弃这些情形），容纳系统差异的负担将转向协议（即 HOST 系统）中的实现，或者默认地转向用户程序。

十分显然，今天提出的任何提案，就其“解决”终极问题的程度而言，都应当受到怀疑。要有多少雄心，纯粹是口味问题。在现阶段，我宁愿尝试某种我相信能被我们所有人使用（因而值得去做）、在解决近期问题上走得足够远、容易做到、并且在长远看来有希望存活下去的东西。下文我将描述提案本身，并希望为它的各个部分给出恰当的动机论证。然后我会勾勒我们在哈佛为 PDP-10 所做的具体实现，并描述我们打算如何把它应用于一个具体场景：把文件存放在 Network 中的其他 PDP-10 上。