home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0410.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  3.9 KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                      John M. McQuillan
  8. Request for Comments #410                  Bolt Beranek and Newman
  9. NIC #12402                                 10 November 1972
  10. Categories:  B-1
  11.  
  12.  
  13.            Removal of the 30-Second Delay When Hosts Come Up
  14.            -------------------------------------------------
  15.  
  16.  
  17.      The IMP currently delays accepting input from a Host for 30
  18. seconds after the Host has come up.  This delay serves to allow
  19. the fact that the Host is up to propagate through the network.
  20. The fundamental problem is that a Host must not be permitted
  21. to communicate with a second Host until the second Host
  22. (actually its IMP) has been made aware that the first Host is
  23. up.  Otherwise, one Host may come up and send a "hello"
  24. message to another Host, whose reply is discarded by the IMP
  25. because it is for a dead destination.
  26.  
  27.      All this reasoning is based on a dead destination de-
  28. tection mechanism at the source IMP.  The 30-second delay is
  29. based on the worst-case propagation delay for routing information
  30. in the network, so that every potential source IMP can update
  31. its host up/down table.  There are several drawbacks to this
  32. scheme:
  33.  
  34.          1.  Hosts should not have to wait the worst-case time
  35.              of 30 seconds to send to Hosts at their IMP or
  36.              nearby in the network.
  37.  
  38.          2.  The operation of half-duplex interfaces is made
  39.              even more complicated because of the startup delay.
  40.  
  41.          3.  The timeout period of 30 seconds is really a
  42.              function of network topology and we would like to
  43.              be able to change it when necessary as the network
  44.              expands.
  45.  
  46.      We propose to eliminate the 30-second delay altogether.
  47. The IMP subnetwork will detect messages for a dead Host at the
  48. destination IMP instead of at the source IMP.  There is no delay
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. involved for an IMP to sense when its own Hosts come up, so
  61. that it can always make the correct decision about whether to
  62. give a message to one of its Hosts or to return a destination
  63. dead message to the source Host.  Under this new scheme, when-
  64. ever the IMP's ready line is up it is ready to accept input
  65. from its Hosts without delay.  Several comments on this change
  66. should be noted:
  67.  
  68.          1.  No change to Host software should be necessitated
  69.              by this change.  The Host may attempt to send a
  70.              message to the IMP as soon as it brings its
  71.              ready line up, or it may delay for a long time.  In
  72.              either case, the IMP will take the message.  As
  73.              before, as soon as the Host has brought up its
  74.              ready line, it must accept messages from the IMP.
  75.  
  76.          2.  The Hosts may wish to remove any delays _they_ have
  77.              programmed into their startup routines, since
  78.              such delays are no longer necessary.
  79.  
  80.          3.  Destination dead messages will be returned as
  81.              before with two differences.  There will be more
  82.              delay between the receipt of the message at the
  83.              IMP and the return of the dead destination message
  84.              because it must travel through the network.  For
  85.              the same reason, if many messages are sent to
  86.              dead Hosts, the dead destination messages may come
  87.              back out of order.
  88.  
  89.      The Host personnel responsible for the IMP software at
  90. each site should check that this proposed change will not ad-
  91. versely affect them.  If no adverse comments are received,
  92. this change will go into effect on Tuesday morning, December
  93. 12 at the regular IMP software release time.
  94.  
  95.  
  96.   [ This RFC was put into machine readable form for entry ]
  97.   [ into the online RFC archives by BBN Corp. under the   ]
  98.   [ direction of Alex McKenzie.                      1/97 ]
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.