RFC37 日本語訳

Network Working Group                                        S. Crocker
Request for Comments: 37                                           UCLA
                                                          20 March 1970

コメントを求めるワーキンググループS.医者要求をネットワークでつないでください: 37 UCLA1970年3月20日

                     Network Meeting Epilogue, etc.

ネットワークミーティングエピローグなど

The Meeting
-----------

ミーティング-----------

  On Tuesday, March 17, 1970, I hosted a Network meeting at UCLA.
  About 25 people attended, including representatives from MIT, LL,
  BBN, Harvard, SRI, Utah, UCSB, SDC, RAND and UCLA.  I presented a
  modification of the protocol in NWG/RFC #33; the modifications are
  sketchily documented in NWG/RFC #36.  The main modification is the
  facility for dynamic reconnection.

1970年3月17日火曜日に、私はUCLAでNetworkミーティングを主催しました。 MIT、LL、BBN、ハーバード、SRI、ユタ、UCSB、SDC、RAND、およびUCLAからの代表を含んでいて、およそ25人の人が出席しました。 私はNWG/RFC#33における、プロトコルの変更を提示しました。 変更はNWG/RFC#36にスケッチ風に記録されます。 主な変更はダイナミックな再接続のための施設です。

  The protocol based on sockets and undistinguished simplex
  connections is quite different from the previous protocol as
  documented in NWG/RFC #11.  The impetus for making such changes came
  out of the network meeting on December 8, 1969, at Utah, at which
  time the limitations of a log-in requirement and the inability to
  connect arbitrary processes was seriously challenged.  Accordingly,
  the primary reason for the recent meeting was to sample opinion on
  the new protocol.

ソケットと平凡なシンプレクス接続に基づくプロトコルはNWG/RFC#11に記録されるように前のプロトコルと全く異なっています。 そのような変更を行うための起動力はユタの1969年12月8日にネットワークミーティングから出て来ました。(その時、ログイン要件の制限と任意の過程を接続できないことは真剣に挑戦されました)。 それに従って、最近の会議の第一の理由は新しいプロトコルに関する意見を抽出することでした。

  Recollections may vary, but it is my opinion that the protocol was
  widely accepted and that the criticism and discussion fell into two
  categories:

回想は異なるかもしれませんが、広くプロトコルを受け入れて、批評と議論が2つのカテゴリになったのは、私の意見です:

  1.  Questioning the complexity and usefulness of the full protocol,
      especially the need for dynamic reconnection.

1. 完全なプロトコル、特にダイナミックな再接続の必要性の複雑さと有用性に質問します。

  2.  Other topics, particularly character set translation, higher
      level languages, incompatible equipment, etc.

2. 他の話題、特に文字の組翻訳、高水準言語、両立しない設備など

  Notably lacking was any criticism of the basic concepts of sockets
  and connections.  (Some have since surfaced.)  The following
  agreements were made:

著しく欠けるのはソケットと接続に関する基本概念のあらゆる批評でした。 (或るものは以来、表面化しています。) 以下の協定をしました:

  1.  By April 30, I would be responsible for publishing an
      implementable specification along lines presented.

1. 4月30日で、私は線に沿った実行可能仕様が提示した出版に責任があるでしょう。

  2.  Any interested party would communicate with me (at least)
      immediately if he wished to modify the protocol.

2. 彼がプロトコルを変更したいなら、どんな利害関係者も(少なくとも)すぐに、私にコミュニケートするでしょうに。

                                                                [Page 1]

RFC 37             Network Meeting Epilogue, etc.         20 March 1970

[1ページ] RFC37ネットワークミーティングエピローグなど 1970年3月20日

  3.  If major modifications come under consideration, interested
      parties would meet again.  This would happen in two to three
      weeks.

3. 主要な変更が考慮に該当するなら、利害関係者は再会するでしょう。 これは2〜3週間後に起こるでしょう。

  4.  Jim Forgie of Lincoln Labs tentatively agreed to host a meeting
      on higher level network languages, probably near Spring Joint
      time.

