home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0271.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  3.9 KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                              Bernard Cosell
  8. RFC # 271                                          BBN
  9. NIC 7819                                           3 January 1972
  10. Categories:  B.1
  11. Updates:  None
  12. Obsoletes:  None
  13.  
  14.                      IMP System Change Notification
  15.                      ------------------------------
  16.  
  17.  
  18.     We are planning to install a new version of the IMP System,
  19. version 2514.  The new version is scheduled for field installation
  20. Thursday, January 13, 1972 between noon and 1 PM EST, and will require
  21. the assistance of IMP-site personnel at each site.
  22.  
  23.  
  24.     There were two principal problems with version 2513, both related
  25. to the delay inserted between the time when a Host comes up and the
  26. time when its IMP will accept the second packet from the Host.  The
  27. first was that the delay was lengthened to slightly over 40 seconds,
  28. which caused hardware difficulties for some Hosts.  The second was
  29. that there was an ambiguity that could make the delay run as long as a
  30. minute and a quarter.  On the first point, the delay has been backed
  31. off from 40 seconds to 30 seconds, as it was for IMP systems prior to
  32. 2513.  On the second point, the ambiguity has been entirely removed.
  33. (Note, however, that BBN Report No. 1822, on page 23, specifies that
  34. the delay may range from 30 to 90 seconds, and that future versions
  35. may require a longer delay.)
  36.  
  37.  
  38.     In summary, a Host may come alive in one of two ways, corres-
  39. ponding to the two ways in which the Host can go down.  If the Host
  40. went down voluntarily (by sending a "Host going down" to the IMP), the
  41. Host indicates his intention to come alive by sending the IMP
  42. something.  If the Host went down involuntarily (by dropping his ready
  43. line), the Host indicates his intention to come alive by bringing his
  44. ready line back up.  In either case
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. the IMP will refuse to accept more than one packet from the Host for
  61. 30 seconds after the Host has indicated his intention to come alive.
  62. Notice, however, that the Host must be prepared to accept all messages
  63. from the Network from the instant that he indicates his intention to
  64. come alive.* This particular point seems to have given many Hosts
  65. difficulty in running through their standard initialization
  66. procedures.  Don't forget this simple and universal rule, that when
  67. you are telling your IMP that you are alive, you must be prepared to
  68. always take every- thing from the Network whether or not the Network
  69. is taking any- thing from you.
  70.  
  71.     Version 2514 will also incorporate a few other changes, mainly
  72. related to the operation of the NCC.  Since the Timeout is, for a
  73. change, being made shorter, and the other modifications are minor,
  74. there should be no appreciable transient with the coming of the new
  75. version.
  76.  
  77. _______________
  78. *In fact, if the Host does not accept messages from his IMP
  79. pimmediately then the Host may see the IMP's Ready line go down
  80. for 1/4 second sometime during the 30 second waiting period.
  81. This is due to the following set of circumstances:
  82.  
  83.     *  The IMP periodically places NOPs on the queue for a
  84.        dead Host as part of the process of checking the IMP/Host
  85.        interface.
  86.  
  87.     *  If a message remains on a Host's queue for 30 seconds
  88.        without being taken, the IMP drops its Ready line for
  89.        1/4 second in order to clear the interface (see RFC #270).
  90.  
  91.     *  The timeout periods for the Host queue and the delay
  92.        when the Host comes alive are _not_ synchronized.
  93.  
  94. If the Host is prepared to see the IMP's Ready line dropped
  95. during the 30-second delay while coming alive, then no harm
  96. will be done if messages from the IMP are not accepted immediately.
  97.  
  98.  
  99. BC/jm
  100.  
  101.        [ This RFC was put into machine readable form for entry ]
  102.        [ into the online RFC archives by BBN Corp. under the   ]
  103.        [ direction of Alex McKenzie.                   12/96   ]
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.