home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0394.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  5.6 KB  |  166 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                    John M. McQuillan
  8. Request for Comments #394                Bolt Beranek and Newman Inc.
  9. NIC 11856                                27 September 1972
  10. Categories:  B.1
  11. Updates:  RFC #381
  12. Obsoletes:
  13.  
  14.              TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
  15. ---------------------------------------------
  16.      This note describes two changes to the IMP-Host communication
  17. protocol described in BBN Report 1822 and revised in RFC 381.  The
  18. first deals with the IMP-to-Host interface and the 30-second timeout
  19. mechanism on each IMP transmission to the Host.  The second deals with
  20. the Host-to-IMP interface and proposes a new timeout mechanism.  These
  21. changes are independent; in statement and in implementation.  We
  22. invite comments on each proposal.  If no adverse comments are
  23. received, they will be installed in the network on Tuesday, October 10
  24. (if serious adverse comments are received, action will be delayed
  25. until early November).
  26.  
  27. 1)  Declaring an unresponsive Host as dead to the network
  28.     -----------------------------------------------------
  29.      Currently, a Host is given 30 seconds to accept each packet of a
  30. regular message and is also given 30 seconds to accept non- regular
  31. messages.  If the Host is unresponsive for this period of time, the
  32. IMP takes the following actions:
  33.  
  34.      a)  All messages held for the Host are discarded.
  35.  
  36.      b)  The source Host for each discarded messages is sent
  37.          a type 9, subtype 0 message (Incomplete Transmission -
  38.          Destination Host Tardy).
  39.  
  40.      c)  The IMP ready line is dropped and raised again.
  41.  
  42.      d)  The Host is sent 3 type 4 messages (NOP).
  43.  
  44.      e)  The Host is sent a type 10 message (IMP-Host Interface
  45.          Reset).
  46.  
  47.      We propose that in addition the IMP declare the Host dead to the
  48. network.  Upon receipt of the next bit from the Host, the IMP will
  49. declare the Host alive and begin the 30-second delay while the
  50. information that the Host is now alive is propagated throughout the
  51. network.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC #394                                            John M. McQuillan
  61.  
  62.      This change is an attempt to alleviate some problems that are
  63. caused by Hosts whose ready lines are up when they are not able to
  64. accept bits from the IMP. Several Hosts fall into this category.
  65. There are some Hosts whose ready lines are wired to be on all the
  66. time.  It is annoying, in terminal use and in running survey programs,
  67. to have to wait for 30 seconds to find out that a Host is not
  68. responding.  Other Hosts sometimes go into "break- point mode" for
  69. system debugging for several minutes at a time.  The NCP software is
  70. not running, and messages accumulate in the network and are thrown
  71. away.  It seems preferable to declare such Hosts to be dead until they
  72. send a message* to the IMP, and then any source Host attempting to
  73. communicate can be notified at once that the destination Host is dead.
  74.  
  75. 2) Timing out Host-to-IMP messages in 15 seconds
  76.    ---------------------------------------------
  77.  
  78.      When the IMP receives a message from a Host, it must acquire
  79. several internal resources in order to process the message.  It must
  80. assign it a message number, make an entry in an internal table, and so
  81. on.  If any of these IMP resources is not available, the IMP simply
  82. waits until it does become available.  It cannot take any more
  83. messages from the Host, and so the interface is stopped.  This
  84. condition is usually momentary, but under unusual circumstances the
  85. IMP may not be able to process a message it has begun to accept for
  86. many seconds.  This situation creates an especially difficult problem
  87. for Hosts with half-duplex interfaces.  If the IMP takes 30 seconds to
  88. process a message, then the IMP-to- Host timeout outlined in 1) takes
  89. effect, and the Host loses all messages sent to it in the last 30
  90. seconds.  (It should be noted that the half-duplex interface may be
  91. the cause of a deadly embrace, e.g. the reason that the IMP cannot
  92. acquire the necessary resources to process a given message may be that
  93. the Host in question has several messages on its queue and they are
  94. tying up storage, message
  95.  
  96.  
  97.  
  98.  
  99.  
  100. __________________
  101. *Thus a Host should send its IMP at least two NOPs (or other
  102.  messages) whenever it receives a type 10 message from its IMP.
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. RFC #394                                           John M. Mcquillan
  114.  
  115. numbers, or table slots.  The Host must accept these messages before
  116. any more messages can be introduced into the network.)  Even for Hosts
  117. with full-duplex interfaces, occurrences of this situation might
  118. interfere with other useful communication.
  119.  
  120.      We propose to notify the Host when the IMP cannot continue to
  121. process a message that it has begun to accept.  The IMP will try to
  122. process the message for 15 seconds, and then will send the Host a type
  123. 9, subtype 4 message (bits 30,31,32 = 100) which will be defined as
  124. Incomplete Transmission - Resources Unavailable.  In such a case, the
  125. IMP has not been able to send any part of the message into the
  126. network.  The IMP will take in the remainder of the message; at that
  127. point a Host with a half-duplex interface should begin to accept
  128. messages from the IMP, while a Host with a full-duplex interface might
  129. attempt to transmit some other message.  The Host may attempt to
  130. retransmit the incomplete message if that is desirable.
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.        [ This RFC was put into machine readable form for entry ]
  144.        [ into the online RFC archives by BBN Corp. under the   ]
  145.        [ direction of Alex McKenzie.                      1/97 ]
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166.