4. リンカーンLabsのジムForgieは、より高い平らなネットワーク言語でミーティングを主催するのに試験的に同意しました、たぶんSpring Joint時間。

Mailing List Changes
--------------------

メーリングリスト変化--------------------

  Paul Rovner of LL is replaced by

LLのポールRovnerを取り替えます。

                   James Forgie
                   Mass. Institute of Technology
                   Lincoln Laboratory C158
                   P.O. Box 73
                   Lexington, Mass. 02173

ジェームスForgieマサチューセッツ州 レキシントン、工科大学リンカーン研究所C158P.O. Box73マサチューセッツ州 02173

                   telephone at (617) 862-5500 ext. 7173

(617)862-5500extで電話をしてください。 7173

  Professor George MEaly is added

ジョージMEaly教授は加えられます。

                   George Mealy
                   Rm. 220
                   Aitken Computation Lab.
                   Harvard University
                   Cambridge, Massachusetts 02138

ジョージの粉だらけのRm。 220エイトケン計算研究室。 ハーバード大学ケンブリッジ、マサチューセッツ 02138

                   telephone at (617) 868-1020 ext. 4355

(617)868-1020extで電話をしてください。 4355

Process
-------

過程-------

  In all of our writing we have used the term process, to mean a
  program which has an assigned location counter and an address space.
  A program is merely a pattern of bits stored in some file.  A new
  process is created only by an already existing process.  The
  previous process must execute an atomic operation (forc, attach,
  etc.) to cause such a creation.  Processes may either cause their
  own demise or be terminated by another (usually superior) process.

執筆に、全部で、私たちは、割り当てられたロケーションカウンタとアドレス空間を持っているプログラムを意味するのに過程という用語を使用しました。 プログラムは単に何らかのファイルに格納されたビットのパターンです。 ニュープロセスは単に既に既存の工程で作成されます。 前の過程は、そのような創造を引き起こすために、原子操作(forc、付いてくださいなど)を実行しなければなりません。 過程は、それら自身の終焉を引き起こすか、または別の(通常優れる)の工程で終えられるかもしれません。

  The above definition corresponds to the definition given by
  Vyssotsky, et al on pp.  206, 207 of "Structure of the Multics
  Supervisor" in the FJCC proceedings, 1965.

上の定義はVyssotsky、ページの他によって与えられた定義に対応しています。 206 207 FJCC議事、1965年の「Multics監督の構造」について。

                                                                [Page 2]

RFC 37             Network Meeting Epilogue, etc.         20 March 1970

[2ページ] RFC37ネットワークミーティングエピローグなど 1970年3月20日

  Because a process may create another process, and because in general
  the two processes are indistinguishable when viewed externally, I
  know of no reasonable way for two processes to request connection
  directly with each other.  The function of sockets is to provide a
  standard interface between processes.

過程が別の過程を作成するかもしれなくて、外部的に見られると2つの過程が一般に区別がつかないので、私は2つの過程が直接互いとの接続を要求するどんな合理的な方法も知りません。 ソケットの機能は過程の間に標準インターフェースを提供することです。

The Days After
--------------

後の数日--------------

  In the time since the meeting I have had conversations with Steve
  Wolfe (UCLA-CCN), Bill Crowther (BBN), and John Heafner and Erick
  Harslem (RAND).  Wolf's comments will appear as NWG/RFC #38 and fall
  into a class I will comment on below.

ミーティング以来の時間、私には、スティーブ・ウルフ(UCLA-CCN)、ビル・クラウザー(BBN)、ジョンHeafner、およびエーリックHarslem(RAND)との会話があります。 ヴォルフのコメントは、NWG/RFC#38として現れて、私が以下で批評するつもりであるクラスになるでしょう。

  Crowther submitted the following:

クラウザーは以下を提出しました:

  "A brief description of two ideas for simplifying the host protocol
  described at the March meeting.  These ideas have not been carefully
  worked out.

「3月のミーティングで説明されたホストプロトコルを簡素化するための2つの考えの簡単な説明。」 これらの考えは慎重に考え出されていません。

  Idea 1. To Reconnect.
  --------------------

