RFC381 日本語訳
0381 Three aids to improved network operation. J.M. McQuillan. July 1972. (Format: TXT=9305 bytes) (Updated by RFC0394) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. McQuillan
Request for Comments: 381 D. Walden
NIC: 11151 Bolt Beranek and Newman Inc.
26 July 1972
コメントを求めるワーキンググループJ.マッキランの要求をネットワークでつないでください: 381 D.ウォルデンNIC: 11151 ボルトBeranekとニューマン株式会社1972年7月26日
Three Aids To Improved Network Operation
改良されたネットワーク操作への3つの援助
1. Scheduled Software Maintenance
1. 予定されているソフトウェア・メンテナンス
As the ARPA Network has grown larger, we have found it difficult to find times when necessary new software can be slipped into the network without disrupting anyone. For instance, there is always intrasite traffic between the machines at MIT, and there is almost always traffic between the AMES TIP and IMP--the sun never sets on the ARPA Network. To minimize unscheduled disruptions and to simultaneously let us do what we have to do, we propose to schedule 7 A.M. - 8 A.M. eastern time every Tuesday as a time when the IMPs can be reloaded. We will probably not use this period every Tuesday, but we do reserve this period every Tuesday. The above period is in addition to the several hours a month already scheduled at each site for hardware preventative maintenance.
アーパネットが大きくなったとき、私たちは、必要な新しいソフトウェアがだれも混乱させないでネットワークに滑り込むことができる回を見つけるのが難しいのがわかりました。 AMES TIPとIMPの間には、交通がほとんどいつもあります--例えば、intrasite交通がMITにマシンの間にいつもあります、そして、太陽はアーパネットに決して沈みません。 予定外の分裂を最小にして、同時に私たちがしなければならないことをしようというために、私たちは、午前7時の計画をするよう提案します--毎週火曜日のIMPsを再び積むことができる時としての午前8時の東時間。 毎週火曜日にたぶんこの期間を費やすつもりではありませんが、私たちは毎週火曜日にこの期間を取っておきます。 上の期間は1カ月がハードウェア予防薬メンテナンスのために各サイトで既に計画をした数時間に加えています。
Because a network user may not know when his machine is scheduled for maintenance or because he may forget and work through the Tuesday morning software period, we propose to generalize the IMP-Going-Down IMP-to-Host control message so it may be used to remind the user. This message (described in detail below) will contain information that the IMP is going down in m times five minutes, for n times 5 minutes, for a given reason. Hosts (and the TIP) should use this information to remind all their Network users that the IMP will be going down after the stated interval.
彼が火曜日の朝のソフトウェアの期間をネットワーク利用者が、彼のマシンがいつメンテナンスのために予定されているかを知らないか、忘れて、または終えるかもしれないので、私たちが、落ちるIMP IMPからホストへのコントロールメッセージを広めるよう提案するので、それはユーザに思い出させるのに使用されるかもしれません。 このメッセージ(以下で詳細に説明される)はIMPがm回5分で落ちる予定であるという情報を含むでしょう、n回5分間、与えられた理由で。 ホスト(そして、TIP)は、IMPが述べられた間隔の後に落ちるのを彼らのすべてのNetworkユーザに思い出させるのにこの情報を使用するべきです。
Occasionally there is an emergency reason for restarting or reloading an IMP. For instance, while three Hosts at a site are functioning well, one Host cannot communicate with the IMP. This sort of situation sometimes requires the IMP to be restarted. Such a restart will be preceded by several minutes by an IMP-Going-Down Message to allow working users to save their work in such a way that they can restart once the IMP is back up.
IMPを再開するか、または再び積む非常時の理由が時折あります。 例えば、サイトの3Hostsがよく機能している間、1HostはIMPとコミュニケートできません。 この種類の状況は、時々IMPが再開されるのを必要とします。 再開が働くユーザがIMPがいったん戻るようになると彼らが再開できるような方法における彼らの仕事を救うのを許容するために数分までに落ちるIMP Messageによって先行されるそのようなもの。
In both of these cases, as well as cases where an IMP is performing so poorly that is must be shut down quickly, a type 2 IMP-to-HOST message will be transmitted to the HOST about 30 seconds before the IMP goes down. Finally, of course, there may be occasions when the IMP crashes so quickly that no warning is given, but the IMP will never be intentionally shut down in this way.
また、これらのケースの両方では、すぐに、それがIMPがあまりに不十分に働いているからであるケースを止めなければならないとき、IMPが落ちるおよそ30秒前にタイプ2IMPからHOSTへのメッセージはHOSTに送られるでしょう。 最終的に、IMPが非常に急速にクラッシュするので警告でないのを与えますが、故意にIMPを決してこのように止めない時がもちろんあるかもしれません。
Mc Quillan, et. al. [Page 1] RFC 381 Three Aids To Improved Network Operation 26 July 1972
et mc Quillan、アル。 [1ページ] 改良されたネットワーク操作1972年7月26日へのRFC381 3つの援助
2. IMP-to-Host Communication
2. 悪童からホストへのコミュニケーション
There have long been complaints that the IMP-to-Host error messages were not precise enough or were just plain ambiguous. In RFC #312 we proposed some additional error messages. These and other IMP-to-Host message changes will be made on August 14, 1972 and we encourage Hosts to modify their NCP's as appropriate by then. Unmodified NCPs will probably continue to work after this change, but each site should look into this question carefully. The table below lists all the IMP-to-Host messages and clearly indicates the changes which will be made.
IMPからホストへのエラーメッセージがそうでなかった苦情が長く十分正確な状態でありましたか、まさしく平野はあいまいでしたか? RFC#312では、私たちはいくつかの追加エラーメッセージを提案しました。 これらとIMPからホストへのメッセージ他の変更は1972年8月14日に行われるでしょう、そして、私たちはHostsがその時までに適宜彼らのNCPのものを変更するよう奨励します。 変更されていないNCPは、この変化の後にたぶん働き続けるでしょうが、各サイトは慎重にこの質問を調べるべきです。 以下のテーブルは、IMPからホストへのすべてのメッセージをリストアップして、明確に行われる変更を示します。
Type Old Meaning New Meaning
古い意味新しい意味をタイプしてください。
0 Regular Messages Same
0レギュラーは同じ状態で通信します。
1 Error without Error in Leader of Host-to-
identification IMP Message
Bits 31,32=00 - IMP's
error flip-flop set on
the first 32 bits of a
Host-to-IMP message which
the IMP therefore cannot
identify
Bits 31,32=01 - Host-to-IMP
message too short (less
than 32 bits)
Bits 31,32=10 - illegal
Host-to-IMP code
1 Hostから識別へのIMP Message Bits31のLeaderのErrorのない誤り、32=00に、したがってIMPがそうすることができないHostからIMPへのメッセージの最初の32ビットの上に設定されたIMPの誤りフリップフロップはBits31、32=01--ホストからIMPへのメッセージ脆過ぎる(32ビット未満)ビット31、32=10--HostからIMPへの不法なコードを特定します。
2 IMP Going Down IMP Going Down
Bits 17-32 coded as follows:
All bits zero - going down in
30 sec.
Bits 17,18=01 - scheduled
hardware PM
Bits 17,18=10 - scheduled
software reload
Bits 17,18=11 - emergency
reload or restart
Bits 19-22 - how soon the
IMP is going down - in
5 minute units
Bits 23-32 - how long the IMP
will be down - in 5
minute units
以下の通りコード化された2IMP Going Down IMP Going Down Bits17-32: 30秒以降落ちて、ビットが合っているゼロすべて 18=01--予定されているハードウェアPM Bits17、18=10--ビット17、予定されているソフトウェアは5分のユニットにBits17、18=11--非常時の再ロードか再開Bits19-22--すぐIMPが5分のユニットBits23-32でどう落ちるかを(IMPがどれくらい長くなるかはダウンします)再び積みます。
3 Blocked Link Unassigned
妨げられたリンクが割り当てなかった3
Mc Quillan, et. al. [Page 2] RFC 381 Three Aids To Improved Network Operation 26 July 1972
et mc Quillan、アル。 [2ページ] 改良されたネットワーク操作1972年7月26日へのRFC381 3つの援助
4 NOF Same
4NOF同じです。
5 RFNM Same
5RFNM同じです。
6 Link Table Full Unassigned
6は割り当てられなくテーブルをいっぱいにリンクします。
7 Destination Dead Destination Dead
Bit 32=0 - the destination
IMP is dead, or cannot be
reached, or does not exist
Bit 32=1 - the destination
Host is dead or does not
exist
7目的地Dead Destination Dead Bit、目的地IMPが32=0に、死んでいるか、達することができませんし、存在もしていない、Bit、目的地Hostは32=1に、死んでいるか、または存在していません。
8 Error with identi- Error in Data of Host-to IMP
fication Message
IMP's error flip-flop set
on the data bits of a Host-
to-IMP message identified
by the given source and link
identi誤りがDataにある8誤り、Host、-、IMP fication Message IMPの誤りフリップフロップはIMPへの与えられたソースとリンクによって特定されたHostメッセージのデータ・ビットの上にセットしました。
9 Incomplete Transmission Incomplete Transmission
Bits 31,32=00 - the destination
Host did not take the message
for a long time
Bits 31,32=01 - Host-to-IMP
message too long (more
than 8095 bits)
Bits 31,32=10 - Host-to IMP
message too slow. The
last message took more
than 15 secs. between
the first bit and the
last bit, and was discarded
Bits 31,32=11 - Host-to-
IMP message lost in the
subnet
9不完全なTransmission Incomplete Transmission Bits31、32=00に、目的地Hostが長い間のメッセージBits31、32=01(ホストからIMPへのメッセージ長過ぎる(8095ビット以上)ビット31、32=10)を取らなかった、ホスト、-、IMPは遅過ぎる状態で通信します。 最後のメッセージは15以上secsを取りました。最初のビットと最終の間には、捨てられたBits31は噛み付いて、ありました、32=11--ホストからIMPへのメッセージはサブネットで失われました。
Mc Quillan, et. al. [Page 3] RFC 381 Three Aids To Improved Network Operation 26 July 1972
et mc Quillan、アル。 [3ページ] 改良されたネットワーク操作1972年7月26日へのRFC381 3つの援助
10 Unassigned IMP-Host Interface Reset
The IMP's ready line has
been dropped and pending
output to the Host discarded
(probably because the Host
has not taken messages from
the IMP for a long time).
The IMP will return a type 1
message of subtype 0 at the
completion of the next Host-
to-IMP message.
10 割り当てられなかったIMP-ホストInterface Reset IMPの持ち合わせの線は落とされて、Hostへの未定の出力は捨てられました(たぶんHostが長い間IMPから伝言を受け取ていないので)。 IMPはIMPへの次のHostメッセージの完成のときに「副-タイプ」0に関する1つのメッセージをタイプに返すでしょう。
These changes can be summarized as follows:
以下の通りこれらの変化をまとめることができます:
1. There is now one and only one IMP-to-Host message in response to
each Host-to-IMP regular message.
1. 1つのIMPからホストへの唯一無二のメッセージが現在、HostからIMPへのそれぞれの通常のメッセージに対応しています。
2. Message types 1, 2, 7 and 9 now carry additional information.
2. メッセージタイプ1、2、7、および9は今、追加情報を運びます。
3. Message type 10 has been added.
3. メッセージタイプ10は加えられます。
4. Message types 3 and 6 have been discarded.
4. メッセージタイプ3と6は捨てられました。
3. Network News Service
3. ネットニュースサービス
We have instituted a Network news service. TIP users get the news by typing the TIP command @NEWS. Users of other Host can get the news by ICPing to socket 15600031 (octal) at the BBN Tenex.
私たちはNetwork通信社を設けました。 TIPユーザは、TIPコマンド@NEWSをタイプすることによって、ニュースを得ます。 他のHostのユーザはICPingでBBN Tenexのソケット15600031(8進)にニュースを得ることができます。
If you have further suggestions for improving the operation of the Network, we request your comments.
Networkの操作を改良するためのさらなる提案がありましたら、私たちはあなたのコメントを要求します。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Lorrie Shiota 08/00]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田08/00によるオンラインRFCアーカイブへの]
Mc Quillan, et. al. [Page 4]
et mc Quillan、アル。 [4ページ]
一覧
スポンサーリンク
