この文書はRFC17の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの文書の配布を制限しません。
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:
1. ＢＮＮ１８２２の１１頁で示されたリンクの自動的な削除が良くないように
思われます：
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) メッセージの間のたくさんのローカルＩ／ＯやＣＰＵ時間−もしホ
ストのユーザが１５秒間リンクを使わないなら、ホストネットワー
クプログラムがリンクオープンを維持するダミーメッセージを生成
しなくてはならないのですか？
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、ホストソフトウェア、１９６９年４月７日、は２頁で尋ね
ます：「ＩＭＰと相対した場合、ホストがＲＦＮＭの制御ができますか？」。
ＢＢＮ、報告１８３７版、１９６９年７月、の２頁が言います：「（ＩＭＰ）
プログラムの主要な機能．．．ＲＦＮＭの生成を含む」。何がもしＩＭＰが
ＲＦＮＭを生成し、そしてそれを発見するなら、なんらかの理由で、そのホ
ストへの最後の受信メッセージのタイムリーな配達を完了することができま
せんか？受信メッセージを指定された最大時間で受取らなければならないホ
スト上のＩＭＰがどこで制約をうけるか私が思い出せないので、これは特に
緊急に思われます。
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. ホストはネットワークにメッセージを繰り返し送る用意ができていなければ
ならず（ＢＮＮ１８２２の１７頁参照）、それ故に特別な廃棄可能ＮＯＰ
メッセージです（ＢＮＮ１８２２、１２頁）。
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. 「任意の遅れ」、ＢＮＮ１８２２、２３頁、真ん中の段落、が上の１で問題
にした自動的なリンク削除と一致しないように思われます。通常関係する時
間は大きさが大きく異なりますが、しかし高い優先度の非ネットワークのホ
ストの責任で次のビットを長く遅らせることができます。
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 ]
[ このＲＦＣは００年３月にマーク・ブランチェットにより機械 ]
[ 可読形式にされオンラインＲＦＣアーカイブに入れられました ]
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
以下のコメントは、JOHN KREZNARのＮＷＧ：−１７の質問にが応えです。
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
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 ]
[ このＲＦＣは００年３月にマーク・ブランチェットにより機械 ]
[ 可読形式にされオンラインＲＦＣアーカイブに入れられました ]