介绍
ARPA（高级研究计划局）网络的软件部分地存在于IMP（接口消息处理机）和独立的主机中。BB&N指出IMP上的软件并且表示主机团体有责任就主机的软件达成一致。
1968夏，四个最初站点的代表们碰了几次面以讨论主机软件和网络的最初实验。在秋天和冬天的会晤后，形成了一个以Utah的SteveCarr,SRI的JeffRulifson和UCLA的SteveCrocker为首的三人工作小组。随后的会议在三月底的最后一个星期，地点是Utah。同时出席的还有RSI的BillDuvall，他后来开始和JeffRulifson一起工作。
在完全独立的情况下，UCLA的GerardDeLoche开始了主机-接口消息处理机（HOST-IMP）接口的工作。
在这儿，我列举出达成的一些共识和面临的问题。当然不是确定的，希望得到回馈。
I.IMP软件摘要
消息
主机-主机之间传递的一束信息成为消息。一条消息是包括它的头在内长度不超过8080位的流。头有16位，包含以下信息：
目的地址5位
链接8位
跟踪位1位
空闲位2位
目的地址是数字编码，用来表示消息所要到达的主机。跟踪位发信号通知IMP记录消息的状态信息并且把该信息返回到NMC（网络计算中心，NetworkMeasurementCenter,i.e.,UCLA）空闲位未被使用。
链接
链接字段是IMP使用的一种非凡策略以限制某种阻塞。作用如下：在每一对主机之间有32条逻辑全双工连接用来双向传递消息。IMP对这些链接做了一些限制，即在目的地的IMP返回一条非凡的消息之前，该消息称为RFNM（下一条消息请求，RequestforNextMessage），任何一个主机都不能在同一条链接上发送两条连续的消息。这个安排限制了假如发送端主机试图在同一条链接上发送过多的消息会引起另一端阻塞的问题的发生。请注重：由于目的地的IMP没有足够的能力同时处理所有32个链接，这种链接的实现只是在一路或两路链接过载的情况下。所以主机双方必须互相协作。
这些链接有如下基本特征：它们总是起作用并且总是有32条。“总是起作用”是指：IMP随时预备在其上发送另一条消息。在IMP软件中没有会话的开始和结束的概念。既然这样，我们就无法查询一个IMP以获得链接的状态（虽然可能查询IMP从而得到一个链接最近的历史——两者相差甚远）。
链接的另一个基本特征是：不管它们使用与否，总有32条。这是指：每个IMP必须维护18张表，每张表有32个，跟实际的通信无关。
尽管有人对链接的结构有异议，但它很轻易在IMP内部编程实现，而且正因为其简单，因而是组成更复杂结构的一种较好和可行的办法。
IMP传输和错误检查
IMP从主机收到一条消息后，将其分割成一个或几个包。包是IMP和IMP数据传输的单元，长度不超过1010位。传输装置计算生成一个24位的循环校验码并将其添加到要发送的包中。接受装置计算生成校验码，与原始校验码比较。在目的地的IMP将包重新组织成消息的形式。
IMP软件讨论问题
1.链接的规范是一个8位的字段，但为什么只提供了32个链接？
2.主机能够发送消息给它的IMP，请问是如何实现的？
3.IMP的主机能控制RFNM吗？
4.IMP进行代码转换吗？如何控制？
II.主机-主机软件必要条件
简单应用
就象使用任何一个新工具一样，团体的用户需要一段时间才能进行深层次的网络实验并逐渐依靠于。我们的一个目标就是使之对大多数用户来说能在短时间内很轻易地把握。为了这个目标，显然需要提供使用远程主机的能力，就象已经从一个TTY(电报交换机，teletype)终端拨号登录了一样。此外，我们希望拥有这样一种能力，即以不同于模拟TTY的形式传输文件。
高级应用
网络的一个内在问题是每半秒左右必须收到远程主机的响应，不管它如何简单。对于TTY应用，可以使用半双工，本地响应，但这会破坏网络的一些有效性。例如940系统会有非凡的回波。当考虑到图形工作站或其它由远程主机控制的复杂终端，问题会变得尤其严重。因此需要找到合理的解决途径以便象直接连接到远程计算机一样使用比较复杂的装置。
错误检查
SRI的JeffRulifson指出主流软件接口的错误检查是好事情。他指出SRI的一些经验很好地解决了许多无用的争辩和精力的浪费。正因为如此，我们希望能看到主机-主机之间的错误检查。除了检查软件的接口，还需要检查主机-接口消息处理机（HOST-IMP）装置（BB&N声称主机-接口消息处理机装置就象主机内部的寄存器一样值得信赖。我们相信这一点，但还是希望有错误检查）。
III.主机软件
连接的建立
可以想到的最简单的连接是本地主机类似一个TTY并且已经拨号连接到远程主机。考虑到初始化和中断连接的问题，链接0保留以进行主机操作系统之间的通讯，其余31个链接用作拨号专线。
每个主机操作系统必须给它的用户级程序提供一个基本操作来建立与远程主机的连接和一个基本操作来中止连接。当这些操作被调用后，操作系统选择一条空链接，与此同时，通过链接0上发送一条消息给远程主机请求在已选的链接上实现连接。远程主机的操作系统答应并通过链接0上回送一条接受消息。在整个活动中，两台主机选择同一条链接来初始化一个连接，并且几乎在同时发送请求消息，这时会使用一个简单的优先策略：低优先级的主机让位给高优先级的主机，自己选择另一条空闲链接。一种可行的优先方案是根据主机的身份号码来决定优先级的高低。请注重两台主机都是知道请求是同时发生的，但采取了不同的补救行为：高优先级的主机忽略请求而低优先级的主机除了发送一条接受消息还发送一条请求消息。
建立的连接是一种TTY形式的提前登录状态的连接。这意味着远程主机操作系统一开始就把该链接当作是一个刚实现拨号登录的TTY。远程主机发出相同的回应，期待相同的登录顺序，查找相同的中断字符。
大数据量传输
考虑到传送一个大的文件时，TTY担当终端会有两个专门的缺陷。首先，有些字符是非凡的中断字符。其次，由于使用非凡的缓冲技术，而这些技术只适合于定时的低速字符传输。因此定义了另一类连接用来传输文件或比较大的数据量。为初始化该类链接，已建立的TTY形式的链接的两端的用户级程序要求实现建立的文件形式连接与TTY形式链接并行。于是又用到了优先策略：高优先级的主机通过链接0发送消息，低优先级的主机等待消息的到来。用户级程序对此并不关心。空闲链接的选取有高优先级的主机完成。文件形式链接在于不需要搜索中断字符，并且使用适合高数据比率的缓冲技术。
基本操作摘要
每个主机操作系统至少要给它的用户提供如下基本操作。该列表不是必需的但还不充分。
a)主机x初始化TTY形式连接
b)中断连接
c)通过TTY形式连接发送/接收字符
d)初始化文件形式的连接与TTY形式连接并行
e)中断文件形式连接
e)通过文件形式连接发送/接收
错误检查
假设每条消息体带有一个消息数字，位数和一个校验码，这对于IMP来说是透明的。根据1152位计算得到16位的末位进位的和并且循环右移一位。每1152位循环右移的检查和是IMP用来发现消息中的错误。
相近交互
以上描述的基本操作帮助用户把握如何简单的使用远程设备。它们基于网络的错综复杂的应用令人感到困惑。明确地说，我们关注这样的一个事实：即某些站点做了大量的工作来使计算机对复杂控制台作出迅速地响应。至少UCSB的Culler和SRI的控制台是两个例证。（？未翻译：Itisclearthatdelaysofahalf-secondorsofortrivialecho-likeresponsesdegradetheinteractiontothepoint
ofmakingthesophisticationoftheconsoleirrelevant.）
大多数的控制台交互可以分为两个部分，一部分本质上是本地的，立即的和不很重要的，另一部分是远程的，更长，更重要的。举一简单例子，一个控制台的用户操作键盘并且刷新显示屏幕。用户键入一串字符和一个回车，控制台开始处理字符。当键入字符的时候，它们显示在屏幕上。键入删除字符的时候它删除先前的非删除字符。用户键入HELLO<-<-P
为解决该问题，需要为控制台控制生成一门语言。子系统治理员用此种语言（称为DEL）决定终端由哪些组成，它如何响应键盘的输入等等。作为协议初始化的一部分，远程主机发送控制控制台的程序的源语言文本给本地主机。程序由子系统的设计者用DEL编写，但在本地编译。
DEL规范目前还在探讨之中。以下的图例表示了整个时序过程。
A.
/
+-----------++-----------+
终端终端
+-----+-----++-----+-----+
+-----+-----++-----------+
请求连接
UCLA{->通过链路25}SRI
+-+-++-++-++-+-+
OS---+-=I----------I=-+---OS
+-+-++-++-++---+
+-----------++-----------+
主机:UCLA主机:SRI
/
b.已建立链接后和登录
/
+-----------++-----------+
终端终端
+-----+-----++-----+-----+
+-----+-----+"发送头"+-----------+
结束控制"
UCLA{->}SRI___
+-+-++-++-++--+---+/
OS---+-=I----------I=-+--OSNLS+----+---
+-+-++-++-++------+___/
DEL程序
<-____
+-----------++-----------+
主机:UCLA主机:SRI
/
c.接收后并且便宜DEL程序
/
+-----------++-----------+
终端终端
+-----+-----++-----+-----+
Trivial
Responses
+-----+------++-----------+
UCLA{主要响应}SRI___
+--+--++-++-++--+---+/
DEL---+-=I----------I=-+--OSNLS+---+---
头+-++-++------+___/
尾
程序.____
+-----+
OS
+-----+
+------------++-----------+
主机:UCLA主机:SRI
/
讨论问题：
1.假如IMP进行代码转换，校验码会不正确。
2.请求DEL开头和结尾的过程未具体说明。
IV.初步实验
实验一
SRI目前正在修改他们的在线修补系统以便可以被模型35TTY操作，该系统将会成为网络文档中心（NetworkDocumentationCenter）的主要软件组件。TTY的控制用DEL编写。所有的站点都将编写DEL编译器并且在DEL程序中使用NLS。
实验二
SRI将为完整的NLS编写一个DEL开头和结尾，包括图形。UCLA和UTAH使用带图形的NLS。
[ThisRFCwASPutintomachinereadableformforentry]
[intotheonlineRFCarchivesbyCelesteAnderson3/97]
RFC1-HostSoftware
上一篇 IPv6/IPv4协议转换的试验
下一篇 零文本长度的EOF信息