Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
Network Working Group                    John M. McQuillanRequest for Comments #394                Bolt Beranek and Newman Inc.NIC 11856                                27 September 1972Categories:  B.1Updates:  RFC #381Obsoletes:TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL---------------------------------------------     This note describes two changes to the IMP-Host communicationprotocol described in BBN Report 1822 and revised inRFC 381.  Thefirst deals with the IMP-to-Host interface and the 30-second timeoutmechanism on each IMP transmission to the Host.  The second deals withthe Host-to-IMP interface and proposes a new timeout mechanism.  Thesechanges are independent; in statement and in implementation.  Weinvite comments on each proposal.  If no adverse comments arereceived, they will be installed in the network on Tuesday, October 10(if serious adverse comments are received, action will be delayeduntil early November).1)  Declaring an unresponsive Host as dead to the network    -----------------------------------------------------     Currently, a Host is given 30 seconds to accept each packet of aregular message and is also given 30 seconds to accept non- regularmessages.  If the Host is unresponsive for this period of time, theIMP 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 thenetwork.  Upon receipt of the next bit from the Host, the IMP willdeclare the Host alive and begin the 30-second delay while theinformation that the Host is now alive is propagated throughout thenetwork.                                                                [Page 1]

RFC #394                                            John M. McQuillan     This change is an attempt to alleviate some problems that arecaused by Hosts whose ready lines are up when they are not able toaccept bits from the IMP. Several Hosts fall into this category.There are some Hosts whose ready lines are wired to be on all thetime.  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 notresponding.  Other Hosts sometimes go into "break- point mode" forsystem debugging for several minutes at a time.  The NCP software isnot running, and messages accumulate in the network and are thrownaway.  It seems preferable to declare such Hosts to be dead until theysend a message* to the IMP, and then any source Host attempting tocommunicate 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 acquireseveral internal resources in order to process the message.  It mustassign it a message number, make an entry in an internal table, and soon.  If any of these IMP resources is not available, the IMP simplywaits until it does become available.  It cannot take any moremessages from the Host, and so the interface is stopped.  Thiscondition is usually momentary, but under unusual circumstances theIMP may not be able to process a message it has begun to accept formany seconds.  This situation creates an especially difficult problemfor Hosts with half-duplex interfaces.  If the IMP takes 30 seconds toprocess a message, then the IMP-to- Host timeout outlined in 1) takeseffect, and the Host loses all messages sent to it in the last 30seconds.  (It should be noted that the half-duplex interface may bethe cause of a deadly embrace, e.g. the reason that the IMP cannotacquire the necessary resources to process a given message may be thatthe Host in question has several messages on its queue and they aretying 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. Mcquillannumbers, or table slots.  The Host must accept these messages beforeany more messages can be introduced into the network.)  Even for Hostswith full-duplex interfaces, occurrences of this situation mightinterfere with other useful communication.     We propose to notify the Host when the IMP cannot continue toprocess a message that it has begun to accept.  The IMP will try toprocess the message for 15 seconds, and then will send the Host a type9, subtype 4 message (bits 30,31,32 = 100) which will be defined asIncomplete Transmission - Resources Unavailable.  In such a case, theIMP has not been able to send any part of the message into thenetwork.  The IMP will take in the remainder of the message; at thatpoint a Host with a half-duplex interface should begin to acceptmessages from the IMP, while a Host with a full-duplex interface mightattempt to transmit some other message.  The Host may attempt toretransmit 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]

[8]ページ先頭

©2009-2025 Movatter.jp