附录: 一个应用
目前只存在一个资源共享计算机网络, 也就是前面提到的 ARPA 网络。在本附录中, 我希望说明本附注所述的系统可以应用到 ARPA 网络上。关于 ARPA 网络内的进程间通信, 已经有一批可观的工作。这些工作由几个几乎彼此独立的部分组成: 主机/IMP 协议、IMP/IMP 协议, 以及主机/主机协议。在下文的讨论中, 我假定读者熟悉这些工作。[参见参考文献 [1][3][4][10][11]; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822; 以及 ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59。]
在 ARPA 网络中, 正确地从一个站点向另一个站点传输比特完全由 IMP 负责, 建立进程间连接则完全由主机负责。主机和 IMP 都参与其中, 并各承担一点流量控制和消息定序的责任。把我所描述的进程间通信系统应用上去, 会使我做出不同的责任划分。IMP 仍然继续正确地从一个站点向另一个站点搬运比特, 但网络控制器也驻留在 IMP 中, 而流量控制则完全掌握在主机中运行的进程手里, 尽管它们也许要使用 IMP 提供的机制。
IMP 为主机提供形式稍有改动的 SEND、RECEIVE、SEND FROM ANY、RECEIVE ANY 和 UNIQUE 操作, 并且还维护会合表, 包括在必要时迁移 SEND 端口。
也许最容易的做法是把这五种操作再逐一走一遍。
SEND. 主机把一个 SEND 端口编号、一个 RECEIVE 端口编号、会合站点以及一个缓冲区规格=20 (例如起点与终点、开头与长度) 交给 IMP。该 SEND 被发送到会合站点, 通常就是本地站点。当匹配的 RECEIVE 到达时, 主机得到通知, 得知刚刚到达的那条接收消息的 RECEIVE 端口。这个端口编号足以标识发出该 SEND 的进程, 尽管某个具体的分时系统可能必须维护一些内部表, 把这个端口编号映射为有用的内部进程标识符。与此同时, IMP 会开始向主机索要数据缓冲区的特定数据块。这些数据块将在 IMP 的 RFNM 控制允许的范围内被发往目的地。如果长时间收不到 RFNM (意味着某条消息在网络中丢失), 主机会被要求再次提供同一数据块 [这同时也使得消息可以被 IMP 网络完全丢弃, 如果这种做法在某些时候有用的话], 但此时主机有权选择中止这次传输。在一次传输进行期间, 主机可以请 IMP 执行其他操作, 包括其他 SEND。对一对已经处于传输中的端口再次发出 SEND, 会被记录下来, 该 SEND 将在第一次传输完成后立即生效。第三次相同的 SEND 会导致向主机返回一条错误消息。如果某个 SEND 超时, 也会返回错误。
RECEIVE. 主机把一个 SEND 端口、一个 RECEIVE 端口、一个会合站点以及一个缓冲区描述交给 IMP。该 RECEIVE 消息被发送到会合站点。当某次传输的数据块到达该 RECEIVE 端口时, 它们连同 RECEIVE 端口编号 (也许还有 SEND 端口编号) 一起被交给主机, 同时告知主机应把数据放在其输入缓冲区的什么位置。当 SEND 缓冲区的最后一部分被交给主机后, 它就被相应地标记, 主机于是能够察觉这一点。对同一对端口允许再次发出 RECEIVE。第三次则会向主机返回一条错误消息。本段和上一段所述的机制使一对进程总能有“一次传输正在进行、下一次传输已经挂起”的状态, 因此不会损失任何效率。另一方面, 每一次传输之前都必须有一次进入指定缓冲区的 RECEIVE, 从而提供了完整的流量控制。(可以设想, RECEIVE 消息在奔赴会合站点的途中, 顺带分配一段网络带宽。)
RECEIVE ANY. 主机把一个 RECEIVE 端口和一个缓冲区描述符交给 IMP。其工作方式与 RECEIVE 相同, 只是假定本地站点就是会合站点。
SEND FROM ANY. 主机把 RECEIVE 与 SEND 端口、目的站点以及一个缓冲区描述符交给 IMP。IMP 尽快地索取并传输该缓冲区。针对不存在的端口发出的 SEND FROM ANY 会在目的站点被丢弃。
RFNM 与某个特定数据块的传输绑定, 正如确认现在与数据包绑定一样, 它们起着相同的作用。如果主机允许 IMP 通过前述那种"IMP 告诉主机应把某个缓冲区数据块放在何处"的方式, 在主机中重组缓冲区, 那么同一个缓冲区的各个数据块就可以并行传输, 并且可以同时有若干个 RFNM 处于未完成状态。数据包的重组仍在 IMP 中进行。
还有最后一种操作必须由 IMP 提供 —— UNIQUE 操作。维护唯一编号有许多方式, 这里给出三种。第一种可能是: 由主机最初向 IMP 索取这些唯一编号, 然后由主机动用它所掌握的任何手段, 保证当前由本地进程和程序持有的唯一编号的完整性。在这种情况下, IMP 会提供一种把一个唯一编号从一个主机发送到另一个主机的方法, 并为该编号在新站点上的身份作担保。
第二种方式是把唯一编号直接交给正在使用它们的进程, 依靠进程的非恶意行为来保全这些唯一编号, 或者在万一发生意外时, 依靠发起一次传输所必需的两个口令 (SEND 和 RECEIVE 端口)。如果唯一编号以非顺序的方式发放, 而且长度尚可 (比如说 32 位), 危险就很小。
在最后一种方式中, 端口编号里包含一个用户标识, 各个分时系统则保证这些标识位的完整性。这样一来, 一个进程虽然无法确知正在向它传送的是正确的端口, 却可以确知正在传送的是正确用户的某个端口。这就是 W. Crowther 所提出的所谓虚拟网络 (virtual net) 概念 [3]。
杂项内容。把这些操作放进 IMP, 使得主机/主机协议程序只需编写一次, 而不像目前在 ARPA 网络中那样要编写许多次。如果为了缓解通信子网中的拥塞问题而认为有必要, IMP 可以暂停某个特定主机的传输 (办法是一段时间内不去索要下一个数据块)。而且 IMP 可能知道一次 RECEIVE 到达某个特定其他站点大约需要多长时间, 从而可以在某个进程的消息即将到来之前不久, 提醒主机唤醒该进程。
Note: This RFC was put into machine readable form for entry into the online RFC archives by Katsunori Tanaka 4/99.