RFC271 日本語訳

Network Working Group                              Bernard Cosell
RFC # 271                                          BBN
NIC 7819                                           3 January 1972
Categories:  B.1
Updates:  None
Obsoletes:  None

ワーキンググループバーナードコーセルRFC#271BBN NIC7819 1972年1月3日のカテゴリをネットワークでつないでください: B.1アップデート: なにも以下を時代遅れにしません。 なし

                     IMP System Change Notification
                     ------------------------------

悪童システム変更届出書------------------------------

    We are planning to install a new version of the IMP System,
version 2514.  The new version is scheduled for field installation
Thursday, January 13, 1972 between noon and 1 PM EST, and will require
the assistance of IMP-site personnel at each site.

私たちは、IMP Systemの新しいバージョン、バージョン2514をインストールするのを計画しています。 新しいバージョンは、1972年1月13日木曜日に分野インストールのために正午と東部標準時午後1時の間で予定されて、各サイトでIMP-サイト人員の支援を必要とするでしょう。

    There were two principal problems with version 2513, both related
to the delay inserted between the time when a Host comes up and the
time when its IMP will accept the second packet from the Host.  The
first was that the delay was lengthened to slightly over 40 seconds,
which caused hardware difficulties for some Hosts.  The second was
that there was an ambiguity that could make the delay run as long as a
minute and a quarter.  On the first point, the delay has been backed
off from 40 seconds to 30 seconds, as it was for IMP systems prior to
2513.  On the second point, the ambiguity has been entirely removed.
(Note, however, that BBN Report No. 1822, on page 23, specifies that
the delay may range from 30 to 90 seconds, and that future versions
may require a longer delay.)

バージョン2513(Hostが来る時、IMPがHostから2番目のパケットを受け入れる時の間に挿入された遅れに関連する両方)に関する2つの主要な問題がありました。 1番目は遅れが40秒余りまで伸されたということでした。(秒はいくつかのHostsのためにハードウェア困難を引き起こしました)。 2番目は遅れが1分と四半期と同じくらい長い間走ることができたあいまいさがあったということでした。 最初のポイントに、遅れは40秒から30秒まで戻されました、2513年前にそれがIMPシステムのためのものであったときに。 2番目のポイントの上では、あいまいさを完全に取り除きました。 (しかしながら、BBN Report No.1822が、23ページで遅れが30〜90秒に及ぶかもしれなくて、将来のバージョンが、より長い遅れを必要とするかもしれないと指定することに注意してください。)

    In summary, a Host may come alive in one of two ways, corres-
ponding to the two ways in which the Host can go down.  If the Host
went down voluntarily (by sending a "Host going down" to the IMP), the
Host indicates his intention to come alive by sending the IMP
something.  If the Host went down involuntarily (by dropping his ready
line), the Host indicates his intention to come alive by bringing his
ready line back up.  In either case

概要では、Hostは2つの方法(Hostが落ちることができる2つの方法に池になるcorres)の1つで本物に見えるかもしれません。 Hostが自発的(「落ちるホスト」をIMPに送ることによって)に落ちたなら、Hostは何かをIMPに送ることによって本物に見えるという彼の意志を示します。 Hostが心ならずも(彼の持ち合わせの線を落とすことによって)落ちたなら、Hostは彼の持ち合わせの線背中を持って来ることによって本物に見えるという彼の意志を示します。 どちらかの場合で

                                                                [Page 1]

the IMP will refuse to accept more than one packet from the Host for
30 seconds after the Host has indicated his intention to come alive.
Notice, however, that the Host must be prepared to accept all messages
from the Network from the instant that he indicates his intention to
come alive.* This particular point seems to have given many Hosts
difficulty in running through their standard initialization
procedures.  Don't forget this simple and universal rule, that when
you are telling your IMP that you are alive, you must be prepared to
always take every- thing from the Network whether or not the Network
is taking any- thing from you.

[1ページ] IMPは、Hostが本物に見えるという彼の意志を示した後に30秒間、Hostから1つ以上のパケットを受け入れるのを拒否するでしょう。 しかしながら、Networkから彼が本物に見えるという意志を示す瞬間からすべてのメッセージを受け入れるようにHostを準備しなければならないのに注意してください。*この特定のポイントは彼らの標準の初期化手順をざっと読むことにおける苦労を多くのHostsに与えたように思えます。 いつも取るために、あなたが、生きているとIMPに言っているとき、用意ができていなければならないというこの簡単で普遍的な規則を忘れないでください、あらゆる、-、Networkからのもの、Networkが取っている、いくらか、あなたからのもの。

    Version 2514 will also incorporate a few other changes, mainly
related to the operation of the NCC.  Since the Timeout is, for a
change, being made shorter, and the other modifications are minor,
there should be no appreciable transient with the coming of the new
version.

また、バージョン2514はNCCの操作に主に関連する他のいくつかの変化を取り入れるでしょう。 より短く作られていながらTimeoutが変化のためのものであり、他の変更が小さい方であるので、かなりの新しいバージョンの来ることで一時的なノーがあるべきです。

_______________
*In fact, if the Host does not accept messages from his IMP
pimmediately then the Host may see the IMP's Ready line go down
for 1/4 second sometime during the 30 second waiting period.
This is due to the following set of circumstances:

_______________ *事実上、Hostが彼のIMP pimmediatelyからメッセージを受け入れないなら、Hostは、IMPのReady線が30 2番目の待ちの期間のうちに1/4秒間、落ちるのを見るかもしれません。 これは以下のセットの事情のためです:

    *  The IMP periodically places NOPs on the queue for a
       dead Host as part of the process of checking the IMP/Host
       interface.

* IMPは死んでいるHostのためにIMP/ホスト・インターフェースをチェックする過程の一部として定期的に待ち行列にNOPsを置きます。

    *  If a message remains on a Host's queue for 30 seconds
       without being taken, the IMP drops its Ready line for
       1/4 second in order to clear the interface (see RFC #270).

* 30秒間、メッセージが取らないでHostの待ち行列に残っているなら、IMPは、インタフェースをクリアするために1/4秒間、Ready線を落とします(RFC#270を見てください)。

    *  The timeout periods for the Host queue and the delay
       when the Host comes alive are _not_ synchronized.

* Host待ち行列と遅れのためのHostが本物に見えるタイムアウト時間はどんな_も連動させなかった_です。

If the Host is prepared to see the IMP's Ready line dropped
during the 30-second delay while coming alive, then no harm
will be done if messages from the IMP are not accepted immediately.

IMPのReady線が30秒の遅れの間、落とされるのを本物に見えている間、見るようにHostを準備して、すぐにIMPからのメッセージを受け入れないと、害を全く加えないでしょう。

BC/jm

紀元前/jm

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 12/96 ]

                                                                [Page 2]

[2ページ]