RFC692 - Comments on IMP/Host Protocol changes (RFCs 687 and 690)

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group Stephen Wolfe

RFC# 692 UCLA CCN

NIC # 32734 June 20, 1975

COMMENTS ON IMP/HOST PROTOCOL CHANGES, (RFCS 687 AND 690)

Basically, the proposed set of changes in RFC687 seems reasonable, as

are the comments in RFC690.

The major problem, as pointed out by Postel, is the change in the

combined length of the IMP and Host leaders to a total of 120 bits,

which is not a multiple of both 8 and 36 bits.

The suggested solution is to increase the length of the host to host

protocol leader by 24 bits, creating a total length of 144 bits. The

problem, however, is that the only way of compatibly changing this

length would be to have the IMP either insert or delete the extra 24

bits when converting to/from the old format leader. The problems with

this solution are obvious.

The better solution is to change the length of the new proposed IMP

leader. I suggest 104 bits instead of 80 bits. The complaint that 104

is not a multiple of an IMP Word is valid, but it should not be that

difficult if the following rules are observed.

1. The last 8 bits are never used to convey information.

2. The network is not required to pass them from source to

destination, or to return them to the source.

3. When sending messages of types other than zero, (irregular

messages), the IMP is allowed to send either 96, 104 or 112 bits

of data, the choice being at the IMP's convenience.

4. Also, if desired, either 96 or 112 could be used as the new

leader length for irregular messages.

It must be faster (and cheaper) to just change the IMP program to handle

a 104 bit leader, than to force additional changes in all hosts using

the standard protocol.

Another suggested extension to the protocol would add a new type of IMP

to Host message. This message has a table of Host names (people type

character strings) and Host network addresses. Send this message(s) to

the Host after each interface reset, or alternatively, it could be a

response to a new Host to IMP request for this information.

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by Alex McKenzie with ]

[ support from GTE, formerly BBN Corp. 10/99 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航