RFC271 IMP System change notifications

0271 IMP System change notifications. B. Cosell. January 1972. (Format: TXT=4022 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

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 RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]







                                                                [Page 2]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

インストール 初期設定

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る