RFC 1 - 主机软件 (Host Software)
网络工作组 (Network Working Group): Steve Crocker
征求意见 (Request for Comments): 1
机构: UCLA
日期: 1969年4月7日
摘要
本文档是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,他们在秋冬季节多次会面。最近一次会议是在3月最后一周在犹他举行的。当时还有来自SRI的Bill Duvall参加,他最近开始与Jeff Rulifson合作。
某种程度上独立地,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是透明的。对于校验和,我们建议使用16位端到端进位和 (end-around-carry sum),在1152位上计算,然后循环右移一位。每1152位进行一次右循环移位旨在捕获IMP消息重新组装中的错误。
更紧密的交互 (Closer Interaction)
上述原语说明了用户如何简单地使用远程设施。它们没有阐明如何进行更复杂的网络使用。具体来说,我们关注的是,在某些站点,已经投入大量工作使计算机对复杂的控制台高度响应。UCSB的Culler控制台和SRI的Englebart控制台至少是两个例子。很明显,对于琐碎的类似回显的响应延迟半秒左右会将交互降级到使控制台的复杂性变得无关紧要的程度。
我们相信大多数控制台交互可以分为两部分,一个本质上是本地的、即时的和琐碎的部分,以及一个远程的、更冗长和更重要的部分。作为一个简单的例子,考虑一个用户在由键盘和刷新显示屏组成的控制台前。用户正在输入的程序累积字符串,直到遇到回车符,然后处理该字符串。在输入字符时,它在屏幕上显示字符。当输入删除字符 (rubout) 时,它删除前一个非删除字符。如果用户输入 H E L L O <- <- P <CR> (其中 <- 是删除,<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),这个名称一直沿用至今。这份文档体现了早期互联网先驱者的合作精神和开放态度。