组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：邵毅（epl&nbsp;&nbsp;&nbsp;shaoyi@163.net）<br />
译文发布时间：2001-10-11<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Steve&nbsp;Crocker,&nbsp;Chairman<br />
Request&nbsp;for&nbsp;Comment:&nbsp;102				at&nbsp;BBN,&nbsp;Cambridge<br />
NIC#5763					22,&nbsp;23&nbsp;February&nbsp;1971<br />
<br />
主机-主机&nbsp;协议故障清除委员会的说明<br />
(RFC102---OUTPUT&nbsp;OF&nbsp;THE&nbsp;HOST/HOST&nbsp;PROTOCOLGLITCH&nbsp;CLEANING&nbsp;COMMITTEE)<br />
<br />
在1971年2月17日到19日Urbana网络工作组会议上建立了一个委员会。该委员<br />
会着眼于主机-主机协议，负责考察那些迫切需要或必需的更改。<br />
<br />
委员会主席由Steve&nbsp;Crocker担任，由另八个成员组成：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ray&nbsp;Tomlinson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BBN&nbsp;(Tenex)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jim&nbsp;White&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;UCSB<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Gary&nbsp;Grossman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Illinois<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Tom&nbsp;Barkalow&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Lincoln&nbsp;(TX2)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Will&nbsp;Crowther&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BBN&nbsp;(IMPs)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bob&nbsp;Bressler&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;MIT&nbsp;(Dynamic&nbsp;Modeling<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Doug&nbsp;McKay&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IBM&nbsp;(Yorktown)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Dan&nbsp;Murphy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BBN&nbsp;(Tenex)<br />
<br />
会议讨论了一些问题。对于其中的一些问题，成员就是否建议更改，以及如何更改<br />
达成一致。此外还留有一些问题，并为达成一致，而仅是描述了几种选择方案。<br />
<br />
委员会即刻将就网络群展开深入讨论，并收集关于其建议和提案的反馈意见。然后，<br />
委员会将于1971年3月8日在UCLA再次召集大家来确定最终的议案。接下来，由Steve&nbsp;<br />
Crocker负责撰写2号文件。按工作步骤的依据是网络工作组RFC53号文档。<br />
<br />
下面是几项建议的详细内容：<br />
1．	ECO和ERP命令的长度应为8位（bits）。<br />
2．	ERR命令的长度应为96位。<br />
3．	应除去消息数据类型。而由第三级协议人对此机制加以实现。<br />
4．	应废除“停止”机制。<br />
5．	应增加一对新的单字节命令：RST（重置）和RRP（重置应答）。RST应被解<br />
释为一个清除由发送端主机激发的所有当前条目的NCP表的信号。还应返回<br />
RRP命令，表示已接收到RST命令。发送RST命令的主机可在收到返回的RST<br />
或RRP命令后继续进行下一步工作。如果又出现了一个主机，还可返回一个<br />
RST命令。<br />
6．	尽管在Urbana会议上大家建议连接采用全双工方式，委员会仍建议保留原方案<br />
不改动。<br />
7．	消息长度应为整数字节，并且在消息体内给出字节数以及字节长度。应该废除<br />
标记的习惯，并忽略填充体。<br />
信息体中的字节数应由消息头及随后的16位数字组成。字节长度由接下<br />
来的8位数域表示。下一节将解释针对文本起始点的两个提议。<br />
出于流控制的目的，消息体中的位数为字节数和字节长度的乘积。消息头<br />
及其它固定格式位不计。<br />
8．	考虑终端输入流中中断信号同步的问题，我们认为可以用终端输入扫描器的方<br />
法。两种合理的执行方案包括：终端输入扫描器可尽其可能快的读入字符，来<br />
寻找中断字符，并在用户进程输入队列满的时候将字符串丢弃。此外，还可以<br />
按照用户进程处理可接受的速度（或至少有读入空间时）读取字符。<br />
第一个方案保证中断字符（如PDP-10上的control-C）总被处理，但其需<br />
要其使用的进程对输出流进行解释，从而检测其是否发送过快。第二个方案避<br />
免了溢出问题，但不支持中断码的发送。注意在第一种情况下，分配总是随着<br />
终端输入解释器尽快更新的，分配方案的更新仅作为数据被用户进程接受的结<br />
果。<br />
我们认为使用INS意味着向输入流中插入一个特殊代码，而这个问题实<br />
际上属于第三级协议问题。与此相关的还有创建一个特殊代码插入到输入队列<br />
中。<br />
这一特殊代码可以是网络范围的，与现役系统不同的独立的特殊中断字<br />
符。解释进程的方法为：现役进程将主机中断序列中插入代码，并跟随网络特<br />
别代码，以及INS。<br />
<br />
以下是几项未解决方案：<br />
1．	控制信息的长度<br />
与其它规范相应，控制信息应为一个8位字节整数，信息体长度应在字节记数<br />
位上标出。而且，控制命令间不能被断开。<br />
是否对控制信息的长度加以特别限制这一问题未得到解决。有两种选择：<br />
a）无特别限制（1000字节）<br />
b）120字节<br />
<br />
2．	消息格式<br />
成员一致同意去除标记，并以字节数和字节长度来标示文本长度。关于数据第<br />
一个字节的起始点问题未确定。两种选择方案为：<br />
a）让数据第一字节于72位消息头、字节数、字节长度及间隔后开始。则<br />
消息格式如下图所示：<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;------------16------------&gt;<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;__________________________<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|_&nbsp;_&nbsp;_&nbsp;_&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;消息头&nbsp;&nbsp;&nbsp;&nbsp;_&nbsp;_&nbsp;_&nbsp;_&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|__________________________|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;字节数&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|__________________________|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;字节长度&nbsp;-----|----&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|____________|_____________|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|?-----------------|--数据第一字节起点<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|____________|_____________|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|<br />
<br />
b）使用网络工作组RFC67号文件提出的双向物理传输方案。当发送正常<br />
消息时，主机应发送一个消息头，以及字节数、字节长度，并终止传送。<br />
第二此传送则为消息数据。<br />
<br />
3．	分配<br />
考虑到ALL，GVB和RET命令中包含的分配机制，我们给出两种选择方案：<br />
a）保持原有方案不变。<br />
b）更改流控制算法以跟踪记录消息和位的数量。ALL，GVB和RET命<br />
令有两个数位。ALL命令分配一个消息上限和一个位上限。GVB命令由<br />
两段组成。RET命令则既返回消息体，又返回位。发送消息时，发送的<br />
NCP将消息数减1，将位数减去消息体文本长度。发送的NCP不能够使<br />
其计数器为负。消息计数器应为16位长。<br />
<br />
[本RFC文档由Gottfried&nbsp;Janik于98年2月]<br />
[编为机器可读形式以便录入RFC在线档案]<br />
RFC102---OUTPUT&nbsp;OF&nbsp;THE&nbsp;HOST/HOST&nbsp;PROTOCOLGLITCH&nbsp;CLEANING&nbsp;COMMITTEE<br />
主机-主机&nbsp;协议故障清除委员会的说明<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />