RFC102 日本語訳

Network Working Group                            Steve Crocker, Chairman
Request for Comments: 102                              at BBN, Cambridge
NIC#5763                                            22, 23 February 1971

ワーキンググループのスティーブ・クロッカー、コメントを求める議長Requestをネットワークでつないでください: 102 BBN、ケンブリッジNIC#5763 22 1971年2月23日に

                    OUTPUT OF THE HOST/HOST PROTOCOL
                       GLITCH CLEANING COMMITTEE

ホスト/ホストプロトコル不調掃除委員会の出力

   At the NWG meeting in Urbana on 17-19 February 1971, a
   committee was established to look at the Host/Host protocol
   and see what changes were immediately desirable or necessary.

1971年2月17-19日のアーバナでのNWGミーティングでは、委員会は、Host/ホストプロトコルを見て、どんな変化がすぐに、望ましいか、または必要であったかを確認するために設立されました。

   The committee is chaired by Steve Crocker, and has eight
   other members:

委員会には、スティーブ・クロッカーによってまとめられて、他の8人のメンバーがいます:

             Ray Tomlinson                 BBN (Tenex)

レイトムリンスンBBN(Tenex)

             Jim White                     UCSB

ジムホワイトUCSB

             Gary Grossman                 Illinois

ゲーリー・グロースマン・イリノイ

             Tom Barkalow                  Lincoln (TX2)

トム・Barkalowリンカーン(TX2)

             Will Crowther                 BBN (IMPs)

