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

时间:2004-08-06 来源: 作者: 点击:
在1971年2月17日到19日Urbana网络工作组会议上建立了一个委员会。该委员 会着眼于主机-主机协议,负责考察那些迫切需要或必需的更改。 委员会主席由SteveCrocker担任,由另八个成员组成: RayTomlinsonBBN(Tenex) JimWhiteUCSB GaryGrossmanIllinois TomBarkalowLincol
  

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

委员会主席由SteveCrocker担任,由另八个成员组成:
RayTomlinsonBBN(Tenex)
JimWhiteUCSB
GaryGrossmanIllinois
TomBarkalowLincoln(TX2)
WillCrowtherBBN(IMPs)
BobBresslerMIT(DynamicModeling
DougMcKayIBM(Yorktown)
DanMurphyBBN(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文档由GottfriedJanik于98年2月]
[编为机器可读形式以便录入RFC在线档案]
RFC102---OUTPUTOFTHEHOST/HOSTPROTOCOLGLITCHCLEANINGCOMMITTEE
主机-主机协议故障清除委员会的说明

------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容