RFC102 主机-主机 协议故障清除委员会的说明

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：邵毅（epl   shaoyi@163.net）
译文发布时间：2001-10-11
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。

Network Working Group                          Steve Crocker, Chairman
Request for Comment: 102				at BBN, Cambridge
NIC#5763					22, 23 February 1971

主机-主机 协议故障清除委员会的说明
(RFC102---OUTPUT OF THE HOST/HOST PROTOCOLGLITCH CLEANING COMMITTEE)

在1971年2月17日到19日Urbana网络工作组会议上建立了一个委员会。该委员
会着眼于主机-主机协议，负责考察那些迫切需要或必需的更改。

委员会主席由Steve Crocker担任，由另八个成员组成：
             Ray Tomlinson                 BBN (Tenex)
             Jim White                     UCSB
             Gary Grossman                 Illinois
             Tom Barkalow                  Lincoln (TX2)
             Will Crowther                 BBN (IMPs)
             Bob Bressler                  MIT (Dynamic Modeling
             Doug McKay                    IBM (Yorktown)
             Dan Murphy                    BBN (Tenex)

会议讨论了一些问题。对于其中的一些问题，成员就是否建议更改，以及如何更改
达成一致。此外还留有一些问题，并为达成一致，而仅是描述了几种选择方案。

委员会即刻将就网络群展开深入讨论，并收集关于其建议和提案的反馈意见。然后，
委员会将于1971年3月8日在UCLA再次召集大家来确定最终的议案。接下来，由Steve 
Crocker负责撰写2号文件。按工作步骤的依据是网络工作组RFC53号文档。

下面是几项建议的详细内容：
1．	ECO和ERP命令的长度应为8位（bits）。
2．	ERR命令的长度应为96位。
3．	应除去消息数据类型。而由第三级协议人对此机制加以实现。
4．	应废除“停止”机制。
5．	应增加一对新的单字节命令：RST（重置）和RRP（重置应答）。RST应被解
释为一个清除由发送端主机激发的所有当前条目的NCP表的信号。还应返回
RRP命令，表示已接收到RST命令。发送RST命令的主机可在收到返回的RST
或RRP命令后继续进行下一步工作。如果又出现了一个主机，还可返回一个
RST命令。
6．	尽管在Urbana会议上大家建议连接采用全双工方式，委员会仍建议保留原方案
不改动。
7．	消息长度应为整数字节，并且在消息体内给出字节数以及字节长度。应该废除
标记的习惯，并忽略填充体。
信息体中的字节数应由消息头及随后的16位数字组成。字节长度由接下
来的8位数域表示。下一节将解释针对文本起始点的两个提议。
出于流控制的目的，消息体中的位数为字节数和字节长度的乘积。消息头
及其它固定格式位不计。
8．	考虑终端输入流中中断信号同步的问题，我们认为可以用终端输入扫描器的方
法。两种合理的执行方案包括：终端输入扫描器可尽其可能快的读入字符，来
寻找中断字符，并在用户进程输入队列满的时候将字符串丢弃。此外，还可以
按照用户进程处理可接受的速度（或至少有读入空间时）读取字符。
第一个方案保证中断字符（如PDP-10上的control-C）总被处理，但其需
要其使用的进程对输出流进行解释，从而检测其是否发送过快。第二个方案避
免了溢出问题，但不支持中断码的发送。注意在第一种情况下，分配总是随着
终端输入解释器尽快更新的，分配方案的更新仅作为数据被用户进程接受的结
果。
我们认为使用INS意味着向输入流中插入一个特殊代码，而这个问题实
际上属于第三级协议问题。与此相关的还有创建一个特殊代码插入到输入队列
中。
这一特殊代码可以是网络范围的，与现役系统不同的独立的特殊中断字
符。解释进程的方法为：现役进程将主机中断序列中插入代码，并跟随网络特
别代码，以及INS。

以下是几项未解决方案：
1．	控制信息的长度
与其它规范相应，控制信息应为一个8位字节整数，信息体长度应在字节记数
位上标出。而且，控制命令间不能被断开。
是否对控制信息的长度加以特别限制这一问题未得到解决。有两种选择：
a）无特别限制（1000字节）
b）120字节

2．	消息格式
成员一致同意去除标记，并以字节数和字节长度来标示文本长度。关于数据第
一个字节的起始点问题未确定。两种选择方案为：
a）让数据第一字节于72位消息头、字节数、字节长度及间隔后开始。则
消息格式如下图所示：







                    <------------16------------>
                 __________________________
                 |                          |
                 |_ _ _ _     消息头    _ _ _ _ |
                 |                          |
                 |__________________________|
                 |                          |
                 |          字节数          |
                 |__________________________|
                 |            |             |
   字节长度 -----|---->        |             |
                 |____________|_____________|
                 |            |             |
                 |            |?-----------------|--数据第一字节起点
                 |____________|_____________|
                 |                          |
                 |                          |

b）使用网络工作组RFC67号文件提出的双向物理传输方案。当发送正常
消息时，主机应发送一个消息头，以及字节数、字节长度，并终止传送。
第二此传送则为消息数据。

3．	分配
考虑到ALL，GVB和RET命令中包含的分配机制，我们给出两种选择方案：
a）保持原有方案不变。
b）更改流控制算法以跟踪记录消息和位的数量。ALL，GVB和RET命
令有两个数位。ALL命令分配一个消息上限和一个位上限。GVB命令由
两段组成。RET命令则既返回消息体，又返回位。发送消息时，发送的
NCP将消息数减1，将位数减去消息体文本长度。发送的NCP不能够使
其计数器为负。消息计数器应为16位长。

[本RFC文档由Gottfried Janik于98年2月]
[编为机器可读形式以便录入RFC在线档案]
RFC102---OUTPUT OF THE HOST/HOST PROTOCOLGLITCH CLEANING COMMITTEE
主机-主机 协议故障清除委员会的说明


1
RFC文档中文翻译计划