ウィルクラウザーBBN(悪童)

             Bob Bressler                  MIT (Dynamic Modeling

ボブBressler MIT、(ダイナミックなモデル

             Doug McKay                    IBM (Yorktown)

ダグマッケイIBM(ヨークタウン)

             Dan Murphy                    BBN (Tenex)

ダンマーフィーBBN(Tenex)

   A number of topics were discussed.  On some of these topics, a
   consensus was reached on whether or not to recommend a change, and if
   so, what the change should be.  On the remaining topics, specific
   alternatives were proposed but no consensus was reached.

多くの話題について議論しました。 これらの話題のいくつかでは、コンセンサスに変化を推薦するかどうかと、そうだとすれば、変化が何であるべきであるかに関して達しました。 残っている話題に関して、特定の代替手段は提案されましたが、コンセンサスに全く達しませんでした。

   The committee will immediately canvas the network community and
   gather reaction to its recommendations and the proposed alternatives.
   The committee will then reconvene at UCLA on 8 March 1971 and decide
   on final recommendations.  Steve Crocker will then write Document #2.
   This sequence is in lieu of the change procedure outlined in NWG/RFC
   53.

委員会はすぐに、推薦と提案された代替手段へのネットワーク共同体とギャザー反応をキャンバスに望んでいます。 委員会は、次に、1971年3月8日にUCLAで再召集して、最終勧告を決めるでしょう。 そして、スティーブ・クロッカーはDocument#2を書くでしょう。 この系列はNWG/RFC53に概説された変化手順の代わりにあります。

Crocker                                                         [Page 1]

RFC 102       HOST/HOST PROTOCOL GLITCH CLEANING COMMITTEE February 1971

委員会の1971年2月に掃除されるクロッカー[1ページ]RFC102ホスト/ホストプロトコル不調

   Specific Recommendations

特定の推薦

   1. The ECO and ERP command should each be 8 bits long.

1. ECOとERPコマンドはそれぞれ長さ8ビットであるべきです。

   2. The ERR command should be 96 bits long.

2. ERRコマンドは長さ96ビットであるべきです。

   3. Message Data Types should be eliminated.  Third-level protocol
      people may reinstate such a mechanism.

3. メッセージData Typesは排除されるべきです。 第3レベルプロトコルの人々はそのようなメカニズムを復職させるかもしれません。

   4. The Cease mechanism should be discontinued.

4. Ceaseメカニズムは中止されるべきです。

   5. A new pair of one byte commands RST (reset) and RRP (reset reply)
      should be added.  The RST should be interpreted as a signal to
      purge the NCP tables of any existing entries which arose from the
      sending Host.  The RRP command should be returned to acknowledge
      receipt of the RST.  The Host sending the RST may proceed after
      receiving either a RST or a RRP in return.  A RST may be returned
      if the second Host comes up after the first Host.

5. 1バイトのコマンドのRST(リセット)とRRP(リセット回答)の新しいペアは加えられるべきです。 RSTは、NCPテーブルから発信しているHostから起こったどんな既存のエントリーも一掃するために信号として解釈されるべきです。 RSTの領収書を受け取ったことを知らせるためにRRPコマンドを返すべきです。代わりにRSTかRRPのどちらかを受けた後に、RSTを送るHostは続くかもしれません。 第2Hostが最初のHostの後に来るなら、RSTを返すかもしれません。

   6. Although it was suggested at the Urbana meeting that connections
      should be full-duplex, the committee recommends against this
      change.

6. 委員会は、この変化に対してそれがアーバナに示されましたが、その接続に会うのが、全二重であるべきであることを推薦します。

   7. Messages should be an integral number of bytes, and the number of
      bytes and the byte size should be specified in each message.  The
      marking convention should be abandoned and the padding ignored.

7. メッセージは整数のバイトであるべきです、そして、バイト数とバイトサイズは各メッセージで指定されるべきです。 マークコンベンションは、捨てられて無視された詰め物であるべきです。

      The number of bytes in the message should be a 16-bit number
      following the leader.  The byte size should be in the next 8-bit
      field.  Two suggestions were generated for the starting point of
      the text, and these are explained in the next session.

メッセージのバイト数はリーダーに続く16ビットの数であるべきです。 バイトサイズが次の8ビットの分野にあるべきです。 2つの提案がテキストの出発点に発生しました、そして、これらは次のセッションのときに説明されます。

      For flow control purposes, the number of bits in a message is the
      product of the number of bytes and the byte size.  The leader and
      other fixed format fields are not counted.

フロー制御目的のために、メッセージのビットの数はバイト数とバイトサイズの製品です。 リーダーと他の固定フォーマット分野は数えられません。

   8. The problem of synchronizing the interrupt signal in a console
      input stream was considered.  We consider the console input
      scanner as a process and note two reasonable implementations: it
      may either read characters as fast as it can, looking for the
      interrupt character and throwing away characters if there is no
      room in the user process' input queue; it may read characters only
      as fast as the user process can receive them, (or at least has
      room for them).

8. コンソール入力ストリームで割り込み信号を同期させるという問題は考えられました。 私たちは、コンソール入力スキャナが過程であるとみなして、2つの合理的な実現に注意します: それはできるだけ速くキャラクタを読むかもしれません、ユーザ・プロセスの入力キューに余地が全くなければ、中断キャラクタを探して、キャラクタを無駄にして。 それがユーザ・プロセスが彼らを受けることができるのと同じくらい速くだけキャラクタを読むかもしれない、(または、彼らの余地を少なくとも持っています。)

   The first implementation guarantees that the interrupt character
   (e.g., control - C on the PDP-10 10/50) will always be acted on, but
   requires that the using process interpret the output stream to detect

最初の実現は、中断キャラクタ(例えば、コントロール--PDP-10 10/50のC)がいつも影響されるのを保証しますが、使用の過程が検出する出力ストリームの機械言語に翻訳処理をするのを必要とします。

Crocker                                                         [Page 2]

RFC 102       HOST/HOST PROTOCOL GLITCH CLEANING COMMITTEE February 1971

委員会の1971年2月に掃除されるクロッカー[2ページ]RFC102ホスト/ホストプロトコル不調

   when it is sending too fast.  The second implementation avoids
   overrun but may not allow for sending an interrupt code.  Note that
   in the first case, allocation is alway renewed as soon as possible by
   the console input interpreter; whereas in the second case, allocation
   is renewed only as the result of acceptance of data by the user
   process.

あまりに速く発信するとき。 2番目の実現は、超過を避けますが、中断コードを送ると考慮しないかもしれません。 前者の場合、配分ができるだけ早くコンソール入力インタプリタによって取り替えられたalwayであることに注意してください。 2番目の場合では、配分は単にユーザ・プロセスによるデータの承認の結果として更新されますが。

   We decided that this is really a third-level protocol matter, viz,
   use the INS to mean that a special code has been inserted into the
   input stream.  In conjunction with this, create the special code to
   be put into the input sequence.

私たちは、特別なコードを入力ストリームに挿入してあることを意味するためにこれが本当につまり第3レベルプロトコル問題であり、使用がINSであると決めました。 これに関連して特別なコードを作成して、入力系列に入れてください。

   This special code would be network-wide and independent of the
   particular interrupt character peculiar to the serving system.  The
   scheme for interrupting a serving process is that the using process
   inserts the serving Host's interrupt sequence, followed by the
   network special code, and also issue the INS.

この特別なコードは、給仕システムに独特の特定の中断キャラクタからネットワーク全体であって独立しているでしょう。 給仕の過程を中断することの計画は使用の過程が給仕Hostの中断系列を挿入するということです、とINSがネットワークの特別なコードで続いて、また、発行します。

UNRESOLVED ALTERNATIVES

未定の代替手段

   1. Length of Control Messages

1. コントロールメッセージの長さ

   In accordance with other specifications, control messages should be
   an integral number of 8-bit bytes, the length should be specified in
   the byte count field, and control commands should not be split across
   messages.

他の仕様に従って、コントロールメッセージは整数の8ビットのバイトであるべきです、そして、バイト・カウント分野で長さを指定するべきです、そして、メッセージの向こう側に制御コマンドを分けるべきではありません。

   Unresolved was whether to specially limit the length of control
   messages.  The two choices are.

未定であるのは、特に、コントロールメッセージの長さを制限するかどうかということでした。 2つの選択がそうです。

      a) no special limit ( ~ 1000 bytes)

a) 特別な限界がありません。(~1000バイト)

      b) 120 bytes

