RFC117 日本語訳

Network Working Group                                          J. Wong
Request for Comments: 117                                         UCLA
NIC #5826                                                 7 April 1971

コメントを求めるワーキンググループJ.ウォン要求をネットワークでつないでください: 117 UCLA NIC#5826 1971年4月7日

                 Some Comments on the Official Protocol

公式のプロトコルのいくつかのコメント

               [Categories B.1, C.1, C.2, C.3, C.4, C.5]

[カテゴリB.1、C.1、C.2、C.3、C.4、C.5]

 Document No. 1 and NWG/RFC No. 107 gave a very detailed description of
connection establishment, connection termination and flow control over
the Network.  Throughout the implementation of the NCP it was
discovered that the handling of ERR control commands, messages of
types other than 0 (regular), 4 (nop), and 5 (rfnm), and messages with
the From-imp bit on are not well discussed so that problems arise when
they occur.

ドキュメントNo.1とNWG/RFC No.107はコネクション確立、接続終了、およびフロー制御の非常に詳細な記述をNetworkの上に与えました。 NCPの実現の間中、起こると5つのERR制御コマンドの取り扱い、0(通常の)以外のタイプに関するメッセージ、4(nop)、(rfnm)、およびFrom-悪童ビットがオンのメッセージについてよく議論しないので問題が起こると発見されました。

The Protocol is not complete if the above situations are not handled
clearly, and the Host-Host Protocol Glitch Cleaning Committee should
take this into consideration.  In this document, experience with these
unfavorable situations and suggestions for handling are given:

上の状況が明確に扱われないなら、プロトコルは完全ではありません、そして、Host-ホストプロトコルGlitch Cleaning Committeeはこれを考慮に入れるはずです。 本書では、これらの好ましくない状況の経験と取り扱いのための提案を与えます:

1.  ERR Control Commands

1. 間違え、制御コマンド

In Document No. 1, the following error conditions are described:

Document No.1では、以下のエラー条件は説明されます:

     a.  Illegal Op. code.
     b.  End of message encountered before all expected parameters.
     c.  Bad socket polarity within commands.
     d.  Link number not in the range of 0 <= L < 32.
     e.  A request (other than RTS/STR) on a non-existent socket.
     f.  A request (ALL, GVB, RET, INR, INS) on a non-existent link
         number.
     g.  Transmit over non-existent link number.

a。 不法なOpコードb。 すべてがパラメタcを予想する前に遭遇するメッセージの終わり。 コマンドdの中の悪いソケットの極性。 リンク番号は0<の範囲でL<32eと等しくはありません。 a実在しないソケットfに関する要求(RTS/STRを除いた)。 a実在しないリンク番号gに関する要求(GVB、RET、INR、INS)。 実在しないリンク番号の上伝わってください。

Other error conditions are:

他のエラー条件は以下の通りです。

     h.  A request (GVB, RET, INR, INS) on an existent link, but
         connection is not established.

h。 目下のリンクに関する要求(GVB、RET、INR、INS)、しかし、接続は確立されません。

                                                                [Page 1]

     i.  Transmit over an existent link, but connection is not
         established.
     j.  ALL or GVB on a send connection.
     k.  RET on a receive connection.
     l.  An attempt to send more than the allocated number of bits or
         messages.
     m.  ECO, ERP, ERR commands do not have the defined number of bits
        of data.

[1ページ] i。 目下のリンクの上に伝わってくださいが、接続は伝わります。. jを設立しませんでした。 aのすべてかGVBが接続kを送ります。 aのRETは接続lを受けます。 ビットかメッセージmの割り当てられた数より発信する試み。 ECO(ERP)には、ビットのデータの定義された数がありませんERRが、命令する。

In Document No. 1, each site is supposed to document the information
on their ERR command.  No one has done that so far, and the main
reason is we are not sure of what information is important.  In
NWG/RFC No. 107, the text portion of the ERR Commands is decided to
have a fixed length of 80 bits because 80 bits is long enough to hold
the longest non-ERR command.  In some of the above error conditions,
more information than the command itself is desirable.  It was noted
that these error conditions arise very often in the experimental stage
of the NCP.  If every NCP is operating properly, none of them should
ever occur.  The ERR commands are therefore, an excellent debugging
tool for the protocol.  So it is desirable to define a set of possible
error conditions, and for each condition, define a set of arguments in
the corresponding ERR command so that enough information is given to
tell what's wrong.  The suggested arguments for each situation (a - m)
are listed below:

