rfc802.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,673 行 · 第 1/5 页

One possibility is for the IMP to stop  accepting  messages  from

the  source  host  until  it has gathered the resources needed to

process the message just submitted.  This strategy  is  known  as

blocking  the  host,  and is basically the strategy that has been

used in the ARPANET up to the present.  When  a  host  submits  a

message  to  an  IMP, all further transmissions from that host to

that IMP are blocked until the message can be processed.


It is important to note, however, that not all  messages  require

the  same  set  of resources in order to be processed by the IMP.

The particular set of resources needed will depend on the message

type, the message length, and the destination host of the message

(see below).  Therefore, although it might take a  long  time  to



                             - 16 -




RFC 802                                           Andrew G. Malis



gather  the  resources needed to process some particular message,

it might take only a short time to gather the resources needed to

process  some  other  message.   This  fact exposes a significant

disadvantage in the strategy of blocking the host.  A host  which

is  blocked may have many other messages to submit which, if only

they could be submitted, could be processed immediately.   It  is

"unfair"  for  the IMP to refuse to accept these message until it

has gathered the resources for  some  other,  unrelated  message.

Why  should messages for which the IMP has plenty of resources be

delayed for an arbitrarily long amount of time just  because  the

IMP lacks the resources needed for some other message?


A simple way to alleviate the problem would be to place  a  limit

on  the  amount of time during which a host can be blocked.  This

amount  of  time  should  be  long  enough  so  that,   in   most

circumstances,  the  IMP  will  be  able  to gather the resources

needed to process the message within the given time period.   If,

however, the resources cannot be gathered in this period of time,

the IMP will flush the message, sending a  reply  to  the  source

host   indicating   that  the  message  was  not  processed,  and

specifying the reason that it could not be  processed.   However,

the  resource gathering process would continue.  The intention is

that the host  resubmit  the  message  in  a  short  time,  when,

hopefully,   the   resource   gathering   process  has  concluded



                             - 17 -




RFC 802                                           Andrew G. Malis



successfully.   In  the  meantime,  the  host  can  submit  other

messages,  which may be processed sooner.  This strategy does not

eliminate the phenomenon of host blocking, but  only  limits  the

time  during  which  a  host is blocked.  This shorter time limit

will generally fall somewhere in the range of 100 milliseconds to

2  seconds,  with  its value possibly depending on the reason for

the blocking.


Note, however, that there  is  a  disadvantage  to  having  short

blocking  times.  Let us say that the IMP accepts a message if it

has all the resources needed to process it.  The ARPANET provides

a  sequential  delivery  service,  whereby messages with the same

priority, source host, and destination host are delivered to  the

destination  host in the same order as they are accepted from the

source host.  With short blocking times, however,  the  order  in

which  the  IMP accepts messages from the source host need not be

the same as  the  order  in  which  the  source  host  originally

submitted  the messages.  Since the two data streams (one in each

direction) between the host and the IMP are not synchronized, the

host  may  not  receive the reply to a rejected message before it

submits subsequent messages of the same  priority  for  the  same

destination host.  If a subsequent message is accepted, the order

of acceptance differs from the order of original submission,  and

the ARPANET will not provide the same type of sequential delivery



                             - 18 -




RFC 802                                           Andrew G. Malis



that it has in the past.


Up to now, type 0 (regular)  messages  have  only  had  sub-types

available  to  request the standard blocking timeout.  The short-

blocking feature makes available new  sub-types  that  allow  the

host  to  request  messages to be short-blocking, i.e. only cause

the host to be blocked for a short amount of time if the  message

cannot be immediately processed.   See section 3.1 for a complete

list of the available sub-types.


If sequential delivery by the subnet is a strict requirement,  as

would  be  the  case  for  messages  produced  by NCP, the short-

blocking feature cannot be used.  For messages produced  by  TCP,

however,  the  use  of  the short-blocking feature is allowed and

recommended.




2.4.2  Reasons for Host Blockage


There are a number of reasons why a message could  cause  a  long

blockage  in  the  IMP,  which would result in the rejection of a

short-blocking message.  The IMP  signals  this  rejection  of  a

short-blocking message by using the Incomplete Transmission (Type

9) message, using the sub-type field to  indicate  which  of  the

above  reasons  caused the rejection of the message.  See section




                             - 19 -




RFC 802                                           Andrew G. Malis



3.2 for a summary of the Incomplete Transmission  message  and  a

complete  list of its sub-types.  The sub-types that apply to the

short-blocking feature are:


6.  Connection setup-delay: Although the IMP  presents  a  simple

    message-at-a-time  interface  to  the  host,  it  provides an

    internal  connection-oriented  (virtual   circuit)   service,

    except  in  the  case  of  uncontrolled messages (see section

    2.3).   Two  messages  are  considered  to  be  on  the  same

    connection  if they have the same source host (i.e., they are

    submitted to the same IMP over the same host interface),  the

    same priority, and the same destination host name or address.

    The subnet maintains internal connection set-up and tear-down

    procedures.   Connections  are set up as needed, and are torn

    down  only  after  a  period  of  inactivity.   Occasionally,

    network  congestion or resource shortage will cause a lengthy

    delay in connection set-up.  During this period, no  messages

    for  that  connection can be accepted, but other messages can

    be accepted.


