RFC410 日本語訳

Network Working Group                      John M. McQuillan
Request for Comments #410                  Bolt Beranek and Newman
NIC #12402                                 10 November 1972
Categories:  B-1

コメント#410のボルトBeranekとニューマンNIC#12402の1972年11月10日のカテゴリを求めるワーキンググループジョンのM.マッキランの要求をネットワークでつないでください: B-1

           Removal of the 30-Second Delay When Hosts Come Up
           -------------------------------------------------

ホストが来るときの30秒の遅れの取り外し-------------------------------------------------

     The IMP currently delays accepting input from a Host for 30
seconds after the Host has come up.  This delay serves to allow
the fact that the Host is up to propagate through the network.
The fundamental problem is that a Host must not be permitted
to communicate with a second Host until the second Host
(actually its IMP) has been made aware that the first Host is
up.  Otherwise, one Host may come up and send a "hello"
message to another Host, whose reply is discarded by the IMP
because it is for a dead destination.

IMPは、現在、Hostが来た後に30秒間、Hostから入力を受け入れるのを遅らせます。 この遅れは、Hostが上がっているという事実がネットワークを通して伝播されるのを許容するのに役立ちます。 基本的な問題はHostが第2Host(実際にIMP)を最初のHostが上がっているのを意識するようにするまで第2のHostとコミュニケートすることが許可されてはいけないということです。 さもなければ、1Hostが死んでいる目的地にはそれがあるので回答がIMPによって捨てられる別のHostに「こんにちは」メッセージを来て、送るかもしれません。

     All this reasoning is based on a dead destination de-
tection mechanism at the source IMP.  The 30-second delay is
based on the worst-case propagation delay for routing information
in the network, so that every potential source IMP can update
its host up/down table.  There are several drawbacks to this
scheme:

このすべての推理がソースIMPで死んでいる目的地反-tectionメカニズムに基づいています。 30秒の遅れはネットワークでルーティング情報のための最悪の場合伝播遅延に基づいています、あらゆる潜在的ソースIMPが/下にテーブルにホストをアップデートできるように。 この計画へのいくつかの欠点があります:

         1.  Hosts should not have to wait the worst-case time
             of 30 seconds to send to Hosts at their IMP or
             nearby in the network.

1. ホストは30秒が彼らのIMPにおいて近くにネットワークでHostsに発信する最悪の場合時間を待つ必要はないはずです。

         2.  The operation of half-duplex interfaces is made
             even more complicated because of the startup delay.

2. 半二重インタフェースの操作を始動遅れのためにさらに複雑にします。

         3.  The timeout period of 30 seconds is really a
             function of network topology and we would like to
             be able to change it when necessary as the network
             expands.

3. 30秒のタイムアウト時間は本当にネットワーク形態の機能です、そして、必要であるときに、ネットワークが広がるのに従って、それを変えたいと思います。

     We propose to eliminate the 30-second delay altogether.
The IMP subnetwork will detect messages for a dead Host at the
destination IMP instead of at the source IMP.  There is no delay

私たちは、全体で30秒の遅れを排除するよう提案します。 IMPサブネットワークはソースIMPの代わりに目的地IMPの死んでいるHostへのメッセージを検出するでしょう。 遅れが全くありません。

                                                                [Page 1]

involved for an IMP to sense when its own Hosts come up, so
that it can always make the correct decision about whether to
give a message to one of its Hosts or to return a destination
dead message to the source Host.  Under this new scheme, when-
ever the IMP's ready line is up it is ready to accept input
from its Hosts without delay.  Several comments on this change
should be noted:

いつもHostsの1つに口上を述べるか、または目的地の死んでいるメッセージをソースに返すかに関する正しい決定をHostにすることができて、IMPが、それ自身のHostsがいつ来るかを感じるようにかかわる[1ページ。] この新しい計画の下でいつ、-、かつて、IMPの持ち合わせの線はHostsから即刻入力されて、それが受け入れる準備ができている上であるか。 この変化のいくつかのコメントが注意されるべきです:

         1.  No change to Host software should be necessitated
             by this change.  The Host may attempt to send a
             message to the IMP as soon as it brings its
             ready line up, or it may delay for a long time.  In
             either case, the IMP will take the message.  As
             before, as soon as the Host has brought up its
             ready line, it must accept messages from the IMP.

1. この変化はHostソフトウェアへの変化を全く必要とするべきではありません。 持ち合わせの線を持って来るとすぐに、Hostが、メッセージをIMPに送るのを試みるかもしれませんか、またはそれは長い間、延着するかもしれません。 どちらの場合ではも、IMPは伝言を受け取るでしょう。 従来と同様、Hostが持ち合わせの線を持って来るとすぐに、それはIMPからメッセージを受け入れなければなりません。

         2.  The Hosts may wish to remove any delays _they_ have
             programmed into their startup routines, since
             such delays are no longer necessary.

2. Hostsがどんな遅れ_も取り外したがっているかもしれない、それら、_は彼らの始動ルーチンにプログラムを作りました、そのような遅れがもう必要でないので。

         3.  Destination dead messages will be returned as
             before with two differences.  There will be more
             delay between the receipt of the message at the
             IMP and the return of the dead destination message
             because it must travel through the network.  For
             the same reason, if many messages are sent to
             dead Hosts, the dead destination messages may come
             back out of order.

3. 従来と同様2つの違いと共に目的地の死んでいるメッセージを返すでしょう。 ネットワークを通って移動しなければならないので、IMPのメッセージの領収書と死んでいる目的地メッセージの復帰の間で、より多く遅れるでしょう。 同じ理由から、多くのメッセージを死んでいるHostsに送るなら、死んでいる目的地メッセージは故障していた状態で戻るかもしれません。

     The Host personnel responsible for the IMP software at
each site should check that this proposed change will not ad-
versely affect them.  If no adverse comments are received,
this change will go into effect on Tuesday morning, December
12 at the regular IMP software release time.

各サイトのIMPソフトウェアに責任があるHost人員は、どんなこの変更案意志の広告詩も彼らに影響しないのをチェックするべきです。 どんな不利なコメントも受け取られていないと、この変化は火曜日の朝実施されるでしょう、12月12日の通常のIMPソフトウェアリリース時間に。

  [ 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 2]

[2ページ]