Document No.1では、各サイトは彼らのERRコマンドの情報を記録するべきです。 だれもそんなに今までのところしていません、そして、主な理由は私たちがどんな情報が重要であるかを確信していないということです。 NWG/RFC No.107では、ERR Commandsのテキスト一部が、80ビットが最も長い非ERRコマンドを保持できるくらい長いので80ビットの固定長を持つために決められます。 上のエラー条件のいくつかでは、コマンドより多くの情報自体が望ましいです。 これらのエラー条件がNCPの実験の域に頻繁に起こることに注意されました。 あらゆるNCPが適切に作動しているなら、それらのいずれも起こるべきではありません。 したがって、ERRコマンドはプロトコルのための素晴らしいデバッグ用ツールです。 それで、1セットの可能なエラー条件を定義して、各状態のために対応するERRコマンドにおける、1セットの議論を定義してください。そうすれば、何が問題であるかを言うために十分な情報を与えるのは望ましいです。 各状況(a--m)のための提案された議論は以下に記載されています:

     a.  1.  Op. code in error.
         2.  Part of message following op. code (A maximum of 72
             bits).

a。 1. オプアート間違いコード。 2. メッセージの次のオプアートコード(最大72ビット)の一部。

     b, c, d, e, f.
         1.  The command in error.

b、c、d、e、f。 1. 間違いコマンド。

     g.  1.  Link number,
         2.  Beginning of message (A maximum of 72 bits),

g。 1. 数、2をリンクしてください。 メッセージ(最大72ビット)の始まり

     h.  1.  Command in error.
         2.  Socket numbers for the connection.
         3.  Status of the connection.

h。 1. 間違って命令してください。 2. 接続のソケット番号。 3. 接続の状態。

                                                                [Page 2]

     i.  1.  Link number,
         2.  Beginning of message (A maximum of 72 bits),
         3.  Socket numbers for the connection.
         4.  Status of the connection.

[2ページ] i。 1. 数、2をリンクしてください。 メッセージ(最大72ビット)の始まり、3。 接続のソケット番号。 4. 接続の状態。

     j, k.
         1.  Command in error.
         2.  Socket numbers for the connection.

j、k。 1. 間違って命令してください。 2. 接続のソケット番号。

     l.  1.  Link number.
         2.  Beginning of message (A maximum of 72 bits).
         3.  Number of bits sent.
         4.  Number of bits allocated.
         5.  Number of messages allocated.

l。 1. 数をリンクしてください。 2. メッセージ(最大72ビット)の始まり。 3. ビットの数は発信しました。 4. 割り当てられたビットの数。 5. 割り当てられたメッセージの数。

     m.  1.  The Command in error.

m。 1. 間違いCommand。

Each of the ERR commands should have a special error code (8 bits) to
tell the error type, an 80-bits field to store the command in error,
and additional fields for socket numbers and other information.

それぞれのERRコマンドには、誤りタイプ(誤りにおけるコマンド、およびソケット番号と他の情報のための追加野原を格納する80ビットの分野)に言うために、特別なエラーコードがあるべきです(8ビット)。

2.  Imp-to-host messages of types other than 0, 4, and 5.

2. 0、4、および5以外のタイプに関する悪童からホストへのメッセージ。

From the BBN report 1822, the following message types will cause
difficulty in the implementation of the Protocol.

BBNレポート1822から、以下のメッセージタイプはプロトコルの実現における困難を引き起こすでしょう。

     a.  Type 2 - Imp going down.
     b.  Type 7 - Destination host or imp dead.
     c.  Type 9 - Incomplete transmission.

a。 2をタイプしてください--. bを下る悪童。 7をタイプしてください--あて先ホストか悪童死者c。 9をタイプしてください--不完全なトランスミッション。