考え1。 再接続するために。 --------------------

  "A NCP wanting to Reconnect tells each of his neighbors "I want to
  reconnect".  They wait until there are no messages in transit and
  respond "OK".  He then says "Reconnect as follows" and they do it.
  In the Rare condition, the NCP gets back an "I want to reconnect
  instead of an "OK", then one must go and one must stop.  So treat a
  "reconnect" from a higher Host user etc. as an ok and from a lower
  as a "No-wait until I reconnect you" and do the connection.

「「再接続したいと思います」と、Reconnectに足りないNCPは彼の隣人各人に言います。」 彼らは、トランジットにはメッセージが全くないまで待っていて、「OK」を反応させます。 次に、「以下の通り再接続してください」と、彼は言います、そして、彼らはそれをします。 Rare状態で、NCPは「「OK」の代わりに再接続したいと思って、次に、ある必須が、碁とある欠かせない立ち寄り先です」を後部から抜きます。 それで、OKとaからのなどが「私があなたを再接続するまでの待ちがありません」として下ろすより高いHostユーザからの「再接続してください」を扱ってください、そして、接続してください。

  Idea 2
  ------

考え2------

  "Decouple connections and links.  Still establish connections, but
  use any handy link for the messages.  Don't send another message on
  a connection until a FRNM comes back.  Include source and
  destination socket numbers in the packet.

「接続とリンクの衝撃を吸収してください。」 それでも、関係を樹立しなさい、ただし、メッセージにあらゆる便利なリンクを使用してください。 FRNMが戻るまで、別のメッセージを接続に送らないでください。 パケットでソースと目的地ソケット番号を含めてください。

  "To reconnect, say to each of neighbors "please reconnect me as
  follows...".  Hold onto the connect for a short time (seconds) and
  send both packets and connection messages along toward their
  destinations.  I haven't worked out how to keep the in-transit
  messages in order, but probably everything works if you don't send
  out a reconnect when RFNM's are pending."

「再接続するには、「以下の通り私を再接続してください」と隣人各人に言ってください。」 握っている、短い間(秒)接続してください、そして、パケットと接続メッセージの両方をそれらの目的地に向かって送ってください。 「私はRFNMが未定であるときに、あなたがaを出さないならしかし、注文、たぶんすべてにトランジットにおけるメッセージを保つために、作品にどう再接続されるかを解決していません。」

                                                                [Page 3]

RFC 37             Network Meeting Epilogue, etc.         20 March 1970

[3ページ] RFC37ネットワークミーティングエピローグなど 1970年3月20日

  Bill's first idea does not seem to me to be either decisively better
  or (after some thought) very different, and I am considering it.  I
  have no strong feelings about it yet, but I am trying to develop
  some.

