この文書はRFC17の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。


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


                  Some Questions Re: HOST-IMP Protocol
               いくつかの質問 返答:ホスト−IMPプロトコル

1.  Automatic deletion of links, as indicated in BBN 1822, page 11,
    seems bad:
1.  BNN1822の11頁で示されたリンクの自動的な削除が良くないように
    思われます:

     a) Link use may be dependent upon human use of a time share
        terminal - indefinite time between messages.
     a) リンクの使用はタイムシェアリング端末の人間の使用−メッセージ間の
        時間が不明確−に依存しているかもしれません。

     b) Program using link may be slow due to:
     b) リンクを使うプログラムが遅いかもしれないこと:

        i)  Busy HOST (many jobs)
        i)  忙しいホスト(多くの仕事)

        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?
        ii) メッセージの間のたくさんのローカルI/OやCPU時間−もしホ
            ストのユーザが15秒間リンクを使わないなら、ホストネットワー
            クプログラムがリンクオープンを維持するダミーメッセージを生成
            しなくてはならないのですか?

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.
2.  Steve Crocker、ホストソフトウェア、1969年4月7日、は2頁で尋ね
    ます:「IMPと相対した場合、ホストがRFNMの制御ができますか?」。
    BBN、報告1837版、1969年7月、の2頁が言います:「(IMP)
    プログラムの主要な機能...RFNMの生成を含む」。何がもしIMPが
    RFNMを生成し、そしてそれを発見するなら、なんらかの理由で、そのホ
    ストへの最後の受信メッセージのタイムリーな配達を完了することができま
    せんか?受信メッセージを指定された最大時間で受取らなければならないホ
    スト上のIMPがどこで制約をうけるか私が思い出せないので、これは特に
    緊急に思われます。

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).
3.  ホストはネットワークにメッセージを繰り返し送る用意ができていなければ
    ならず(BNN1822の17頁参照)、それ故に特別な廃棄可能NOP
    メッセージです(BNN1822、12頁)。

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.
4.  「任意の遅れ」、BNN1822、23頁、真ん中の段落、が上の1で問題
    にした自動的なリンク削除と一致しないように思われます。通常関係する時
    間は大きさが大きく異なりますが、しかし高い優先度の非ネットワークのホ
    ストの責任で次のビットを長く遅らせることができます。

    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,  "
    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 ]
       [ このRFCは00年3月にマーク・ブランチェットにより機械 ]
       [ 可読形式にされオンラインRFCアーカイブに入れられました ]



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


                 Re: Some Questions Re: HOST-IMP Protocol
               応答:いくつかの質問レ:ホスト−IMPプロトコル

   THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS
   WHICH WERE RAISED IN NWG:- 17
   以下のコメントは、JOHN KREZNARの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.
   IMPリンクテーブルからのリンク項目の削除は、一般に、そのIMPのサ
   イトでホスト送信(あるいは受信)に効果を持たないでしょう。中間メッセー
   ジの非使用リンクと、メッセージの送信や受信の間のホストプログラムの遅
   れによるリンクの非使用を区別しましょう。ホストが項目がリンクテーブル
   にないリンク上にメッセージを送信する時、単純にそこに差し込まれるでしょ
   う。リンクが効果的に常にオープンであるから、「ダミー」ホストメッセー
   ジでリンクの「オープン」を維持する必要がありません。ただもし項目が削
   除されるすぐ後にリンクテーブルが埋まる(我々が起こることを期待しない
   状態)なら結果として生じている遅延の可能性があります。

   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.
   ホストプログラムによる任意の遅延は同じくリンクの項目削除手順と矛盾し
   ません。送信IMPからの送信の間にリンクテーブルの最初のアクセスが行
   われるときリンクは塞がれて、RFNMが帰ってくるときに空けられます。
   ただ非塞がり送信項目が30秒間使用されていなければの30秒後に削除さ
   れます。任意の遅延を参照している23頁の文は、ホスト/IMPインタ
   フェースがホストと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.
   メッセージが宛先IMPの出力キューの先頭からホストに到達するときに、
   宛先IMPからソースIMPへ送られます(すなわち、メッセージがホスト
   に送られる直前)。もし宛先IMPがそのホストへ完全なメッセージを届け
   ることができないなら、RFNMの早すぎる開放のために、IMPに最大1
   つのメッセージが到着します。新しいメッセージは、その後、ホストへの出
   力キューの最後に置かれるでしょう、それで適切なメッセージ到着の連続の
   保存を保証します。

   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
   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.
   NOPメッセージはホストとIMP間の通信の開始の際に使用可能な特殊な
   制御メッセージです。ホストは、もちろん、この期間にNOPメッセージを
   送ることを断わってもよいです、しかしIMP始動後の最初の受信メッセー
   ジあるいはホストのレディ表示の後の最初のメッセージは、IMPによって
   捨てられるかもしれません。我々はホストにネットワークでの伝達の用意が
   できているように要求しません。

   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 ]
       [ このRFCは00年3月にマーク・ブランチェットにより機械 ]
       [ 可読形式にされオンラインRFCアーカイブに入れられました ]

Japanese translation by Ishida So