介绍
在游说了网络共同体之后，传输协议故障清除委员会于1971年3月8日至9日
在加利福尼亚州立大学洛杉矶分校举行了第二次会议。委员会第一次略微扩大
会议的结果以RFC102号文件的形式备案。委员会同意就1号文件中的协议进行
个别的修改，所涉及的修改如下。
每次会议上，委员会很快地处理除了一个突出课题之外的所有的主题。第
一次会议中，大部分时间被用来考虑中断机制，并且讨论结果被概括为RFC102
号文件。在第二次会议上，委员会花费几乎所有的时间讨论字节的概念，这一
讨论结果在修改列表之后加以总结。
本RFC文档将全部取代RFC102号文件，并且作为1号文档的官方修订。1号文
档的修订版将被简单地述及，并且与这里列出的修改列表合并。
网络控制程序的制订人将尽快合并这些变动。网络控制程序的制订人还将
估计这些网络控制程序将于何时预备就绪，并将上述推算向SteveCrocker或他
的秘书Byrnakristel通报。
修改
1字节
迄今为止，一个联接一直是一个位流。从今以后，它将是一个字节流，具
有字节长度S，在每一消息报文的STR命令中给出。该字节长度满足约束：
1<=S<=255.
某一联接字节长度的选择是一个第三级协议的问题，但是字节长度在此联接
的使用期限内是一个常数。每一条消息报文必须包含整数个正文字节（见下文）。
2报文格式
报文格式被转换为如图１所示的格式。
字段S和C分别代表字节长度与字节数。
字段S有8位，必须与创建联接的STR中声明的字节长度相匹配。字段C是16
位长的，它说明该消息报文中正文部分字节的数目。字段C中的零值容许存在，
但无做任何使用。
M1与M2字段长都必须为8位，且必须包含零。字段M3必须为存在，且必须全
部为零。字段M3可以用来向一个字的边界填写消息报文。并随后填充补全。
32bits
<--------------------------------->
+-----------------------------------+
leader
+--------+--------+-----------------+
M1SC
+--------+--------+-----------------+
^
M2
+--------+
Text
////
+--------+
M3
v
+-----------------+--------+--------+
10---------0<--Padding
+-----------------+
TypicalMessage
图1
正文字段由C字节组成，每个字节长S位。该正文字段开始于消息报文的开始
点72位之后。
子网必须能够将字节流分割为消息报文。消息报文边界上并不附加任何语
义成分。非凡地：
1. 对于C而言，尽管一个具有零值的消息报文是合法的，但其用尽了资源
分配，且是无意义的。（见后文的流控制）
2. 接收器并不期望与消息报文边界同步的第三级控制信息。非凡地，假如
记录被声明为对联接进行定义，则接收器必须等候多记录或一个消息报
文中的记录碎片。（然而控制信息遵守非凡的规则，见下文）
3消息报文数据类型
数据类型并不作为第二级协议的一部分而加以定义。
第三级协议则可包括该定义。数据类型不可能在消息报文边界同步。
4重置与重置应答
添加了一对新的一位控制信号RST（reset）和RRP（resetreply）。RST
信号被解释为一个用于由发送给RST的主人产生的所有存在的入口的网络控制程
序表的信号。主机接收RRP信号表示对RST信号的确认。发送RST信号的主机可
以在收到一个RST信号或一个应答RRP信号之后继续请求联接。假如在第一个主
机之后出现第二个主机，则返回一个RST信号。
5流量控制
流量控制方法从两方面发生了变化。首先，中止机制被停用。10HI和11HI
消息报文将不再被辨别为Imps，并且该Imps也将不再生成10HI、11HI或12HI消息
报文。
其次，分配机制此刻处理二个量：位与消息报文。接收器给这些量中间的
每一个分别地分派。发送器与接收器必须为消息报文保留一个16位无符号计数
器，并为位保留一个32位无符号计算器。
发送消息报文时，发送器从该消息报文计数器减一，并且将位计数器的正文
长度也减一。接收器在收到该消息报文的时候同样地递减其计数器。假如任何
一个计数器将要递减至低于零，则禁止发送器继续发送。同样地，也禁止接收
器生产当前消息报文的大于2**16-1的分配，以及超过2**32-1的当前位的分配。
消息报文的正文长度是S（字节长度）和C（字节数）的乘积。如报文格式
内所述，这些值总出现在消息报文的第一部分。
ALL、GVB和RET命令将被修正以便处理上述二个数值。
如下，它们的格式由控制命令给出。GVB命令被进一步修改以使其可以请求
返回空分配。新的GVB命令有4个8位字段。如前所述，开头两个字段是该操作
码和连接。
下两个字段包含号码fM和fB，用于控制返回消息报文和分配的多少。假如
这些号码在0到128的范围内，则被解释为："当前分配的第128个"。假如这些号
码在128到255的范围内，则被解释为："当前分配的全体"。
6控制信号
控制连接被改为链接0；连接1不再使用。因此，新旧协议可以共存。
根据上面对报文格式的描述，控制链路中发送的消息报文与其他常规消息报
文具有同样的格式。字节长度字段必须包含值8。
控制信号不能包含多于120字节的正文。因此，字节数字段的值最大为120。
这些限制是为了对小型主机有所帮助。
控制信号必须包含整数个控制命令。
因此，控制命令不能够被控制信号分开。
7连接指派
当前连接被分配如下：
0控制连接
1旧协议控制连接，将被逐步淘汰
2-31联接的连接
32-190保留
191仅为加利福尼亚大学洛杉矶分校的网络测量中心使用
192-255对任何独立实验有效
8定长控制命令
ECO、ERP和ERR命令具有固定长度。ECO和ERP命令的长度为16位，包括8位
操作码和8为数据。ERR命令目前长度为96位，包括8位操作码，8位错误码，以及
80位文本。80位对于保存最长的非ERR控制命令来说也是足够的。
9控制命令的格式
如上所述，STR、ALL、GVB、RET、ECO、ERP和ERR命令的格式已经变动。;并
添加了RST和RRP命令。
这些命令的格式如下：
832328
+-----+-----------------------+-----------------------+-----+
1.STRsendsocketreceivesocket
^
+-----+-----------------------+-----------------------+----+
881632+--bytesize
+-----+-----+-----------+-----------------------+
2.ALLlinkmsgspacebitspace
+-----+-----+-----------+-----------------------+
881632
+-----+-----+-----------+-----------------------+
3.RETlinkmsgspacebitspace
+-----+-----+-----------+-----------------------+
8888
+-----+-----+-----+-----+
4.GVBlinkfMfB
^^
+-----+-----+----+----+
+--bitfraction
+--------messagefraction
88
+-----+-----+
5.ECOdata
+-----+-----+
88
+-----+-----+
6.ERPdata
+-----+-----+
8880
+-----+-----+----------------------//-----------------------+
7.ERRtext
^
+-----+----+----------------------//-----------------------+
+--errorcode
8
+-----+
8.RST
+-----+
8
+-----+
9.RRP
+-----+
操作码的值为：
NOP=0
RTS=1
STR=2
CLS=3
ALL=4
GVB=5
RET=6
INR=7
INS=8
ECO=9
ERP=10
ERR=11
RST=12
RRP=13
关于字节流的讨论
之前关于联接应成为位流的管道的规范具有最广泛的普遍性，然而效率却最
低。这里考虑了来自提高效率的压力及其相关问题。
位流产生了低效率的两种类型。
1. 接收方主机被请求进行费用浩大的转型工作，以使相继的消息报文的正
文串联在一起。发送方主机还不得不经常变换正文域，以使它们在字
的边界上相匹配。
2. 假如有可能，哪怕是仅发送一位，也禁止发送方网络控制程序将ANY文
本以不确定的时间保存。这些条件对防止任何可能的停顿来说是必须
的。例如：假定进程A和B在一对联接上正在进行会话，每个进程一个
方向。同时还假设这些进程对于输入的每一位也刚好只生成一位输出。
那么，假如进程A的网络控制程序由于想要将一个等待位和在其之后的
来自进程A的计算输出包装起来，而没能及时发送这一等待位，则进程B
将不能进行输出，B也同样。于是很明显，除非发送方网络控制程序
的缓冲中存在一定量的不为接收放所必须的的数据，发送方网络控制程
序必须假定别的方式并且及时发送数据。
这些考虑导致了"传输单位"这一概念，并须为网络控制程序所知。这个问
题即变为典型的及可能的传输单位大小为何的问题。对于面向字符的交互，8位
的传输单位传递单位似乎很合理。而对于面向链路的交互，该传输单位最好为
该链路本身，并且长度可变。换句话说，最好认为该传输单位是一个字符。对
于文件传输，传输单位最好为两机器字长度的倍数。然而，假如传输单位过大的
话，文档的最后一部分可能不来自整个传输单位。此时，要想取得一致，则该
传输单位应该任意可分，且应足够小。于是，该传输单位的概念似乎与字节等
量，且传输单位的限制也降低了。
随后关于停顿和唤醒方面的讨论显示出，可能会有二个字节与单个联接关
联：
1. 来自发送方进程向发送方网络控制程序的传输的长度为S。发送方网
络控制程序必须在连接被解锁时发送一个消息报文。消息报文计数器最
少为1。位计数器最少为S，并且正文的最小S位已经就绪。该消息报文
必须包含整数个字节。
2. 在接收端，对于从接收方网络控制程序到接收方进程的传输可能有一个
不同的字节长度R。R<>S处的一例子由UCSB给出，它为透明地存储二进
制文件提供了一个文件系统。使用中的主机随36位字节发送是合理的，
尽管UCSB文件系统想要的接收可能多于32位。
很明显，从网络协议的观点来看，仅字节S是相关的，并且为在每个消息报
文中的STR命令中通信的量。字节长度R的选择取决于接收方用户，并且它的意
指接收方网络控制程序将唤醒接收方处理的频率。同时也可能出现这种情况：
即接收方进程与接收方网络控制程序之间建立了一个比"请每R位唤醒我"更复杂
的协定。例如：网络控制程序可以在唤醒接收方进程之前扫瞄并捕捉换行字符。
在新协议中，接收器可以根据提供的字节长度来判定是否拒绝某一联接请
求。
从概念出发，我们可以想象网络控制程序能够处理全部字节长度，并且这种
选择可以一直维持到第三级程序（用户程序、日志记录器、远程登录等等）。一
些主机，非凡是小型主机，可以把握足够的关于它们的三级程序的知识，以限制
字节的种类，以及哪个可以被发送，哪个可以被接收。尽管它是一个局部政策
的问题，委员会仍然强烈建议网络控制程序能够对全部字节进行处理。此外，
我们的委员会之一强烈地感觉到网络控制程序应被写成能够为到用户进程的传
输提供不同字节长度R，以及能够接收全部字节S的程序。
[本RFC文档由EnricoBertone于97年4月]
[编为机器可读形式以便录入RFC在线档案]
RFC107——OutputoftheHost-HostProtocolGlitchCleaningCommittee
主机-主机协议故障清除委员会的说明