It was discovered that on sending a message to a site whose imp or
host is not running, a Type 7 or Type 9 message is returned.  This
can happen in two situations:

悪童かホストが走っていないサイトにメッセージを送るときType7かType9メッセージが返されると発見されました。 これは2つの状況で起こることができます:

     a.  The foreign host or imp is not up at all.
     b.  Some connections have been established, and the foreign host
         or imp goes down.

a。 異種宿主か悪童が. bで起きていません。 何人かの接続が確立されました、そして、異種宿主か悪童が落ちます。

                                                                [Page 3]

The first situation does not cause much problem because the NCP has no
entry in its table corresponding to this site.

[3ページ] NCPがこのサイトに対応するテーブルにエントリーを全く持っていないので、最初の状況は多くの問題を引き起こしません。

The second situation is more complicated, because if the table entries
for the connections to the dead host are not cleared, by the time this
host comes up again, the table entries still exist and the information
will be very misleading.  One suggestion to solve this problem is:

2番目の状況は、より複雑です、死んでいるホストとの接続のためのテーブル項目がクリアされないなら、このホストが再び来る時までにテーブル項目がまだ存在していて、情報が非常に紛らわしくなるので。 この問題を解決する1つの提案は以下の通りです。

     a.  Whenever a NCP comes up, it send a RESET Control Command to
         every other site.
     b.  Associated with each site there is a bit called the up-bit.
         If a RESET-reply command is received from some site, the
         corresponding up-bit is set to 1.  Race condition can be
         avoided by ignoring all messages from sites which have not
         returned the RESET-reply command.
     c.  Messages can only be sent to sites with the up-bit on.
     d.  If a RESET control command is received, the Table entries
         corresponding to the site are cleared, a RESET-reply is
         immediately returned, and the up-bit for the site is set.
     e.  The up-bit is reset to 0 when a Type 7 or Type 9 message is
         received from a particular site.

a。 NCPが来て、あらゆるもう一方にRESET Control Commandを送るときはいつも. bを位置させてください。 各サイトに関連づけられて、上がっているビットは少し呼ばれます。 何らかのサイトからRESET-応答コマンドを受け取るなら、対応する上がっているビットを1に設定します。 RESET-reply command. cを返していないサイトからのすべてのメッセージを無視することによって、競合条件を避けることができます。 上がっているビットが. dにある状態で、メッセージをサイトに送ることができるだけです。 RESET制御コマンドが受け取られているなら、サイトに対応するTableエントリーはクリアされます、そして、すぐにRESET-回答を返します、そして、サイトへの上がっているビットは. eを設定することです。 特定のサイトからType7かType9メッセージを受け取るとき、上がっているビットを0にリセットします。

The above solution will handle the Type 2 messages also.  When a host
receives a Type 2 message, there is no way for it to tell the other
NCP's that its imp is going down.  Subsequent messages to this host
will return a Type 7 or 9 message.  The solution above will then come
into effect.

上の解決策はType2メッセージも扱うでしょう。 ホストがType2メッセージを受け取るとき、悪童が落ちる予定であるとNCPのもう片方のものに言う方法が全くありません。 このホストへのその後のメッセージはType7か9メッセージを返すでしょう。 そして、上の解決策は実施されるでしょう。

                                                                [Page 4]

With the introduction of the RESET and RESET-reply Control command,
the ECO and ERP control command are no longer important and should be
removed.

RESETの導入がある[4ページ]、RESET-回答Control命令、ECO、およびERP制御コマンドは、もう重要でなく、取り外されるべきです。

3.  Messages with the From-imp bit on.

3. From-悪童がいるメッセージは取り組みました。

These kinds of messages are not discussed at all.  Some statistical
measurements have been made on messages with the From-imp bit on.  We
should classify what these messages represent.

これらの種類に関するメッセージについて全く議論しません。 メッセージでFrom-悪童ビットがオンな状態でいくつかの統計的測定をしました。 私たちはこれらのメッセージが表すことを分類するべきです。

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Randy Dunlap 4/97]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ランディ・ダンラップ4/97によるオンラインRFCアーカイブへの]

                                                                [Page 5]

[5ページ]