RFC 1 - 主机软件 (Host Software)
- 状态: 未知
- 发布日期: 1969 年 4 月
- Stream: Legacy
- 勘误: 无勘误
摘要
本文档是 ARPANET 历史上的第一份 RFC, 讨论了主机软件的设计考量。文档涵盖了 IMP (Interface Message Processor, 接口消息处理器) 软件概述、主机间软件的需求、连接建立机制以及初步实验计划。本文档标志着互联网协议文档传统的开端。
目录 (CONTENTS)
- 引言 (INTRODUCTION)
- I. IMP 软件概述 (A Summary of the IMP Software)
- II. 主机间软件的若干需求 (Some Requirements Upon the Host-to-Host Software)
- III. 主机软件 (The Host Software)
- IV. 初步实验 (Initial Experiments)
引言 (INTRODUCTION)
ARPA 网络的软件一部分存在于 IMP 中, 一部分存在于各自的主机 (HOSTs) 中。BB&N 公司规定了 IMP 的软件, 而就主机软件达成一致则是主机组的责任。
1968 年夏, 最初四个站点的代表多次会面, 讨论主机软件和网络上的初步实验。这些会议产生了一个由三人组成的工作组: 犹他大学的 Steve Carr、SRI 的 Jeff Rulifson 和 UCLA 的 Steve Crocker, 他们在秋冬两季多次会面。最近一次会议是在三月最后一周于犹他州举行。最近开始与 Jeff Rulifson 合作的 SRI 的 Bill Duvall 也出席了会议。
在某种程度上独立地, UCLA 的 Gerard DeLoche 一直在研究主机-IMP 接口。
我在此提出一些已达成的暂定协议以及遇到的一些未解决问题。这里所写的内容大多尚未确定, 期待各方反应。
I. IMP 软件概述 (A Summary of the IMP Software)
消息 (Messages)
信息以称为消息 (messages) 的捆绑包形式从主机传输到主机。消息是不超过 8080 位的任意数据流, 连同其头部。头部为 16 位, 包含以下信息:
目的地 (Destination) 5 位
链路 (Link) 8 位
跟踪 (Trace) 1 位
备用 (Spare) 2 位
目的地是消息应发送到的主机的数字代码。跟踪位向 IMP 发出信号, 记录有关消息的状态信息并将该信息发送回 NMC (Network Measurement Center, 网络测量中心, 即 UCLA)。备用位未使用。
链路 (Links)
链路字段是 IMP 用于限制某些类型拥塞的特殊设备。其功能如下。在每对主机之间有 32 条逻辑全双工连接 (logical full-duplex connections), 消息可以在任一方向传递。IMP 对这些链路施加限制: 在目的地 IMP 发回称为 RFNM (Request for Next Message, 下一消息请求) 的特殊消息之前, 任何主机都不能在同一链路上连续发送两条消息。这种安排限制了当发送主机试图在一条链路上发送过多内容时, 一台主机可能对另一台主机造成的拥塞。然而, 我们注意到, 由于目的地 IMP 没有足够的容量同时处理所有 32 条链路, 因此只有当过载来自一两条链路时, 链路才能发挥其作用。主机在这方面有必要进行合作。
链路具有以下基本特性: 它们始终在运行, 并且始终有 32 条。
"始终在运行"意味着 IMP 始终准备好在其上传输另一条消息。IMP 软件中不包含开始或结束会话的概念。因此, 不可能向 IMP 查询链路的状态 (尽管可能可以查询 IMP 关于链路的近期历史 -- 这是完全不同的事情!)。
链路的另一个基本特性是, 无论是否在使用中, 始终有 32 条。这意味着每个 IMP 必须维护 18 张表, 每张表有 32 个条目, 无论实际流量如何。
尽管对链路结构存在异议, 但链路在 IMP 内很容易编程, 仅仅因为其简单性, 可能是比更复杂安排更好的替代方案。
IMP 传输与错误检查 (IMP Transmission and Error Checking)
从主机接收消息后, IMP 将消息分割成一个或多个数据包 (packets)。数据包长度不超过 1010 位, 是 IMP 到 IMP 数据传输的单位。24 位循环校验和 (cyclic checksum) 由传输硬件计算并附加到发出的数据包。校验和由接收硬件重新计算, 并与传输的校验和进行核对。数据包在目的地 IMP 重新组装成消息。
IMP 软件的未解决问题 (Open Questions on the IMP Software)
-
为链路规范提供了 8 位字段, 但只提供了 32 条链路, 为什么?
-
主机应该能够向其 IMP 发送消息。它是如何做到的?
-
主机 (而非其 IMP) 能控制 RFNM 吗?
-
IMP 会执行代码转换吗? 如何控制?
II. 主机间软件的若干需求 (Some Requirements Upon the Host-to-Host Software)
简单使用 (Simple Use)
与任何新设施一样, 在用户社区对网络进行实验并开始依赖它之前, 会有一段使用非常轻的时期。我们的目标之一必须是刺激广泛用户群体的即时和便捷使用。基于这一目标, 提供使用任何远程主机的能力似乎是自然的, 就好像它是从 TTY (teletype, 电传打字机) 终端拨号连接的一样。此外, 我们还希望能够以与模拟电传打字机略有不同的方式传输文件。
深度使用 (Deep Use)
网络固有的问题之一是, 无论多么简单, 来自远程主机的所有响应都需要大约半秒钟的时间。对于电传打字机的使用, 我们可以切换到半双工本地回显方式, 但这会破坏网络的部分有用性。例如, 940 系统有非常特殊的回显。
当我们考虑在远程主机的控制下使用图形工作站或其他复杂终端时, 问题变得更加严重。我们必须寻找某种方法, 使我们能够尽可能地使用最复杂的设备, 就好像我们直接连接到远程计算机一样。
错误检查 (Error Checking)
SRI 的 Jeff Rulifson 指出, 在主要软件接口处进行错误检查始终是一件好事。他指出了 SRI 的一些经验, 这些经验节省了许多争论和浪费的精力。基于这些理由, 我们希望看到一些主机间检查。除了检查软件接口外, 它还将检查主机-IMP 传输硬件。(BB&N 声称主机-IMP 硬件将与主机的内部寄存器一样可靠。我们相信他们, 但我们仍然需要错误检查。)
III. 主机软件 (The Host Software)
连接的建立 (Establishment of a Connection)
我们能想象的最简单的连接是本地主机充当 TTY 并拨号连接到远程主机。在考虑了启动和终止此类连接的问题后, 决定将链路 0 保留用于主机操作系统之间的通信。因此, 其余 31 条链路将用作拨号线路。
每个主机操作系统必须向其用户级程序提供一个与远程主机建立连接的原语 (primitive) 和一个断开连接的原语。当这些原语被调用时, 操作系统必须选择一条空闲链路, 并通过链路 0 向远程主机发送消息, 请求在所选链路上建立连接。远程主机的操作系统必须同意并通过链路 0 发回接受消息。如果两台主机都选择了相同的链路来发起连接, 并且都在基本上同时发送请求消息, 则将调用一个简单的优先级方案, 其中优先级较低的主机让步并选择另一条空闲链路。一个可用的优先级方案就是简单地按主机的标识号对其进行排名。请注意, 两台主机都意识到同时发出了请求, 但它们采取了互补的行动: 优先级较高的主机忽略请求, 而优先级较低的主机同时发送接受消息和另一个请求。
如此建立的连接是登录前状态的类 TTY 连接。这意味着远程主机操作系统最初将把该链路视为刚刚拨入的 TTY。远程主机将生成相同的回显, 期望相同的登录序列并查找相同的中断字符。
大容量传输 (High Volume Transmission)
当我们考虑传输大型文件时, 充当终端的电传打字机有两个特殊缺点。第一是某些字符是特殊的中断字符。第二是通常采用特殊的缓冲技术, 这些技术仅适用于低速逐字符传输。
因此, 我们定义另一类连接, 用于传输文件或其他大量数据。要启动这类链路, 已建立的类 TTY 链路两端的用户级程序必须请求建立与类 TTY 链路并行的类文件连接。优先级方案再次发挥作用, 优先级较高的主机通过链路 0 发送消息, 而优先级较低的主机等待。当然, 用户级程序不关心这一点。空闲链路的选择由优先级较高的主机完成。
类文件链路的区别在于不进行中断字符搜索, 并采用适合更高数据速率的缓冲技术。
原语摘要 (A Summary of Primitives)
每个主机操作系统必须至少向其用户提供以下原语。此列表已知是必要的但不充分的。
a) 与主机 x 建立类 TTY 连接。
b) 终止连接。
c) 通过类 TTY 连接发送/接收字符。
d) 与类 TTY 连接并行建立类文件连接。
e) 终止类文件连接。
f) 通过类文件连接发送/接收。
错误检查
我们建议每条消息在其主体中携带消息编号、位计数和校验和, 这对 IMP 是透明的。对于校验和, 我们建议使用在 1152 位上计算的 16 位端绕进位和 (end-around-carry sum), 然后循环右移一位。每 1152 位的右循环移位旨在捕获 IMP 消息重组中的错误。
更紧密的交互 (Closer Interaction)
上述原语暗示了用户如何简单地使用远程设施。它们没有阐明如何进行更复杂的网络使用。具体来说, 我们关注的是这样一个事实: 在某些站点, 大量工作已经投入到使计算机对复杂控制台高度响应。UCSB 的 Culler 控制台和 SRI 的 Englebart 控制台至少是两个例子。显然, 对于微不足道的回显类响应, 大约半秒的延迟会将交互降低到使控制台的复杂性变得无关紧要的程度。
我们认为大多数控制台交互可以分为两部分: 本质上是本地的、即时的和微不足道的部分, 以及远程的、更长时间的和重要的部分。作为一个简单的例子, 考虑一个使用由键盘和刷新显示屏组成的控制台的用户。用户正在输入的程序积累字符串, 直到遇到回车符, 然后处理该字符串。在输入字符时, 它在屏幕上显示字符。当输入 rubout 字符时, 它删除前一个非 rubout 字符。如果用户输入 H E L L O <- <- P <CR> (其中 <- 是 rubout, <CR> 是回车), 他进行了九次按键。如果这些按键中的每一个都导致发送一条消息, 而该消息反过来又调用对我们显示站的指令, 我们很快就会感到厌倦。
更好的解决方案是让远程程序的前端 -- 即扫描 <- 和 <CR> 的部分 -- 驻留在我们的计算机中。在这种情况下, 只会发送一条五字符消息, 即 H E L P <CR>, 屏幕将在本地管理。
我们建议通过创建一种控制台控制语言来实现这一解决方案。这种语言, 目前命名为 DEL, 将由子系统设计者用来指定终端需要哪些组件以及终端如何响应来自其键盘、Lincoln Wand 等的输入。然后, 作为初始协议的一部分, 远程主机将向本地主机发送控制控制台的程序的源语言文本。该程序将由子系统设计者用 DEL 编写, 但将在本地编译。
DEL 的规范正在讨论中。以下图表显示了操作序列。
A. 链路建立前 (Before Link Establishment)
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ +-----------+ |
| | | | Request connection | | | |
UCLA { | | | -> over link 25 | | | } SRI
| | +-+-+ | +-+ +-+ | +-+-+ | |
| | | OS|---+-=|I|----------|I|=-+---| OS| | |
| | +-+-+ | +-+ +-+ | +---+ | |
| | | | | |
| | | | | |
| +-----------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
B. 链路建立和登录后 (After Link Establishment and Log-in)
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| | | |
| | | |
| | | |
| +-----+-----+ "Please send front"+-----------+ |
| | | | end control" | | | |
UCLA { | | | -> | | | } SRI ___
| | +-+-+ | +-+ +-+ | +--+---+ | | / |
| | | OS|---+-=|I|----------|I|=-+--|OS|NLS| +----+---| |
| | +-+-+ | +-+ +-+ | +------+ | | |___/
| | | DEL prog. | | | | |
| | | <- | | | |____|
| +-----------+ +-----------+ |
| HOST: UCLA HOST:SRI |
\ /
C. 接收并编译 DEL 程序后 (After Receipt and Compilation of the DEL program)
/ \
| +-----------+ +-----------+ |
| | | | | |
| | | | | |
| | terminal | | terminal | |
| | | | | |
| | | | | |
| +-----+-----+ +-----+-----+ |
| |Trivial | |
| |Responses | |
| | | |
| +-----+------+ +-----------+ |
| | | | | | | |
UCLA { | | | Major Responses | | | } SRI ___
| | +--+--+ | +-+ +-+ | +--+---+ | | / |
| | |DEL |---+-=|I|----------|I|=-+--|OS|NLS| +---+---| |
| | |front| | +-+ +-+ | +------+ | | |___/
| | | end | | | | | | |
| | |prog.| | | | | |____|
| | +-----+ | | | |
| | | OS | | | | |
| | +-----+ | | | |
| | | | | |
| +------------+ +-----------+ |
| HOST: UCLA HOST: SRI |
\ /
未解决的问题 (Open Questions)
-
如果 IMP 进行代码转换, 校验和将不正确。
-
请求 DEL 前端的程序尚未指定。
IV. 初步实验 (Initial Experiments)
实验一 (Experiment One)
SRI 目前正在修改其在线检索系统, 该系统将成为网络文档中心的主要软件组件, 以便可以使用 35 型电传打字机操作。电传打字机的控制将用 DEL 编写。所有站点将编写 DEL 编译器并通过 DEL 程序使用 NLS。
实验二 (Experiment Two)
SRI 将为完整的 NLS (包括图形) 编写 DEL 前端。UCLA 和犹他大学将使用带图形的 NLS。
注: 本 RFC 由 Celeste Anderson 于 1997 年 3 月转换为机器可读形式, 以便录入在线 RFC 档案。
相关资源
- 官方文本:
https://www.rfc-editor.org/rfc/rfc1.txt - 官方页面:
https://datatracker.ietf.org/doc/html/rfc1
历史意义
RFC 1 是互联网历史上的第一份 RFC 文档, 标志着 ARPANET 和现代互联网协议文档传统的开端。由年轻研究生 Steve Crocker 撰写, 他谦逊地将这些文档称为"意见征求稿 (Request for Comments)", 这一名称沿用至今。本文档体现了早期互联网先驱者的协作精神和开放态度。