RFC271 - IMP System change notifications

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

Network Working Group Bernard Cosell

RFC# 271 BBN

NIC 7819 3 January 1972

Categories: B.1

Updates: None

Obsoletes: None

IMP System Change Notification

------------------------------

We are planning to install a new version of the IMP System,

version 2514. The new version is scheduled for field installation

Thursday, January 13, 1972 between noon and 1 PM EST, and will require

the assistance of IMP-site personnel at each site.

There were two principal problems with version 2513, both related

to the delay inserted between the time when a Host comes up and the

time when its IMP will accept the second packet from the Host. The

first was that the delay was lengthened to slightly over 40 seconds,

which caused hardware difficulties for some Hosts. The second was

that there was an ambiguity that could make the delay run as long as a

minute and a quarter. On the first point, the delay has been backed

off from 40 seconds to 30 seconds, as it was for IMP systems prior to

2513. On the second point, the ambiguity has been entirely removed.

(Note, however, that BBN Report No. 1822, on page 23, specifies that

the delay may range from 30 to 90 seconds, and that future versions

may require a longer delay.)

In summary, a Host may come alive in one of two ways, corres-

ponding to the two ways in which the Host can go down. If the Host

went down voluntarily (by sending a "Host going down" to the IMP), the

Host indicates his intention to come alive by sending the IMP

something. If the Host went down involuntarily (by dropping his ready

line), the Host indicates his intention to come alive by bringing his

ready line back up. In either case

[Page 1]

the IMP will refuse to accept more than one packet from the Host for

30 seconds after the Host has indicated his intention to come alive.

Notice, however, that the Host must be prepared to accept all messages

from the Network from the instant that he indicates his intention to

come alive.* This particular point seems to have given many Hosts

difficulty in running through their standard initialization

procedures. Don't forget this simple and universal rule, that when

you are telling your IMP that you are alive, you must be prepared to

always take every- thing from the Network whether or not the Network

is taking any- thing from you.

Version 2514 will also incorporate a few other changes, mainly

related to the operation of the NCC. Since the Timeout is, for a

change, being made shorter, and the other modifications are minor,

there should be no appreciable transient with the coming of the new

version.

_______________

*In fact, if the Host does not accept messages from his IMP

pimmediately then the Host may see the IMP's Ready line go down

for 1/4 second sometime during the 30 second waiting period.

This is due to the following set of circumstances:

* The IMP periodically places NOPs on the queue for a

dead Host as part of the process of checking the IMP/Host

interface.

* If a message remains on a Host's queue for 30 seconds

without being taken, the IMP drops its Ready line for

1/4 second in order to clear the interface (see RFC#270).

* The timeout periods for the Host queue and the delay

when the Host comes alive are _not_ synchronized.

If the Host is prepared to see the IMP's Ready line dropped

during the 30-second delay while coming alive, then no harm

will be done if messages from the IMP are not accepted immediately.

BC/jm

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by BBN Corp. under the ]

[ direction of Alex McKenzie. 12/96 ]

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