考えが決定的に良くなるように私にとって見えないビルの1番目か(後何らかの考え)、非常に異なる、私はそれを考えています。 それに関するどんな強い意見もまだありませんが、私はいくつかを開発しようとしています。

  Bill's second idea seems contrary to my conception of the role of
  links.  An argument in favor of decoupling connections and links
  that the number of connections between two hosts might want to
  exceed 255, and that even if not, it is sounder practice to isolate
  dependancies in design.  On the other hand, the newly provided Cease
  on Link facility* (page 22 of the soon to be released BBN report
  #1822 revised Febuary 1970) becomes useless.  (Bill, who just put
  the feature in, doesn't care.)  Another objection is that it seems
  intuitively bad to waste the possibility of using the link field to
  carry information.  (Note the conflict of gut level feelings).

ビルの2番目の考えは私のリンクの役割に関する概念とは逆に見えます。 接続とリンクの衝撃を吸収することを支持して2人のホストの間のポートの数が255、およびそれを超えたがっているかもしれないという主張、デザインにおける依存度を隔離するのは、音響器習慣です。 他方では、Link施設*の上の新たに提供されたCease、(22を呼び出す、すぐリリースされるために、BBNレポート#1822の改訂されたFebuary1970)は役に立たなくなります。 (ビル(ただ特徴を入れた)は気にかけません。) 別の異論はリンクフィールドを使用すると情報が運ばれる可能性を浪費するのが直観的に悪く思えるということです。 (生理的な気持ちの闘争に注意します。)

  In a conversation with John Haefner and Eric Harslem of RAND, the
  pointed out that the current protocol makes no provision for error
  detection and reporting, status testing and reporting, and expansion
  and experimentation.  Error detection and status testing will
  require some extended discussion to see what is useful, and I expect
  that such discussion will take place while implementation proceeds.
  Leaving room for protocol expansion and experimentation, however, is
  best done now.

現在のプロトコルが誤り検出、報告、状態テスト、報告、拡大、および実験への設備を全くしないジョンHaefnerとの会話とRAND、先鋭なアウトのエリックHarslemで。 誤り検出と状態テストは役に立つものを見るために何らかの長い討論を必要とするでしょう、そして、私は実現が続いている間そのような議論が行われると予想します。 しかしながら、プロトコル拡大と実験の余地は現在、最も上手に残されます。

  I suggest that two areas for expansion be reserved.  One is that
  only a fraction of the 256 links be used, say the first 32.  The
  other area is to use command codes from 255 downward, with permanent
  codes assigned from the number of links in use to 32, I feel that it
  is quite unlikely that we would need more than 32 for quite some
  time, and moreover, the network probably wouldn't handle traffic
  implied by heavy link assignment.  (These two things aren't
  necessarily strongly coupled:  one can have many links assigned but
  only a few carrying traffic at any given time.)

私は、拡大のための2つの領域が予約されることを提案します。 最初の32は、1つが256個のリンクの部分だけが使用されるということであると言います。 永久的なコードが32に使用中のリンクの数から割り当てられている状態で、私は、私たちが長い間32以上を必要とするのが、全くありそうもないと感じます、そして、ネットワークはもう片方の領域が255からコマンドコードを下向きに使用することであり、そのうえ、たぶん重いリンク課題で含意された交通を扱わないでしょう。 (これらの2つのものが必ず強く結合されるというわけではありません: 1つはその時々で割り当てられた多くのリンクにもかかわらず、ほんのいくつかの携帯交通を持つことができます。)

  Some of Heafner's and Harslen's other ideas may appear in NWG/RFC
  form.

HeafnerとHarslenの他の考えのいくつかがNWG/RFCフォームに載るかもしれません。

                                                                [Page 4]

RFC 37             Network Meeting Epilogue, etc.         20 March 1970

[4ページ] RFC37ネットワークミーティングエピローグなど 1970年3月20日

  Immediate Interaction
  ---------------------

即座の相互作用---------------------

  During the next several days, I will still be interested in those
  editicisms of current protocol which might lead to rejection or
  serious modification of it.  Thereafter, the focus will be a
  refinement, implementation, extension, and utilization.  I may be
  reached at UCLA through my secretary Mrs. Benita Kristel at (213)
  825-2368.  Also, everyone is invited to contribuet to the NWG/RFC
  series.  Unique numbers are assigned by Benita.

次の数日間、それでも、私はそれの拒絶か重大な変更につながるかもしれない現在のプロトコルのそれらのediticismsに興味を持つでしょう。 その後、焦点は、気品と、実現と、拡大と、利用になるでしょう。 私は(213)825-2368の私の秘書ベニータ・クリステル夫人を通してUCLAで連絡されるかもしれません。 また、皆はNWG/RFCシリーズへのcontribuetに招待されます。 ユニークな数はベニータによって割り当てられます。

  * The Cease on Link facility is a way a receiving host modifies
    RFNM's so as to carry a flow-quenching meaning.  An alternative
    proceedure is to use a host-to-host control command.

* Link施設の上のCeaseは受信ホストが流れを冷却している意味を運ぶようにRFNMのものを変更する方法です。 代替のproceedureはホストからホストへの制御コマンドを使用することになっています。

       [ This RFC was put into machine readable form for entry ]
        [ into the online RFC archives by Ron Fitzherbert 1/97 ]

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

                                                                [Page 5]

[5ページ]