摘要

  • James E. White 在 RFC 707 中提出通用的过程调用协议和运行时，希望减少 ARPANET 各应用协议反复处理命令、参数与答复的负担。
  • 文件记载了面向运行 TENEX 的 PDP-10 原型，也强调远程调用依然要经过进程间通信，成本高于本地调用，而且并非所有通信都适合过程调用。

一次改名为何要走两步

FTP 的改名操作把这个问题变得具体。1973 年的规范要求发送 RENAME FROM，再发送 RENAME TO。用户想表达的是一次改名，协议却要求客户端和服务器按顺序完成一段命令与答复。远程作业提交也有自己的命令流和回复；作业尚未结束时，服务器还可能报告进度。每种应用都在描述业务操作之外，重复承担一套对话规则。

RFC 707《网络资源共享的高级框架》正是从这层重复工作切入。作者 James E. White 当时在斯坦福研究院（SRI）的增强研究中心工作。文件并未主张取消消息，而是提出把共同的请求、参数、结果和应答处理方式放进更通用的层，让应用不必为每一种服务重新拼出命令语法。

调用语法下面仍是消息

方案中的过程调用协议（PCP）以 CALL 和 RETURN 配对，使用事务标识关联请求与结果，支持参数、返回值以及多个未完成请求。每个安装点的运行时负责封装调用、与远端交换消息，再把结果交还调用方。设计还允许阻塞或非阻塞调用，以及远端服务向客户端回调。

这改变的是程序的表达方式，不是网络的工作方式。程序可以围绕一个过程及其参数来组织逻辑，运行时再处理重复的命令往返；但消息仍需发送、匹配和等待。PCP 也没有把所有通信都塞进过程调用。文件保留较低层的进程间通信接口，供不适合这种形式的交互使用。

一台 TENEX 主机的证据边界

RFC 707 自述，增强研究中心从 1974 年 7 月开始研究，经过约 12 个月和三轮设计，最终为运行 TENEX 的 PDP-10 设计、编写说明并实现了运行时原型。文件称 TENEX 运行时实现了该规范，并提供了文中及附录所述能力的超集。这比单纯提出设想更具体：它指向一个明确的平台和项目方报告的实现。

证据也止于这里。它不能证明不同厂商的主机已经互通，不能给出部署规模或采用数量，更不能代表整个 ARPANET。RFC 编辑部如今把 RFC 707 标为 Legacy、状态 UNKNOWN；IETF Datatracker 说明它早于正式来源记录，不属于今天 IETF 标准流程中的正式成果。这些现行标签同样不能推算 1975 年有多少人使用过原型。

运行时不能抹掉路程

RFC 707 对自己的抽象提出了限制：本地过程调用很便宜，远程调用则不同，因为它必须借助进程间通信消息。程序员需要判断何时采用这种便利形式；分布式程序可以异步继续；某些有用的网络交互也无法自然表示成过程调用，因此底层 IPC 必须继续开放。

这段提醒比“网络像本地机器”这样的后见概括更忠于史料。RFC 707 记录的是一个有限而可检验的尝试：将重复的请求与回复机制放进通用运行时，在 TENEX 上做出原型，同时不把距离、异步性和通信成本藏起来。现有来源没有证明它成为后续 RPC 系统的起点，也没有说明它曾在 ARPANET 普遍部署。

来源

  • James E. White，RFC 707，《网络资源共享的高级框架》。
  • RFC 编辑部的 RFC 707 记录；IETF Datatracker 的 RFC 707 状态页。
  • RFC 542：FTP 命令和改名序列；RFC 360：远程作业提交的命令、答复与进度报告。
  • RFC 592提供 SRI 早期资源共享讨论的背景；恒路的第 65 篇笔记只是后来的编辑视角，不是证明 1970 年代意图或采用情况的史料。