跳到主要内容

一种可适配的机制

我们希望让那些当初并非为网络而规划的问题程序适配网络使用，这些程序无疑不会轻易屈从于它们被纳入时既有的网络标准。 这种不兼容问题与主机硬件各不相同一样，都是支撑网络的研究中同样根本的一部分。 要求每个这样的程序都配备庞大的前端并不是一个合理的目标。 我们把网络看作这样的混合体：a) 提供服务的主机；b) 把终端接入这些服务的寄生主机；c) 兼具服务使用者与服务提供者身份的一系列主机。 要求每个寄生主机为其用户所需的所有服务处理各不相同的协议与数据格式，并不是一个合理的目标。 结果就是希望通信却说着不同语言的那些程序与终端。

解决协议与数据格式问题的一种途径，是提供一种可适配的机制，供程序与终端用来方便地访问网络资源。 ARPA 正在 Rand 资助 Adaptive Communicator Project，这是一项研究努力，旨在考察一种可教的前端进程，以便在人与其程序之间提供接口。 正在探索的终端设备种类包括语音、手写板、精密图形终端等。

Adaptive Communicator 看起来非常有前景，但还要过一段时间才能就绪。 Rand 的网络项目选择走可适配的路线（_而非_自适应，即没有启发式、没有自学习）。 我们的问题是让 Rand 的研究人员方便地接入网络，假定他们同时有不同的应用，需要不同的程序协议与数据配置。

协议与数据格式将分开描述，以说明我们所说的适配是什么意思。 协议是“系统调用”的序列，它们对应于 NCP 命令（并导致 NCP 发出这些命令）。 数据格式是对常规消息内容的描述，对 NCP 而言没有意义。

Form Machine（适配数据格式）​

为使读者了解背景，Form Machine 属于有限状态机这一类，它识别一种_正则_表达式_，在我们的情形中，这些表达式描述数据格式。 不过，该记法针对的是特定的描述，因此就我们的目的而言，它可以比正则表达式的语言更简洁。

Form Machine 是一个实验性软件包，它把数据格式需求各不相同的多种程序与终端耦合起来。 我们设想把 Form Machine 安置在各个提供服务的主机上（以减少网络流量）。

为了检验 Form Machine 这一构想，我们正在实现两个可由 IBM OS 调用的子程序；一个编译器，用于编译描述各种数据格式形态的语句；以及一个执行器，用于在数据流上执行已编译的格式。

为了描述 Form Machine 的测试，有必要提到 Rand 的另一个程序——Network Services Program（NSP），它是一个多路访问程序，把 Network Control Program 分别与任意程序和 Video Graphics Consoles 对接。（我们把终端看作只是另一个接口不同的程序，即每行 # 个字符、每页 # 行、独特的硬件特性、它被投入的应用等。） Form Machine 的子程序可以在控制台或程序的指示下由 NSP 调用。

在操作上，控制台用户为其将要使用的数据格式命名并加以规定。 这些格式被编译并存储起来以备后用。 在将来某个时刻，当用户希望建立网络连接并传输数据时，他把已命名的格式动态地关联到端口的两侧——端口是一个以符号命名的网络全双工连接。 传入或传出的数据流按编译后的格式执行，随后被转换后的数据流分别传给控制台/程序或网络。

我们 Form Machine 记法的语法细节对整个网络社群而言并不重要。 不过，该记法的各项规定值得关注。 它最终将涵盖高性能 CRT 显示器、TTY 以及任意文件结构的描述。 为检验其可行性，正在实现这类特性的一个子集。

当前版本具有以下特性：

  1. 字符代码转换（即十进制、八进制、十六进制、8 位 ASCII、7 位 ASCII、EBCDIC 和二进制）。

  2. 多个中断字符串（许多终端有多个终止信号）。

  3. 字面量的插入（主要用于显示信息的呈现）。

  4. 跳过或删除任意字符串（用于移除记录序号等不应显示的内容）。

  5. 记录序号的生成。

  6. 字符串长度的计算与插入。

  7. _任意_的数据字符串长度规定，例如“一个十六进制字面量字符串，后跟_任意_数量的 EBCDIC 字符，再跟一个中断字符串，……”。

  8. 网络消息的拼接，即在未完成的数据字符串上执行已编译的格式。

  9. 数据字段的换位。

  10. 针对单行与多行消息的显式与不定乘数因子。

尚未实现、但若成功将会加入的特性包括：

  1. 面向图形的描述。

  2. 通用数字转换。

  3. 条件语句。

  4. 指针能力。

Protocol Manager（适配 NCP 命令序列）​

NSP 允许终端用户与程序在 NCP 协议层上工作；即 LISTEN、INIT 等。 它还允许它们传输并处理只对它们自己有意义的信息。从系统程序员或探索性观点来看，这种“动手”的做法是可取的。 然而，对于反复使用某个给定远程程序的研究人员，可取的是允许他定义、存储、检索并执行“现成的”协议序列，从而省去费力的“握手”。

我们目前正在规定 Protocol Manager，作为 NSP 的一个模块，它将允许对 NCP 命令序列进行上述操作。 该模块的特性包括：

  1. 这些序列可以包含“断点”，以允许控制台用户动态地注入任何上下文所需的信息。

  2. 命令的参数可以包含若干记号，其值由远端在协议对话期间提供。例如，在 Note #66 中，由服务器提供的套接字编号将由用户在后续的 RTS、STR 命令中使用。