1 files changed, 165 insertions, 0 deletions
diff --git a/doc/rfc/rfc394.txt b/doc/rfc/rfc394.txt
new file mode 100644
index 0000000..0556805
--- /dev/null
+++ b/doc/rfc/rfc394.txt
@@ -0,0 +1,165 @@
+
+
+
+
+
+
+Network Working Group                    John M. McQuillan
+Request for Comments #394                Bolt Beranek and Newman Inc.
+NIC 11856                                27 September 1972
+Categories:  B.1
+Updates:  RFC #381
+Obsoletes:
+
+             TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL
+---------------------------------------------
+     This note describes two changes to the IMP-Host communication
+protocol described in BBN Report 1822 and revised in RFC 381.  The
+first deals with the IMP-to-Host interface and the 30-second timeout
+mechanism on each IMP transmission to the Host.  The second deals with
+the Host-to-IMP interface and proposes a new timeout mechanism.  These
+changes are independent; in statement and in implementation.  We
+invite comments on each proposal.  If no adverse comments are
+received, they will be installed in the network on Tuesday, October 10
+(if serious adverse comments are received, action will be delayed
+until early November).
+
+1)  Declaring an unresponsive Host as dead to the network
+    -----------------------------------------------------
+     Currently, a Host is given 30 seconds to accept each packet of a
+regular message and is also given 30 seconds to accept non- regular
+messages.  If the Host is unresponsive for this period of time, the
+IMP takes the following actions:
+
+     a)  All messages held for the Host are discarded.
+
+     b)  The source Host for each discarded messages is sent
+         a type 9, subtype 0 message (Incomplete Transmission -
+         Destination Host Tardy).
+
+     c)  The IMP ready line is dropped and raised again.
+
+     d)  The Host is sent 3 type 4 messages (NOP).
+
+     e)  The Host is sent a type 10 message (IMP-Host Interface
+         Reset).
+
+     We propose that in addition the IMP declare the Host dead to the
+network.  Upon receipt of the next bit from the Host, the IMP will
+declare the Host alive and begin the 30-second delay while the
+information that the Host is now alive is propagated throughout the
+network.
+
+
+
+
+
+
+                                                                [Page 1]
+
+RFC #394                                            John M. McQuillan
+
+     This change is an attempt to alleviate some problems that are
+caused by Hosts whose ready lines are up when they are not able to
+accept bits from the IMP. Several Hosts fall into this category.
+There are some Hosts whose ready lines are wired to be on all the
+time.  It is annoying, in terminal use and in running survey programs,
+to have to wait for 30 seconds to find out that a Host is not
+responding.  Other Hosts sometimes go into "break- point mode" for
+system debugging for several minutes at a time.  The NCP software is
+not running, and messages accumulate in the network and are thrown
+away.  It seems preferable to declare such Hosts to be dead until they
+send a message* to the IMP, and then any source Host attempting to
+communicate can be notified at once that the destination Host is dead.
+
+2) Timing out Host-to-IMP messages in 15 seconds
+   ---------------------------------------------
+
+     When the IMP receives a message from a Host, it must acquire
+several internal resources in order to process the message.  It must
+assign it a message number, make an entry in an internal table, and so
+on.  If any of these IMP resources is not available, the IMP simply
+waits until it does become available.  It cannot take any more
+messages from the Host, and so the interface is stopped.  This
+condition is usually momentary, but under unusual circumstances the
+IMP may not be able to process a message it has begun to accept for
+many seconds.  This situation creates an especially difficult problem
+for Hosts with half-duplex interfaces.  If the IMP takes 30 seconds to
+process a message, then the IMP-to- Host timeout outlined in 1) takes
+effect, and the Host loses all messages sent to it in the last 30
+seconds.  (It should be noted that the half-duplex interface may be
+the cause of a deadly embrace, e.g. the reason that the IMP cannot
+acquire the necessary resources to process a given message may be that
+the Host in question has several messages on its queue and they are
+tying up storage, message
+
+
+
+
+
+__________________
+*Thus a Host should send its IMP at least two NOPs (or other
+ messages) whenever it receives a type 10 message from its IMP.
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+RFC #394                                           John M. Mcquillan
+
+numbers, or table slots.  The Host must accept these messages before
+any more messages can be introduced into the network.)  Even for Hosts
+with full-duplex interfaces, occurrences of this situation might
+interfere with other useful communication.
+
+     We propose to notify the Host when the IMP cannot continue to
+process a message that it has begun to accept.  The IMP will try to
+process the message for 15 seconds, and then will send the Host a type
+9, subtype 4 message (bits 30,31,32 = 100) which will be defined as
+Incomplete Transmission - Resources Unavailable.  In such a case, the
+IMP has not been able to send any part of the message into the
+network.  The IMP will take in the remainder of the message; at that
+point a Host with a half-duplex interface should begin to accept
+messages from the IMP, while a Host with a full-duplex interface might
+attempt to transmit some other message.  The Host may attempt to
+retransmit the incomplete message if that is desirable.
+
+
+
+
+
+
+
+
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by BBN Corp. under the   ]
+       [ direction of Alex McKenzie.                      1/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+