RFC17 Some questions re: Host-IMP Protocol

0017 Some questions re: Host-IMP Protocol. J.E. Kreznar. August 1969. (Format: TXT=6065 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

Network Working Group                                         J. Kreznar
Request for Comments: 17                                             SDC
Category: Informational                                   27 August 1969


                  Some Questions Re: HOST-IMP Protocol

1.  Automatic deletion of links, as indicated in BBN 1822, page 11,
    seems bad:

     a) Link use may be dependent upon human use of a time share
        terminal - indefinite time between messages.

     b) Program using link may be slow due to:

        i)  Busy HOST (many jobs)

        ii) Much local I/O and/or CPU time between messages - is it
            that, if a HOST's user fails to use a link for 15 seconds,
            the HOST network program must generate a dummy message
            merely to keep the link open?

2.  Steve Crocker, HOST Software, 1969 Apr 7, asks on page 2: "Can a
    HOST, as opposed to its IMP, control RFNM's?"  BBN, Report No. 1837,
    1969 Jul, says on page 2: "The principal function of the (IMP)
    program...includes...generating of RFNM's..."  What if an IMP
    generates an RFNM and then discovers it cannot, for some reason,
    complete timely delivery of the last received message to its HOST?
    This seems especially pressing since I don't recall seeing anywhere an
    IMP constraint upon HOSTs that they must accept incoming messages
    within some specified maximum time.

3.  A HOST has to be prepared to repeat transmissions of a message
    into network (see, e.g., Page 17, BBN 1822) therefore why the
            special discardable NOP message (Page 12, BBN 1822).

4.  "Arbitrary delays," middle paragraph, page 23, BBN 1822, seems
    inconsistent with automatic link deletion questioned in 1 above.
    Normally the times involved differ by many orders of magnitude but a
    high priority non-network HOST responsibility could delay next bit for
    a long time.

    1.  Abhi Bhushan, Proj. MAC         10.  Sal Aranda, SDC
    2.  Steve Crocker, UCLA             11.  Jerry Cole,  "
    3.  Ron Stoughton, UCSB             12.  John Kreznar,"
    4.  Elmer Shapiro, SRI              13.  Dick Linde,  "
    5.  Steve Carr, Utah                14.  Bob Long,    "
    6.  John Haefner, RAND              15.  Reg Martin,  "



Kreznar & Kahn                                                  [Page 1]

RFC 17& 17a         Re: HOST-IMP Protocol & Response         August 1969


    7.  Paul Rovner, LL                 16.  Hal Sackman, "
    8.  Bob Kahn, BB & N                17.  C. Weissman, "
    9.  Larry Roberts, ARPA

         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Marc Blanchett 3/00 ]













































Kreznar & Kahn                                                  [Page 2]

RFC 17& 17a         Re: HOST-IMP Protocol & Response         August 1969


Network Working Group                                            R. Kahn
Request for Comments: 17a                    Bolt Beranek and Newman Inc
                                                             August 1969


                 Re: Some Questions Re: HOST-IMP Protocol

   THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS
   WHICH WERE RAISED IN NWG:- 17

   The deletion of a link entry from an IMP's link table will, in
   general, have no effect upon a Host transmission (or reception) at
   that IMP's site.  Let us distinguish between non-use of a link in-
   between messages and non-use of a link due to Host program delays in
   the middle of transmitting or receiving a message.  When the Host
   transmits a message on a link for which an entry is not in the link
   table, one will simply be inserted there.  There is no need for
   "dummy" Host messages to keep a link "open" since a link is
   effectively always open.  Only if the link table becomes full
   immediately after an entry is deleted (a situation we do not expect
   to occur) is there a possibility of resulting delay.

   Arbitrary delays introduced by Host programs are also not
   inconsistent with the link entry deletion procedure.  A link is
   blocked when the first access of the link table is made during
   transmission from the source IMP and is unblocked when the RFNM
   returns.  Only non-blocked transmit link entries are deleted after 30
   seconds of disuse.  The statement on page 23 referencing arbitrary
   delays was only intended to have hardware implications insofar as the
   Host/IMP interface is designed to transfer bits asynchronously
   between the Host and the IMP.

   A RFNM is returned from the destination IMP to the source IMP when a
   message reaches the head of the destination IMP's output queue to the
   Host (i.e. just before a message is sent to the Host).  If a
   destination IMP cannot then deliver that full message to the Host, at
   most one more message may possibly arrive at that IMP due to the
   premature release of the RFNM.  The new message will subsequently
   take its place at the end of the output queue to the Host thus
   guaranteeing the preservation of the proper message arrival sequence.

   The NOP message is a special control message which is available for
   use during initiation of communication between the Host and its IMP.
   The Host may, of course, decline to send NOP messages during this
   period, but the first received message after IMP startup or after the






Kreznar & Kahn                                                  [Page 3]

RFC 17& 17a         Re: HOST-IMP Protocol & Response         August 1969


   Host ready indicator has gone on, may be discarded by the IMP.  We do
   not require a Host to be prepared to repeat transmissions into the
   network.

   R.E. Kahn
   BOLT BERANEK AND NEWMAN INC.


         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Marc Blanchett 3/00 ]









































Kreznar & Kahn                                                  [Page 4]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

IS NULL演算子 NULL値であるか

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る