RFC394 日本語訳
0394 Two Proposed Changes to the IMP-Host Protocol. J.M. McQuillan. September 1972. (Format: TXT=5780 bytes) (Updates RFC0381) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group John M. McQuillan Request for Comments #394 Bolt Beranek and Newman Inc. NIC 11856 27 September 1972 Categories: B.1 Updates: RFC #381 Obsoletes:
コメント#394ボルトBeranekとニューマン株式会社NIC11856 1972年9月27日のカテゴリを求めるワーキンググループジョンのM.マッキランの要求をネットワークでつないでください: B.1アップデート: RFC#381は以下を時代遅れにします。
TWO PROPOSED CHANGES TO THE IMP-HOST PROTOCOL --------------------------------------------- This note describes two changes to the IMP-Host communication protocol described in BBN Report 1822 and revised in RFC 381. The first deals with the IMP-to-Host interface and the 30-second timeout mechanism on each IMP transmission to the Host. The second deals with the Host-to-IMP interface and proposes a new timeout mechanism. These changes are independent; in statement and in implementation. We invite comments on each proposal. If no adverse comments are received, they will be installed in the network on Tuesday, October 10 (if serious adverse comments are received, action will be delayed until early November).
悪童ホストプロトコルへの2回の変更案--------------------------------------------- この注意はBBN Report1822で説明されて、RFC381で改訂されたIMP-ホスト通信プロトコルに2回の変化を説明します。 IMPからホスト・インターフェースとの最初の取引とHostへのそれぞれのIMPトランスミッションでの30秒のタイムアウトメカニズム。 2番目は、HostからIMPへのインタフェースに対処して、新しいタイムアウトメカニズムを提案します。 これらの変化は独立しています。 声明と実現で。 私たちはそれぞれの提案のコメントを招待します。 どんな不利なコメントも受け取られていないと、それらは10月10日火曜日のネットワークにインストールされるでしょう(重大な不利なコメントが受け取られていると、動作は11月前半まで遅れるでしょう)。
1) Declaring an unresponsive Host as dead to the network ----------------------------------------------------- Currently, a Host is given 30 seconds to accept each packet of a regular message and is also given 30 seconds to accept non- regular messages. If the Host is unresponsive for this period of time, the IMP takes the following actions:
1) 死者として無反応がHostであるとネットワークに宣言します。----------------------------------------------------- 現在、Hostに通常のメッセージの各パケットを受け入れるために30秒を与えて、また、非通常のメッセージを受け入れるために30秒を与えます。 この期間にHostが無反応であるなら、IMPは以下の行動を取ります:
a) All messages held for the Host are discarded.
a) Hostのために保持されたすべてのメッセージが捨てられます。
b) The source Host for each discarded messages is sent a type 9, subtype 0 message (Incomplete Transmission - Destination Host Tardy).
b) それぞれがメッセージを捨てたので、ソースHostをタイプ9に送ります、「副-タイプ」0メッセージ(不完全なTransmission--目的地Host Tardy)。
c) The IMP ready line is dropped and raised again.
c) IMPの持ち合わせの線は、再び低下していて高くしています。
d) The Host is sent 3 type 4 messages (NOP).
d) 3タイプ4メッセージ(NOP)をHostに送ります。
e) The Host is sent a type 10 message (IMP-Host Interface Reset).
e) タイプ10メッセージ(IMP-ホストInterface Reset)をHostに送ります。
We propose that in addition the IMP declare the Host dead to the network. Upon receipt of the next bit from the Host, the IMP will declare the Host alive and begin the 30-second delay while the information that the Host is now alive is propagated throughout the network.
私たちは、さらに、IMPが、Hostがネットワークに死んでいると宣言するよう提案します。 Hostからの次のビットを受け取り次第、Hostが現在生きているという情報がネットワーク中で伝播される間、IMPはHostが生きていると宣言して、30秒の遅れを始めるでしょう。
[Page 1] RFC #394 John M. McQuillan
[1ページ] RFC#394ジョン・M.マッキラン
This change is an attempt to alleviate some problems that are caused by Hosts whose ready lines are up when they are not able to accept bits from the IMP. Several Hosts fall into this category. There are some Hosts whose ready lines are wired to be on all the time. 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 not responding. Other Hosts sometimes go into "break- point mode" for system debugging for several minutes at a time. The NCP software is not running, and messages accumulate in the network and are thrown away. It seems preferable to declare such Hosts to be dead until they send a message* to the IMP, and then any source Host attempting to communicate can be notified at once that the destination Host is dead.
この変化は持ち合わせの線がそれらがいつにできるかに、IMPからのビットが受け入れていないということであるHostsによって引き起こされるいくつかの問題を軽減する試みです。 数個のHostsがこのカテゴリになります。 持ち合わせの線が絶えずあるように配線されるいくつかのHostsがあります。 端末の使用と調査プログラムを動かすのにおいて、30秒が見つけられるのを待たなければならないために、Hostが応じていないのは、煩わしいです。 他のHostsは一度に、数分間時々システムデバッグのための「中断ポイントモード」に入ります。 NCPソフトウェアが動いていなくて、メッセージは、ネットワークで蓄積して、無駄にされます。 彼らがメッセージ*をIMPに送るまでそのようなHostsが死んでいると宣言するように望ましく思えて、次に、すぐに、目的地Hostが死んでいるように交信するのを試みるどんなソースHostにも通知できます。
2) Timing out Host-to-IMP messages in 15 seconds ---------------------------------------------
2) 15秒でタイミングアウトHostからIMPへのメッセージ---------------------------------------------
When the IMP receives a message from a Host, it must acquire several internal resources in order to process the message. It must assign it a message number, make an entry in an internal table, and so on. If any of these IMP resources is not available, the IMP simply waits until it does become available. It cannot take any more messages from the Host, and so the interface is stopped. This condition is usually momentary, but under unusual circumstances the IMP may not be able to process a message it has begun to accept for many seconds. This situation creates an especially difficult problem for Hosts with half-duplex interfaces. If the IMP takes 30 seconds to process a message, then the IMP-to- Host timeout outlined in 1) takes effect, and the Host loses all messages sent to it in the last 30 seconds. (It should be noted that the half-duplex interface may be the cause of a deadly embrace, e.g. the reason that the IMP cannot acquire the necessary resources to process a given message may be that the Host in question has several messages on its queue and they are tying up storage, message
IMPがHostからメッセージを受け取るとき、それは、メッセージを処理するためにいくつかの社内資源を取得しなければなりません。 などそれはメッセージ番号をそれに割り当てなければならなくて、内部のテーブルに記帳してください。 これらのIMPリソースのいずれも利用可能でないなら、IMPは利用可能になるまで単に待っています。 それがHostからそれ以上の伝言を受け取ることができないので、インタフェースは止められます。 この状態は通常瞬間ですが、珍しい状況で、IMPはそれが何秒も受け入れ始めたメッセージを処理できないかもしれません。 この状況は半二重インタフェースがあるHostsには、特に難しい問題を生じさせます。 IMPがメッセージを処理するために30秒取るなら、IMPからホストへの1に)概説されたタイムアウトは効きます、そして、Hostは最後の30秒でそれに送られたすべてのメッセージを失います。 (半二重インタフェースが致命的な抱擁の原因であるかもしれないことに注意されるべきであり、例えば、IMPが与えられたメッセージを処理するために必要なリソースを取得できない理由は問題のHostには待ち行列に関するいくつかのメッセージがあって、格納をタイアップしているということであるかもしれません、メッセージ
__________________ *Thus a Host should send its IMP at least two NOPs (or other messages) whenever it receives a type 10 message from its IMP.
__________________ *したがって、IMPからタイプ10メッセージを受け取るときはいつも、Hostは少なくとも2NOPs(または、他のメッセージ)をIMPに送るはずです。
[Page 2] RFC #394 John M. Mcquillan
[2ページ] RFC#394ジョンM.Mcquillan
numbers, or table slots. The Host must accept these messages before any more messages can be introduced into the network.) Even for Hosts with full-duplex interfaces, occurrences of this situation might interfere with other useful communication.
数、またはテーブルスロット。 ネットワークにそれ以上のメッセージを取り入れられることができる前にHostはこれらのメッセージを受け入れなければなりません。) 全二重インタフェースがあるHostsに関してはさえ、この状況の発生は他の役に立つコミュニケーションを妨げるかもしれません。
We propose to notify the Host when the IMP cannot continue to process a message that it has begun to accept. The IMP will try to process the message for 15 seconds, and then will send the Host a type 9, subtype 4 message (bits 30,31,32 = 100) which will be defined as Incomplete Transmission - Resources Unavailable. In such a case, the IMP has not been able to send any part of the message into the network. The IMP will take in the remainder of the message; at that point a Host with a half-duplex interface should begin to accept messages from the IMP, while a Host with a full-duplex interface might attempt to transmit some other message. The Host may attempt to retransmit the incomplete message if that is desirable.
私たちは、IMPが、受け入れ始めたというメッセージを処理し続けることができないとき、Hostに通知するよう提案します。 IMPは15秒間、メッセージを処理しようとして、次に、タイプ9、Incomplete Transmissionと定義される「副-タイプ」4メッセージ(32 = 100のビット30、31)をHostに送るでしょう--リソースUnavailable。 このような場合には、IMPはメッセージのどんな部分もネットワークに送ることができませんでした。 IMPはメッセージの残りを見て取るでしょう。 その時、半二重インタフェースがあるHostはIMPからメッセージを受け入れ始めるはずです、全二重インタフェースがあるHostが、ある他のメッセージを送るのを試みるかもしれませんが。 それが望ましいなら、Hostは、不完全なメッセージを再送するのを試みるかもしれません。
[ 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 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 1/97 ]
[Page 3]
[3ページ]
一覧
スポンサーリンク