7.  End-to-end flow  control:  For  every  message  that  a  host

    submits  to  an  IMP  (except  uncontrolled messages) the IMP

    eventually  returns  a  reply  to  the  host  indicating  the

    disposition  of  the  message.   Between  the  time  that the




                             - 20 -




RFC 802                                           Andrew G. Malis



    message is submitted and  the  time  the  host  receives  the

    reply,  the  message  is  said to be outstanding. The ARPANET

    allows  only  eight  outstanding  messages   on   any   given

    connection.   If  there  are  eight outstanding messages on a

    given connection, and a ninth is  submitted,  it  cannot  the

    accepted.  If  a message is refused because its connection is

    blocked due to flow control, messages  on  other  connections

    can still be accepted.


    End-to-end flow control is the  most  common  cause  of  host

    blocking in the ARPANET at present.


8.  Destination IMP buffer space shortage: If the host submits  a

    message  of  more  than  1008  bits  (exclusive of the 96-bit

    leader), buffer space at the destination IMP must be reserved

    before  the  message  can  be  accepted.  Buffer space at the

    destination IMP is always reserved on a per-connection basis.

    If  the  destination  IMP  is  heavily loaded, there may be a

    lengthy wait for the buffer space;  this  is  another  common

    cause  of  blocking  in  the  present  ARPANET.  Messages are

    rejected  for  this  reason  based  on   their   length   and

    connection;  messages  of  1008 or fewer bits or messages for

    other connections may still be acceptable.






                             - 21 -




RFC 802                                           Andrew G. Malis



9.  Congestion control: A message may be refused for  reasons  of

    congestion  control if the path via the intermediate IMPs and

    lines to the destination IMP is too heavily loaded to  handle

    additional  traffic.   Messages  to other destinations may be

    acceptable, however.


10.  Local resource shortage: Sometimes the source IMP itself  is

    short  of buffer space, table entries, or some other resource

    that it needs to accept a message.  Unlike the other  reasons

    for message rejection, this resource shortage will affect all

    messages equally,  except  for  uncontrolled  messages.   The

    message's size or connection is not relevant.


The short-blocking feature is available  to  all  hosts  on  C/30

IMPs,  whether they are using the 1822 or 1822L protocol, through

the use of Type 0, sub-type 1 and 2 messages.  A host using these

sub-types  should  be  prepared  to  correctly  handle Incomplete

Transmission messages from the IMP.




2.5  Establishing Host-IMP Communications


When a host comes up on an IMP, or after there has been  a  break

in   the  communications  between  the  host  and  its  IMP  (see

1822(3.2)), the orderly flow of messages between the host and the




                             - 22 -




RFC 802                                           Andrew G. Malis



IMP  needs  to  be properly (re)established.  This allows the IMP

and host to recover from most any failure  in  the  other  or  in

their communications path, including a break in mid-message.


The first messages that a host should send to its IMP  are  three

NOP  messages.   Three  messages  are  required to insure that at

least one message will be properly read by the IMP (the first NOP

could be concatenated to a previous message if communications had

been broken in mid-stream, and the third provides redundancy  for

the   second).    These   NOPs   serve  several  functions:  they

synchronize the IMP with the host, they tell  the  IMP  how  much

padding  the  host  requires  between  the message leader and its

body, and they also tell the IMP whether the host will  be  using

1822 or 1822L leaders.


Similarly, the IMP will send three  NOPs  to  the  host  when  it

detects  that  the host has come up.  Actually, the IMP will send

six NOPs, alternating three 1822  NOPs  with  three  1822L  NOPs.

Thus, the host will see three NOPs no matter which protocol it is

using.   The  NOPs  will  be  followed  by  two  Interface  Reset

messages,  one of each style.  If the IMP receives a NOP from the

host while the above sequence is occurring,  the  IMP  will  only

send  the  remainder  of  the NOPs and the Interface Reset in the

proper style.  The 1822 NOPs will contain the 1822 address of the




                             - 23 -




RFC 802                                           Andrew G. Malis



host interface, and the 1822L NOPs will contain the corresponding

1822L address.


Once the IMP  and  the  host  have  sent  each  other  the  above

messages, regular communications can commence.  See 1822(3.2) for

further details concerning the ready line,  host  tardiness,  and

other issues.





































                             - 24 -




RFC 802                                           Andrew G. Malis



3  1822L LEADER FORMATS


The following sections describe the formats of the  leaders  that

precede  messages  between  an 1822L host and its IMP.  They were

designed to be as compatible with the 1822 leaders  as  possible.

The  second,  fifth,  and  sixth  words  are identical in the two

leaders, and all  of  the  existing  functionality  of  the  1822

leaders has been retained.  The first difference one will note is

in the first word.  The 1822 New Format Flag is now also used  to

identify  the  two  types of 1822L leaders, and the Handling Type

has been moved to the second byte.  The third  and  fourth  words

contain the Source and Destination 1822L Name, respectively.