b) 120バイト

   2. Message Format

2. メッセージ・フォーマット

   It was agreed to abandon marking and include the text length in the
   form of a byte count and byte size.  Unresolved was where to begin
   the first byte of data.  The two choices are:

バイト・カウントとバイトサイズの形にマークを捨てて、テキストの長さを含むようにそれは同意されました。 未定であるのは、どこでデータの最初のバイトを始めるかということでした。 2つの選択は以下の通りです。

      a) have the first data byte begin after 72 bits of leader, byte
      count, byte size and spacing.  The message format would then be as
      in the diagram:

a) バイトがリーダーの72ビット後に始める最初のデータ、バイト・カウント、バイトサイズ、およびスペースを持ってください。 次に、メッセージ・フォーマットがダイヤグラムであるでしょう:

Crocker                                                         [Page 3]

RFC 102       HOST/HOST PROTOCOL GLITCH CLEANING COMMITTEE February 1971

委員会の1971年2月に掃除されるクロッカー[3ページ]RFC102ホスト/ホストプロトコル不調

                 <------------16------------>
                  __________________________
                 |                          |
                 |_ _ _ _  LEADER   _ _ _ _ |
                 |                          |
                 |__________________________|
                 |                          |
                 |        BYTE COUNT        |
                 |__________________________|
                 |            |             |
   BYTE SIZE-----|---->       |             |
                 |____________|_____________|
                 |            |             |
                 |            |<------------|--Beginning of first
                 |____________|_____________|       data byte
                 |                          |
                 |                          |

<。------------16------------>。__________________________ | | |_ _ _ _ リーダー_ _ _ _| | | |__________________________| | | | バイト・カウント| |__________________________| | | | バイトサイズ-----|、-、-、--、>|、| |____________|_____________| | | | | | <、-、-、-、-、-、-、-、-、-、-、--、|、--最初にの始まり|____________|_____________| データ・バイト| | | |

      b) use the double physical transmission scheme presented in
      NWG/RFC 67.  When sending a regular message, the Host would send a
      leader, byte count and byte size and terminate transmission.  The
      second transmission would be the data.

b) NWG/RFC67に提示された二重物理的なトランスミッション計画を使用してください。 通常のメッセージを送るとき、Hostはリーダー、バイト・カウント、およびバイトサイズを送って、トランスミッションを終えるでしょう。 2番目のトランスミッションはデータでしょう。

      At the receiving end, the IMP would transmit 64 bits of leader,
      byte count, byte size and spacing, and stop transmission.  The
      next transmission would be only the data.

犠牲者に、IMPはリーダーの64ビット、バイト・カウント、バイトサイズ、およびスペースを伝えて、トランスミッションを止めるでしょう。 次の唯一のトランスミッションはデータでしょう。

3. Allocation

3. 配分

   With respect to the allocation mechanism embodied in the ALL, GVB and
   RET commands, two alternatives were proposed:

中で具体化された配分メカニズム、GVBとRETコマンドでありすべて、2つの選択肢が提案されました:

      a) make no change.

a) 変更を全く行わないでください。

      b) The flow control algorithm should be changed to keep track of
      two quantities: messages and bits.  The ALL, GVB, and RET commands
      each have two data fields.  The ALL command allocates a message
      limit and a bit limit.  The GVB command contains two fractions,
      and the RET command returns both messages and bits.  When sending
      a message, the sending NCP decrements its message counter by 1 and
      its bit counter by the text length of the message.  The sending
      NCP may not cause either of its counters to go negative.  The
      message counter would be 16 bits long.

b) 2つの量の動向をおさえるためにフロー制御アルゴリズムを変えるべきです: メッセージとビット。 すべて、GVB、およびRETコマンドには、それぞれ2つのデータ・フィールドがあります。 すべてのコマンドがメッセージ限界としばらく限界を割り当てます。 GVBコマンドは2個の断片を含んでいます、そして、RETコマンドはメッセージとビットの両方を返します。 メッセージを送るとき、メッセージのテキストの長さに従って、送付NCPは1とその噛み付いているカウンタのそばでメッセージカウンタを減少させます。 送付NCPはどちらのカウンタも悪化させないかもしれません。 メッセージカウンタは長さ16ビットでしょう。

         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Gottfried Janik 02/98 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ゴットフリート・ジャニク02/98によるオンラインRFCアーカイブへの]

Crocker                                                         [Page 4]

クロッカー[4ページ]