RFC48 日本語訳

0048 Possible protocol plateau. J. Postel, S.D. Crocker. April 1970. (Format: TXT=41696 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                          J. Postel
Request for Comments: 48                                      S. Crocker
                                                                    UCLA
                                                          April 21, 1970

コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 48秒間1970年4月21日の医者UCLA

                      A Possible Protocol Plateau

可能なプロトコル停滞期

I. Introduction

I. 序論

   We have been engaged in two activities since the network meeting of
   March 17, 1970 and, as promised, are reporting our results.

私たちは、1970年3月17日のネットワークミーティング以来2つの活動に従事して、約束されるように結果を報告しています。

   First, we have considered the various modifications suggested from
   all quarters and have formed preferences about each of these.  In
   Section II we give our preferences on each issue, together with our
   reasoning.

まず最初に、私たちは、いたる所から示された様々な変更を考えて、およそそれぞれこれらの好みを形成しました。 セクションIIでは、私たちは私たちの推理と共に各問題における好みを与えます。

   Second, we have tried to formalize the protocol and algorithms for
   the NCP, we attempted to do this with very little specification of a
   particular implementation.  Our attempts to date have been seriously
   incomplete but have led to a better understanding.  We include here,
   only a brief sketch of the structure of the NCP.  Section III gives
   our assumptions about the environment of the NCP and in Section IV
   the components of the NCP are described.

2番目に、私たちはNCPのためにプロトコルとアルゴリズムを正式にしようとして、特定の実現の非常に少ない仕様でこれをするのを試みました。 私たちのこれまでの試みは、真剣に不完全でしたが、より良い理解に通じました。 私たちはNCPの構造の簡潔なスケッチだけを入れます。 セクションIIIはNCPの環境に関する私たちの仮定を与えます、そして、セクションIVでは、NCPの成分は説明されます。

II. Issues and Preferences

II。 問題と好み

   In this section we try to present each of the several questions which
   have been raised in recent NWG/RFC's and in private conversations,
   and for each issue, we suggest an answer or policy.  In many cases,
   good ideas are rejected because in our estimation they should be
   incorporated at a different level.

私たちがそれぞれ提示しようとする最近のNWG/RFCのものと密談で引き起こされたいくつかの疑問のこのセクション、および各問題のために、私たちは答えか方針を勧めます。 多くの場合、それらが異なったレベルで私たちの見積りでは、組み込むべきであるので、名案は拒絶されます。

      A. Double Padding

A.の二重詰め物

         As BBN report #1822 explains, the Imp side of the Host-to-Imp
         interface concatenates a 1 followed by zero or more 0's to fill
         out a message to an Imp word boundary and yet preserve the
         message length.  Furthermore, the Host side of the Imp-to-Host
         interface extends a message with 0's to fill out the message to
         a Host word boundary.

BBNレポート#1822が説明するように、ゼロか、より多くの0があとに続いて、Imp語境界にメッセージを書き込みますが、メッセージ長を保存して、Hostから悪童へのインタフェースのImp側は1を連結します。 その上、Impからホスト・インターフェースのHost側は、Host語境界にメッセージを書き込むために0でメッセージを広げています。

         BBN's mechanism works fine if the sending Host wants to send an
         integral number of words, or if the sending Host's hardware is
         capable of sending partial words.  However, in the event that

発信しているHostが整数に関する知らせを送りたがっているか、または発信しているHostのハードウェアが部分的な知らせを送ることができるなら、BBNのメカニズムはきめ細かに動作します。 しかしながら

Postel & Crocker                                                [Page 1]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[1ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         the sending Host wants to send an irregular length message and
         its hardware is only capable of sending word-multiple messages,
         some additional convention is needed.

Hostが不規則な長さのメッセージとそのハードウェアを送りたがっている発信が単語複数のメッセージを送ることができるだけである、いくらかの追加コンベンションが必要です。

         One of the simplest solutions is to modify the Imp side of the
         Host-to-Imp interface so that it appends only 0's.  This would
         mean that the Host software would have to supply the trailing
         1.  BBN rejected the change because of an understandably strong
         bias against hardware changes.  It was also suggested that a
         five instruction patch to the Imp program would remove the
         interface supplied 1, but this was also rejected on the new
         grounds that it seemed more secure to depend only upon the Host
         hardware to signal message end, and not to depend upon the Host
         software at all.

最も簡単な解決策の1つがHostから悪童へのインタフェースのImp側を変更することであるので、それは0だけを追加します。 これは、Hostソフトウェアが引きずっている1を供給しなければならないことを意味するでしょう。 BBNは目立って強い偏見でハードウェアの変更に対して変化を拒絶しました。 また、Impプログラムへの5指示パッチがインタフェース供給された1を取り除くと示唆されましたが、また、これは、メッセージ終わりに合図して、全くHostソフトウェアによらないように以上がHostハードウェアだけによるために安全にするように思えたという新しい根拠で拒絶されました。

         Two other solutions are also available.  One is to have "double
         padding", whereby the sending Host supplies 10* and the network
         also supplies 10*.  Upon input, a receiving Host then strips
         the trailing 10* 10*.  The other solution is to make use of the
         marking.  Marking is a string of the form 0*1 inserted between
         the leader and the text of a message.  The original intent of
         marking was to extend the leader so that the sending Host could
         _begin_ its text on a word boundary.  It is also possible to
         use the marking to expand a message so that it _ends_ on a word
         boundary.

また、他の2つの解決策も利用可能です。 1つには、「二重詰め物」があることになっています、また、発信しているHostがどうして10*とネットワークを供給するかが10*を供給します。次に、入力のときに、受信Hostは*もう片方の解決策がマークの使用をすることになっている引きずっている10*10を剥取ります。 マークはメッセージのリーダーとテキストの間に挿入された形式0*1のストリングです。 マークの当初の意図は発信しているHostが広げることができるようにリーダーを広げることでした。__語境界に関するテキストを始めてください。 また、したがって、aを広げる印がそれを通信させるのも、使用に可能である、それ、_は語境界で_を終わらせます。

         Notice that double padding could replace marking altogether by
         abutting the text beginning against the leader.  For 32 bit
         machines, this is convenient and marking is not, while for
         other lengths, particularly 36 bit machines, marking is much
         more convenient than double padding.

二重詰め物がリーダーに対して始まるテキストを隣接させるのに全体でマークに取って代わるかもしれないのに注意してください。 32ビットのマシンに関しては、これは便利です、そして、マークは便利ではありません、マークが詰め物を倍にするより他の長さ、特に36台の噛み付いているマシンに関してはるかに便利ですが。

         We have no strong preference, partially because we can send
         word fragments.  Shoshani, et al in NWG/RFC #44 claim that
         adjusting the marking does not cause them any problems, and
         they have a 32 bit machine.  Since the idea of marking has been
         accepted for some time, we suggest that double padding not be
         used and that marking be used to adjust the length of a
         message.  We note that if BBN ever does remove the 1 from the
         hardware padding, only minimal change to Host software is
         needed on the send side.

私たちには、どんな強い好みもなくて、私たちが発信できるので、部分的に、単語は断片化します。 Shoshani、NWG/RFC#44における他はマークを調整するのがどんな問題もそれらに引き起こさないと主張します、そして、それらには、32ビットのマシンがあります。 しばらくマークの考えを受け入れているので、私たちは、二重詰め物が使用されないで、マークがメッセージの長さを調整するのに使用されることを提案します。 BBNが取り外すなら私たちがそれに注意する、ハードウェア詰め物からの1、Hostへのソフトウェアが必要である最小量の変化だけ、側を送ってください。

         A much prettier (and more expensive) arrangement was suggested
         by W. Sutherland.  He suggested that the Host/Imp interfaces be
         smart enough to strip padding or marking and might even parse
         the message upon input.

はるかにきれいで(より高価)のアレンジメントはW.サザーランドによって提案されました。 彼は、Host/悪童インタフェースが詰め物かマークを剥取ることができるくらい賢く、入力に関するメッセージを分析さえするかもしれないことを提案しました。

Postel & Crocker                                                [Page 2]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[2ページ]RFC48は可能なプロトコル停滞期1970年4月です。

      B. Reconnection

B.再接続

         A very large population of networkers has beat upon us for
         including dynamic reconnection in the protocol.  We felt it
         might be of interest to relate how it came to be included.

ネットワーカーの非常に大きい人口は、プロトコルにダイナミックな再接続を含むように私たちをどんどんたたきました。 私たちは、どう含まれるようになったかを関係づけるのは興味があるかもしれないと感じました。

         After considering connections and their uses for a while, we
         wondered how the mechanism of connections compared to existing
         forms of intra-Host interprocess communication.  Two aspects
         are of interest, what formalisms have been presented in the
         literature, and what mechanisms are in use.  The formalisms are
         interesting because they lead to uniform implementations and
         parsimonious design.  The existing mechanisms are interesting
         because they point out which problems need solving and
         sometimes indicate what an appropriate formalism might be.  In
         particular, we have noticed that the mechanisms for connecting
         a console to the logger upon dial in, the mechanisms for
         creating a job, and the mechanisms for passing a console around
         to various processes within a job tend to be highly
         idiosyncratic and distinct from all other structures and
         mechanisms within an operating system.

しばらく接続と彼らの用途を考えた後に、私たちは、接続のメカニズムがどのように既存のフォームのイントラホストプロセス間通信と比較されたかと思いました。 2つの局面が関心と、形式が文学に提示されたものと、メカニズムが使用でのものであることのものです。 形式は、一定の実現とけちなデザインに通じるので、おもしろいです。 どの問題が、解決する必要であるかを指摘して、時々適切な形式が何であるだろうかを示すので、既存のメカニズムはおもしろいです。 特に、私たちは、コンソールをきこりに接続するためのメカニズムが直通電話にかけるのに気付きました、雇用を創り出すためのメカニズム、そして、仕事の中で様々な過程にコンソールを回すためのメカニズムがオペレーティングシステムの中ですべての非重要構造とメカニズムと非常に特有であって異なる傾向があります。

         With respect to the literature, it appears there is only one
         idea with several variations, viz processes should share a
         portion of their address spaces and cooperatively wake up each
         other.  Semaphores and event channels are handy extensions of
         wake up signals, but the intent is basically the same.  (Event
         channels could probably function as connections, but it seems
         not to be within their intended use.  In small systems, the
         efficiency and capacity of event channels are inversely
         related.)

文学に関して、数回の変化を伴う1つの考えしかないように見えて、過程は、つまり、それらのアドレス空間の部分を共有して、協力して互いを起こすべきです。 腕木信号機とイベントチャンネルは信号への航跡の便利な拡大ですが、意図は基本的に同じです。 (イベントチャンネルはたぶん接続として機能できましたが、それは彼らの意図している使用の中にないように思えます。 小さいシステムでは、イベントチャンネルの効率と容量は逆に関係づけられます。)

         With respect to existing implementations, we note that several
         systems allow a process to appear to be a file to another
         process.  Some systems, e.g. the SDS-940 at SRI impose a
         master/slave relationship between two processes so connected,
         but other systems provide for a coequal relationship e.g. the
         AI group's PDP-6 system at MAC.  The PDP-6 system also has a
         feature whereby a superior process can "surround" an inferior
         process with a mapping from device and file names to other
         device and file names.  Consoles have nearly the same semantics
         as files, so it is quite reasonable for an inferior process to
         believe it is communicating with the console but in fact be
         communicating with another process.

既存の実現に関して、私たちは、過程が数個のシステムで別の過程へのファイルであるように見えることに注意します。 いくつかのシステム、例えば、SRIのSDS-940はそのように接続された2つの過程の間のマスター/奴隷関係を課しますが、他のシステムはMACで例えばAIグループのPDP-6システムを同等な関係に提供します。 また、PDP-6システムには、優れた過程がマッピングで劣った過程を装置とファイル名から対向機器とファイル名まで「囲むことができる」特徴があります。 コンソールにはファイルとほとんど同じ意味論があるので、劣った過程が、それがコンソールとコミュニケートしますが、事実上、別の過程で交信する予定であると信じているのは、かなり妥当です。

         The similarity between network connections and existing
         sequential interprocess connections supports our belief that
         network connections are probably the correct structure for

ネットワーク接続と存在の間の連続したインタプロセス接続がネットワーク接続がたぶん正しい構造であるという私たちの信念を支持する類似性

Postel & Crocker                                                [Page 3]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[3ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         using the network.  Moreover, the structure is clean enough and
         compatible with enough machines to pass as a formalism or
         theory, at least to the extent of the other forms of
         interprocess communication presented in the literature.

ネットワークを使用します。 そのうえ、構造は、形式か理論として通用できるくらいのマシンと十分清潔であって、互換性があります、少なくとも文学に示された他のフォームのプロセス間通信の範囲に。

         Any new formalism, we believe, must meet at least the following
         two tests:

私たちは、どんな新しい形式も少なくとも2がテストする以下に会わなければならないと信じています:

            1. What outstanding problems does it solve?
            2. Is it closed under all operations?

1. それはどんな未解決問題を解決しますか? 2. それはすべての操作で閉じられますか?

         In the case of network connections, the candidates for the
         first are the ones given above, i.e. all operations involving
         connecting a console to a job or a process.  Also of interest
         are the modelling of sequential devices such as tape drives,
         printers and card readers, and the modeling of their buffering
         (spooling, symbiont) systems.

ネットワーク接続の場合では、1つの番目ものの候補はすべて、上に与えられたもの、すなわち、仕事か過程にコンソールを接続することを伴う操作です。 関心も、テープドライブや、プリンタやカードリーダなどのシーケンシャル装置のモデル化と、システムをバッファリングする(スプール、共生者)モデルです。

         The second question mentions closure.  In applying the
         connection formalism to the dial-in and login procedures, we
         felt the need to include some sort of switching or
         reconnection, and an extremely mild form is presented in an
         SJCC paper, which is also NWG/RFC #33.  This mild form permits
         only the substitution of AEN's, and even then only at the time
         of connection establishment. However, it is a common experience
         that if an operation has a natural definition on an extended
         domain, it eventually becomes necessary or at least desirable
         to extend its definition.  Therefore, we considered the
         following extensions:

2番目の質問は閉鎖について言及します。 ダイヤルインとログイン手順に接続形式を適用する際に、私たちはある種の切り換えか再接続を含む必要性を感じました、そして、非常に温和なフォームはSJCC論文に示されます。(また、それは、NWG/RFC#33です)。 この軽症型は単にコネクション確立時点で、その時でさえ、AENの代替だけを可能にします。 しかしながら、操作が拡張ドメインに自然な定義を持っているなら、定義を広げるのが結局必要であるか少なくとも望ましくなるのは、一般的な経験です。 したがって、私たちは以下の拡大を考えました:

            1. Switching to any other socket, possibly in another Host.
            2. Switching even after data flow has started.

1. いかなる他のソケットと、ことによると別のHostではも、切り替わります。 2. データが流れた後にさえ切り替わるのは始まりました。

         There is even some precedent for feeling these extensions might
         be useful.  In one view of an operating system, we see all
         available phone lines as belonging to a live process known as
         the logger.  The logger answers calls, screens users, and
         creates jobs and processes.  One of the features of most
         telephone answering equipment is that many phone lines may
         serve the same phone number by using a block of sequential
         numbers and a rotary answering system.  In our quest for
         accurate models of practical systems, we wanted to be able to
         provide equivalent service to network users, i.e. they should
         be able to call a single advertised number and get connected to
         the logger.  Thus a prima facie case for switching is
         established.

これらの拡大が役に立つかもしれないと感じるための何らかの先例さえあります。 オペレーティングシステムの1つの視点では、私たちはきこりとして知られている在住の過程に属すとすべての利用可能な電話回線をみなします。 きこりは、呼び出しに答えて、ユーザを上映して、仕事と過程を作成します。 ほとんどの電話応答装置の特徴の1つは1ブロックの連番と回転式の回答システムを使用することによって多くの電話回線が同じ電話番号に役立つかもしれないということです。 実用的なシステムの正確なモデルを求める探索では、私たちがネットワーク利用者に対する同等なサービスを提供できるようになりたくて、彼らは、1つの広告を出している数に電話をして、すなわち、きこりに接できるべきです。 したがって、切り替わるための一応のケースは確立されます。

Postel & Crocker                                                [Page 4]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[4ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         Next we see that after the logger interrogates a prospective
         user, it must connect the user to a newly created job.  Data
         flow between the user and the logger has already commenced, so
         flow control has to be meshed with switching if it is desired
         not to lose or garble data in transit.

次に、私たちは、きこりが将来のユーザについて査問した後にそれが新たに作成された仕事にユーザを接続しなければならないのがわかります。 ユーザときこりの間のデータフローが既に始まったので、フロー制御はトランジットにおけるデータを失わないか、または誤り伝えないのが必要であるなら切り替わりながら、合われなければなりません。

         With respect to inter-Host switching, we find it easy to
         imagine a utility service which is distributed throughout the
         network and which passes connections from one socket to another
         without the knowledge of the user.  Also, it is similar to the
         more sophisticated telephone systems, to standard facilities of
         telephone company operators, and to distributed private
         systems.

相互Hostの切り換えに関して、私たちは、ユーザに関する知識なしでユーティリティがネットワーク中に広げられて、1個のソケットから別のソケットまで接続を通過するサービスであると想像するのが簡単であることがわかりました。 また、それも、より精巧な電話と、そして、電話会社のオペレータの標準の施設と、そして、分配された個人的なシステムと同様です。

         These considerations led us to investigate the possibility of
         finding one type of reconnection which provided a basis for all
         known models.  The algorithm did not come easily, probably
         because of inexperience with finite state automata theory, but
         eventually we produced the algorithm presented in NWG/RFC #36.
         A short time later, Bill Crowther produced an equivalent
         algorithm which takes an alternate approach to race conditions.

これらの問題は、私たちがすべての知られているモデルの基礎を提供した1つのタイプの再接続を見つける可能性を調査するように導きました。 アルゴリズムは有限州のオートマトン理論がある無経験ためか容易に来ませんでしたが、結局、私たちはNWG/RFC#36で提示されたアルゴリズムを作成しました。 少し後で、ビル・クラウザーは競合条件への交互のアプローチを取る同等なアルゴリズムを作成しました。

         Networkers seem to have one of two reactions.  Either it was
         pretty and (perhaps ipso facto) useful, or it was complex and
         (again perhaps ipso facto) unnecessary.  The latter group was
         far more evident to us, and we were put into the defensive
         position of admitting that dynamic reconnection was only

ネットワーカーは、2回の反応の1つを持っているように思えます。 それは、不要な状態でそれが、役に立った状態できれい、そして、(恐らくipsoにfacto)でした、複雑、または(再び、恐らくipsoにfacto。)でした。 私たちにとって、後者のグループははるかに明白でした、そして、ダイナミックな再接続があったことを認める防衛陣地だけに私たちを入れました。

            1. pretty
            2. useful for login and console passing

1. ログインとコンソール通過の役に立つきれいな2

         In response to persistent criticism, we have made the following
         change in the protocol.  Instead of calling socket <O,H,O> to
         login, sockets of the form <U,H,O> and <U,H,1> are the input
         and output sockets respectively of a copy of the logger or, if
         a job has been stared with user id U, these sockets are the
         console sockets.  The protocol for login is thus to initiate a
         connection to <U,H,O> and <U,H,1>.  If user U is not in use, a
         copy of the logger will respond and interrogate the caller.  If
         user id U is in use, the call will be refused.  This
         modification was suggested by Barry Wessler recently.  (Others
         also suggested this change much earlier; but we rejected it
         then.)

しつこい批評に対応して、私たちはプロトコルで以下を変えさせました。 ソケット<O、HをログインするO>と呼ぶことの代わりに、フォーム<U、H、O>、および<Uのソケット、H、1>がそれぞれきこりのコピーの入出力ソケットであるか仕事がユーザイドUで見つめられたなら、これらのソケットはコンソールソケットです。 その結果、ログインのためのプロトコルはそうです。<UとHとO>と<U、Hとの接続、1>を開始するために。 ユーザUが使用中でないなら、きこりのコピーは、訪問者について反応して、査問するでしょう。 ユーザイドUが使用中であるなら、呼び出しは拒否されるでしょう。 この変更は最近、バリーWesslerによって勧められました。 (また、他のものははるかに早くこの変化を勧めました; しかし、私たちはその時、それを拒絶しました。)

         The logger may demand that the caller be from the same virtual
         net, i.e. the caller may have user id U in some other Host, or
         it may demand that the user supply a password matched to user

きこりが、訪問者が同じ仮想のネットから来ているのを要求するかもしれませんか、すなわち、訪問者がある他のHostにユーザイドUを持っているかもしれませんか、またはそれは、ユーザがユーザに合わせられたパスワードを提供するのを要求するかもしれません。

Postel & Crocker                                                [Page 5]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[5ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         id U, or it may demand both.  Some systems may even choose to
         permit anybody to login to any user id.

イドU、またはそれは要求するかもしれません。両方を要求してください。 いくつかのシステムが、だれでもどんなユーザイドにもログインすることを許可するのを選びさえするかもしれません。

         After login, AEN's 0 and 1 remain the console AEN's.  Each
         system presumably has mechanisms for passing the console, and
         these would be extended to know about AEN's 0 and 1 for network
         users.  Passing the console is thus a matter of reconnecting
         sockets to ports, and happens within the Host and without the
         network.

ログインの後に、AENの0と1はコンソールAENのもののままで残っています。 各システムには、おそらく、コンソールを渡すためのメカニズムがあります、そして、これらは、0時とAENの1時頃にネットワーク利用者で知るために広げられるでしょう。 コンソールを渡すのは、その結果、ソケットをポートに再接続する問題であり、Host以内とネットワークなしで起こります。

         In conversations with Meyer and Skinner after NWG/RFC #46 was
         received, they suggested a login scheme different from both
         Meyer's and ours in section above.  Their new scheme seemed a
         little better and we look forward to their next note.

NWG/RFC#46を受け取った後にマイヤーとスキナーとの会話では、彼らはセクションのマイヤーと私たちのものの上の両方と異なったログイン計画を示しました。 それらの新しい計画は少し良く見えました、そして、それらの次の注意を楽しみにしています。

         It is generally agreed that login should be "third-level", that
         is, above the NCP level.  We are beginning to be indifferent
         about particular logins schemes; all seem ok and none impress
         us greatly.  We suggest that several be tried.  It is some
         burden, of course, to modify the local login procedure, but we
         believe it imposes no extra hardship to deal with diverse login
         procedures.  This is because the text sequences and interrupt
         conventions are so heterogenous that the additional burden of
         following, say, our scheme on our system and Meyer's on Multics
         is minimal.

一般に、ログインがすなわち、NCPレベルを超えて「3番目に平らであるべきであること」に同意されます。 私たちは、特定のログイン計画に関して無関心であり始めています。 すべてが間違いなく見えます、そして、なにも私たちを大いに感動させません。 私たちは、数個が試みられることを提案します。 それはもちろんローカルのログイン手順を変更するためには何らかの負担ですが、私たちは、それがさまざまのログイン手順に対処するためにどんな余分な苦労も課さないと信じています。 これによるそのように、テキスト系列と中断コンベンションがそうであるので追加が負う次の事柄のheterogenousということである、たとえば、Multicsの上のシステムと私たちのマイヤーのものに関する私たちの計画は最小限です。

         We are agreed that reconnection should not be required in the
         initial protocol, and we will offer it later as an optional and
         experimental tool.  In addition, we would like to be on record
         as predicting that general reconnection facilities will become
         useful and will provide a unifying framework for currently ad
         hoc operating system structures.

私たちは同意されて、初期のプロトコルでその再接続を必要とするべきでないということです、そして、後で任意の、そして、実験用のツールとしてそれを提供するつもりです。 さらに、現在臨時のオペレーティングシステム構造において、一般的な再接続施設が役に立つようになって、統一枠組みを提供すると予測するとして私たちは公に知られていたいです。

      C. Decoupling Connections and Links

C.デカップリングコネクションズとリンク

         Bill Crowther (BBN) and Steve Wolfe (UCLA) independently have
         suggested that links not be assigned to particular connections.
         Instead, they suggest, include the destination socket as part
         of the text of the message and then send messages over any
         unblocked link.

ビル・クラウザー(BBN)とスティーブ・ウルフ(UCLA)は、リンクが特定の接続に割り当てられないことを独自に提案しました。 代わりに、彼らは、示して、メッセージの本文の一部として目的地ソケットを含めて、次に、どんな「非-妨げ」られたリンクの上にもメッセージを送ります。

         We discussed this question a little in NWG/RFC #37, and feel
         there is yet an argument for either case.  With the current
         emphasis on simplicity, speed and small core requirements, it
         seems more efficient to leave links and connections coupled.
         We, therefore, recommend this.

私たちは、NWG/RFC#37でこの問題について少し議論して、どちらかのケースのための議論があると感じます。 簡単さ、速度、および小さいコア要件への現在の強調で、リンクと接続を結合されたままにするように、より効率的に思えます。 したがって、私たちはこれを推薦します。

Postel & Crocker                                                [Page 6]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[6ページ]RFC48は可能なプロトコル停滞期1970年4月です。

      D. Error Reporting

D.誤り報告

         As mentioned by J. Heafner and E. Harslem of RAND, it is
         important to treat errors which might occur.  A good philosophy
         is to guard against any input which destroys the consistency of
         the NCP's data base.

RANDのJ.HeafnerとE.Harslemによって言及されるように、発生するかもしれない誤りを扱うのは重要です。 良い哲学はNCPのデータベースの粘性を破壊するどんな入力にも用心することです。

         The specific formulation of the error command given by Heafner
         and Harslem in NWG/RFC #40 and by Meyer in NWG/RFC #46 seems
         reasonable and we recommend its adoption.  Some comments are in
         order, however.

NWG/RFC#40のHeafnerとHarslemとNWG/RFC#46のマイヤーによって与えられた誤り命令の特定の定式化は妥当に思えます、そして、私たちは採用を推薦します。 しかしながら、いくつかのコメントが整然としています。

         A distinction should be made between resource errors and other
         types of errors.  Resource errors are just the detection of
         overload conditions.  Overload conditions are well-defined and
         valid, although perhaps undesirable.  Other types of errors
         reflect errant software or hardware.  We feel that resource
         errors should not be handled with error mechanisms, but with
         mechanisms specific to the problem.  Thus the <CLS> command may
         be issued when there is no more room to save waiting <RFC>'s.
         Flow control protocol is designed solely to handle buffering
         overload.

リソース誤りと他のタイプの誤りの間で区別をするべきです。 リソース誤りはただ過負荷条件の検出です。 過負荷条件は、明確であって、恐らく望ましくないのですが、有効です。 他のタイプの誤りは誤ったソフトウェアかハードウェアを反映します。 私たちは、リソース誤りが誤りメカニズムにもかかわらず、問題に特定のメカニズムで扱われるべきでないと感じます。 RFC>の待ち<ものを取っておくそれ以上の余地が全くないとき、したがって、<CLS>コマンドを発行するかもしれません。 フロー制御プロトコルは唯一オーバーロードをバッファリングするハンドルに設計されています。

         With respect to true errors, we are not certain what the value
         of the <ERR> command is to the recipient.  Presumably his NCP
         is broken, and it may only aggravate the problem to bombard it
         with error commands.  We therefore, recommend that error
         generation be optional, that all errors be logged locally in a
         chronological file and that <ERR> commands received likewise be
         logged in a chronological file.  No corrective action is
         specified at this time.

本当の誤りに関して、受取人にとって、私たちは<ERR>コマンドの値が何であるかを確信していません。 おそらく、彼のNCPは壊れています、そして、それは誤り命令をそれに砲撃するために問題をいらいらさせるだけであるかもしれません。 私たち、したがって、エラー生成が任意であり、すべての誤りが年代順のファイルに局所的に登録されて、同様に受け取られた<ERR>コマンドが年代順のファイルに登録されることを勧めてください。 修正措置は全くこのとき、指定されません。

         In the short time the network has been up at UCLA, we have
         become convinced that the network itself will generate very few
         errors.  We have watched the BBN staff debug and test the IMP
         program, and it seemed that most of the errors affected timing
         and throughput rather than validity.  Hence most errors will
         probably arise from broken Hosts and/or buggy NCP's.

ネットワークがUCLAで上がっている短い間に、私たちはネットワーク自体がほんのわずかな誤りを発生させると確信するようになりました。 私たちは、BBNスタッフがIMPプログラムをデバッグして、検査するのを見ました、そして、誤りの大部分が正当性よりむしろタイミングとスループットに影響したように思えました。 したがって、ほとんどの誤りがたぶん壊れているHosts、そして/または、バギーのNCPのものから起こるでしょう。

      E. Status Testing and Reporting

E.状態テストと報告

         A valuable debugging aid is to be able to get information about
         what a foreign NCP thinks is happening.  A convenient way to do
         this is to permit NCP's to send status whenever they wish, but
         to always have them do it whenever they receive a request.

貴重なデバッギング・エイドは起こっている外国NCPが考えることの情報を得ることであることができます。 これをする便利な方法は、彼らが願っているときはいつも、NCPのものが状態を送ることを許可しますが、要求を受け取るときはいつも、彼らにいつもにそれをさせることです。

Postel & Crocker                                                [Page 7]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[7ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         Since we view this feature as primarily a debugging tool, we
         suggest that a distinct link, like 255, be used.  The intent is
         that processing of status requests and generating of status
         messages should use as little of the normal machinery as
         possible.  Thus we suggest that link 255 be used to send
         "request status" and "status is" commands.  The form follows
         the suggestion on page 2 of NWG/RFC #40.

この特徴を主としてデバッグ用ツールであるとみなすので、私たちは、異なったリンクが255のように使用されることを提案します。 意図は状態要求の処理とステータスメッセージの発生ができるだけ小さい正常な機械を使用するべきであるということです。 したがって、私たちは、リンク255が「要求状態」と「状態がいること」にコマンドを送るのに使用されることを提案します。 フォームはNWG/RFC#40の2ページにおける提案に続きます。

         Meyer's <ECO> command is easily implemented and serves the more
         basic function of testing whether a foreign NCP is alive.  We
         suggest that the length of the <ECO> command be variable, as
         there seems to be no significance in this context to 48 bits.
         Also, the value of a (presumably) 8 bit binary switch is
         unclear, so we recommend a pair of commands:

マイヤーの<ECO>コマンドは、容易に実行されて、外国NCPが生きているか否かに関係なく、テストするより基本的な機能を果たします。 私たちは、<ECO>コマンドの長さが可変であると示唆します、このような関係においては48ビットへの意味が全くあるように思えないように。 また、(おそらく)8ビットの2進のスイッチの値も不明瞭であるので、私たちは1組のコマンドを推薦します:

                   <ECO>   <length>   <text>
         and
                   <ERP>   <length>   <text>
         where
                   <length> is 8 bits.

<ECO><の長さの><テキスト>と<の長さの>が8ビットである<ERP><の長さの><テキスト>。

         Upon receipt of an <ECO> command the NCP would echo with the
         <ERP> command.

<ECO>コマンドを受け取り次第、NCPは<ERP>コマンドを反響するでしょう。

      F. Expansion and Experimentation

F.拡大と実験

         As Meyer correctly points out in NWG/RFC #46, network protocol
         is a layered affair.  Three levels are apparent so far.

マイヤーがNWG/RFC#46で正しく指摘するように、ネットワーク・プロトコルは層にされた事です。 3つのレベルが今までのところ、明らかです。

            1. IMP Network Protocol
            2. Network Control Program Protocol
            3. Special user level or Subsystem Level Protocol

1. 悪童ネットワーク・プロトコル2。 ネットワーク・コントロール・プログラムプロトコル3。 特別なユーザレベルかSubsystem Levelプロトコル

         This last level should remain idiosyncratic to each Host (or
         even each user).  The first level is well-specified by BBN, and
         our focus here is on level 2.  We would like to keep level 2 as
         neutral and simple as possible, and in particular we agree that
         login protocol should be as much on level 3 as possible.

この最後のレベルは各Host(または、各ユーザさえ)に特有のままで残るべきです。 最初のレベルはBBNによってよく指定されています、そして、ここの私たちの焦点がレベル2にあります。 できるだけ中立で簡単にレベル2を保ちたいと思います、そして、特に、私たちはログインプロトコルが多くとして可能であるとしてのレベル3にあるべきであるのに同意します。

         Simplicity and foresight notwithstanding, there will arise
         occasions when the level 2 protocol should change or be
         experimented with.  In order to provide for experimentation and
         change, we recommend that only link numbers 2 through 31 be
         assigned to regular connections, with the remaining link
         numbers, 32 to 255, used experimentally.  We have already
         suggested that link 255 be used for status requests and
         replies, and this is in consonance with our view of the
         experimental aspects of that feature.

簡単さと先見にもかかわらず、平らな2プロトコルが変化するべきであるか、または実験されるべきである時は起こるでしょう。 実験に備えて、変化するように、私たちは、リンク番号2〜31だけが実験的に残っている32〜255に使用されたリンク番号との定期便に割り当てられることを勧めます。 私たちは、リンク255が状態要求と回答に使用されることを既に提案しました、そして、協和音にはこれが私たちのその特徴の実験局面の視点と共にあります。

Postel & Crocker                                                [Page 8]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[8ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         We also recommend that control command prefixes from 255
         downward be used for experimentation.

また、私たちは255からその制御コマンド接頭語を下向きに推薦します。実験のために、使用されます。

         These two conventions are sufficient, we feel to permit
         convenient experimentation with new protocol among any subset
         of the sites. We thus do not favor inclusion of Ancona's
         suggestion in NWG/RFC #42 for a message data type code as the
         first eight bits of the text of a message.

私たちは、サイトのどんな部分集合の中にも新しいプロトコルがある状態で便利な実験を可能にするためにこれらの2つのコンベンションが十分であると感じます。 その結果、私たちはメッセージデータ型コードのためにメッセージのテキストの最初の8ビットとしてNWG/RFC#42でのアンコナの提案の包含を支持しません。

      G. Multiplexing Ports to Sockets

ソケットへのG.マルチプレクシングポート

         Wolfe in NWG/RFC #38 and Shoshani et al in NWG/RFC #44 suggest
         that it should be possible to attach more than one port to a
         socket.  While all of our diagrams and prototypical system
         calls have shown a one-to-one correspondence between sockets
         and ports, it is strictly a matter of local implementation.  We
         note that sockets form a network-wide name space whose sole
         purpose is to interface between the idiosyncratic structures
         peculiar to each operating system.  Our references to ports are
         intended to be suggestive only, and should be ignored if no
         internal structures corresponds to them.  Most systems do have
         such structures, however, so we shall continue to use them for
         illustration.

NWG/RFC#38のウルフとNWG/RFC#44のShoshani他は、1つ以上のポートをソケットに取り付けるのが可能であるべきであると示唆します。 私たちのダイヤグラムのすべてとソケットとポートとの1〜1つの通信であり、厳密に、aが重要であるということであることが示されて、システムコールが持っている地方の実現のprototypicalをゆったり過ごしてください。 私たちは、ソケットが各オペレーティングシステムに独特の特有の構造の間で連結する唯一の目的がことであるネットワーク全体の名前スペースを形成することに注意します。 ポートの私たちの参照が思わせ振りであることを意図する、唯一、どんな内部の構造もそれらに対応していないなら、無視されるべきです。 ほとんどのシステムにはそのような構造があるので、しかしながら、私たちは、イラストにそれらを使用し続けるつもりです。

      H. Echoing, Interrupts and Code Conversion

H.反響、中断、およびコード変換

         1. Interrupts

1. 中断

            We had been under the impression that all operating systems
            scanned for a reserved character from the keyboard to
            interpret it as an interrupt signal.  Tom Skinner and Ed
            Meyer of MIT inform us that model 37 TTY's and IBM 2741
            generate a "long space" of 200-500 milliseconds which is
            detected by the I/O channel hardware and passed to the
            operating system as an interrupt.  The "long space" is not a
            character -- it has no ASCII code and cannot be program
            generated.

私たちはキーボードからの控え目なキャラクタが割り込み信号としてそれを解釈するようにすべてのオペレーティングシステムがスキャンされたという印象でいました。 MITのトムSkinnerとエド・マイヤーは、37TTYのモデルものとIBM2741が入出力チャンネルハードウェアによって検出されて、中断としてオペレーティングシステムに通過される200-500人のミリセカンドの「長いスペース」を発生させると私たちにお知らせくださいます。 「長いスペース」はキャラクタではありません--それは、ASCIIコードを全く持たないで、発生するプログラムであるはずがありません。

            Well over a year ago, we considered the problem of
            simulating console interrupts and rejected the <INT> type
            command because it didn't correctly model any system we
            knew.  We now reverse our position and recommend the
            implementation of an INTERRUPT system call and an <INT>
            control command as suggested by Meyer in NWG/RFC #46.

それが正しく、私たちが知っていたどんなシステムもモデル化しなかったので、私たちは、はるかに1年以上前に、コンソール割込みをシミュレートするという問題を考えて、<INT>タイプコマンドを拒絶しました。 私たちは、現在、私たちの地位を逆にして、NWG/RFC#46でマイヤーによって提案されるようにINTERRUPTシステムコールと<INT>制御コマンドの実現を推薦します。

Postel & Crocker                                                [Page 9]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[9ページ]RFC48は可能なプロトコル停滞期1970年4月です。

            Two restrictions of the interrupt facility should be
            observed.  First, when communicating with systems which scan
            for interrupt characters, this feature should not be used.
            Second, non-console-like connections probably should not
            have interrupts. We recommend that systems follow their own
            conventions, and if an <INT> arrives for a connection on
            which it shouldn't the <INT> should be discarded and
            optionally returned as an error.

中断施設の2つの制限が観測されるべきです。 中断キャラクタのためにスキャンされるシステムとコミュニケートするとき、まず最初に、この特徴を使用するべきではありません。 2番目に、非コンソールのような接続には、中断がたぶんあるべきではありません。 私たちが、システムがそれら自身のコンベンションに続くことを勧めて、<INT>がそれがそうするべきでない接続のために届くなら、<INT>を捨てて、誤りとして任意に返すべきです。

         2. Echoing and Code Conversion

2. 反響とコード変換

            We believe that each site should continue its current
            echoing policy and that code conversion should be done by
            the using process.  Standardization in this area should
            await further development.

私たちは各サイトが現在の反響政策を存続させるべきであり、使用工程でそのコード変換をするべきであると信じています。 この領域での標準化はさらなる開発を待つべきです。

            Ancona's suggestion of a table-driven front-end transducer
            seems like the right thing, but we believe that such
            techniques are part of a larger discussion involving
            higher-level languages for the network.

アンコナのテーブル駆動のフロントエンド振動子の提案は正しいもののように見えますが、私たちは、そのようなテクニックがネットワークのために、よりハイレベルの言語にかかわるより大きい議論の一部であると信じています。

      I. Broadcast Facilities

I.放送施設

         Heafner and Harslem suggest in NWG/RFC #39 a broadcast
         facility, i.e. <TER> and <BDC>.  We do not fully understand the
         value of this facility and are thus disposed against it.  We
         suspect that we would understand its value better if we had
         more experience with OS/360.  It is probably true in general
         that sites running OS/360 or similar systems will find less
         relevance in our suggestions for network protocol than sites
         running time-sharing systems.  We would appreciate any cogent
         statement on the relationship between OS/360 and the concepts
         and assumptions underlying the network protocol.

HeafnerとHarslemがNWG/RFC#39で放送施設を勧めて、すなわち、<はTER>と<BDC>です。 私たちは、完全にこの施設の値を理解するというわけではなくて、このようにしてそれに対して配列されます。 私たちは、私たちにOS/360の、より多くの経験があるなら値をより理解していると疑います。 一般に、OS/360を走らせるサイトか同様のシステムが、ネットワーク・プロトコルのための私たちの提案におけるサイト実行時間共有システム私たちより少ない関連性が、OS/360と、概念と仮定との関係に関するどんな力強い声明もネットワーク・プロトコルの基礎となるのに感謝するのがわかるのは、たぶん本当です。

      J. Instance Numbers

J.例の番号

         Meyer in NWG/RFC #46 suggests extending a socket to include an
         _instance_ code which identifies the process attached to the
         socket.  We carefully arranged matters so that processes would
         be indistinguishable.  We did this with the belief that both as
         a formal and as a practical matter it is of concern only within
         a Host whether a computation is performed by one or many
         processes.  Thus we believe that all processes within a job
         should cooperate in allocating AEN's.  If an operating system
         has facilities for passing a console from process to process
         within a job, these facilities mesh nicely with the current
         network protocol, even within reconnection protocol; but
         instance numbers interfere with such a procedure.

NWG/RFC#46におけるマイヤーは、ソケットに取り付けられた過程を特定する_例_コードを含むようにソケットを広げることを提案します。 私たちは、過程が区別がつかないように、慎重に繰り合わせました。 計算が1か多くの工程で実行されるか否かに関係なく、私たちはHostだけの中の関心の信念でこれをしました。 したがって、私たちは、仕事の中のすべての過程がAENを割り当てるのに協力するべきであると信じています。 オペレーティングシステムに仕事の中で過程から過程までコンソールを渡すための施設があるなら、これらの施設はうまく現在のネットワーク・プロトコルと合います、再接続プロトコルの中でさえ。 しかし、例の番号はそのような手順を妨げます。

Postel & Crocker                                               [Page 10]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[10ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         We suggest this matter be discussed fully because it relates to
         the basic philosophy of sockets and connections.  Presently we
         recommend 40 bit socket numbers without instance codes.

私たちは、ソケットと接続の基本理念に関連するのでこの件について完全に議論することを提案します。 現在の、私たちは例のコードなしで40ビットのソケット番号を推薦します。

      K. AEN's

K.AENのもの

         Nobody, including us, is particularly happy with our name AEN
         for the low order 8 bits of the socket.  We rejected _socket_
         number_, and are similarly unhappy with Meyer's _socket_code_.
         The word socket should not be used as part of the field name,
         and we solicit suggestions.

ソケットの下位8ビットには、私たちを含まないだれでも私たちの名前AENに特に満足です。 _ソケット_数の_を拒絶して、同様にマイヤーの_ソケット_コード_に不満です。フィールド名の一部として単語ソケットを使用するべきではありません、そして、私たちは提案に請求します。

III. Environment

III。 環境

   We assume that the typical host will have a time-sharing operating
   system in which the cpu is shared by processes.

私たちは、典型的なホストにはcpuが工程で共有される時分割オペレーティングシステムがあると思います。

   Processes

過程

   We envision that each process is tagged with a _user_number_. There
   may be more than one process with the same user number, and if so,
   they should all be cooperating with respect to using the network.

私たちはそれを思い描きます。各過程は_ユーザ_数の_でタグ付けをされます。同じユーザ番号がある1つ以上の過程があるかもしれません、そして、そうだとすれば、彼らは皆、ネットワークを使用することに関して協力するべきです。

   We envision that each process contains a set of _ports_ which are
   unique to the process.  These ports are used for input to or output
   from the process, from or to files, devices or other processes.

私たちはそれを思い描きます。各過程は_過程にユニークなポート_の1セットを含んでいます。 これらのポートは過程からの入力か出力、または、過程かファイルか、装置か他の過程に使用されます。

   We also envision that each process has an event channel over which it
   can receive very short messages (several bits).  We will use this
   mechanism to notify a process that some action external to the
   process has occurred.

また、私たちはそれを思い描きます。各過程に、それが非常に短いメッセージ(数ビット)を受け取ることができるイベントチャンネルがあります。 私たちは、過程への外部の何らかの動きが起こったことを過程に通知するのにこのメカニズムを使用するつもりです。

   To engage in network activity, a process _attaches_ a _local_socket_
   to one of its ports.  Sockets are identified by user number, host and
   AEN, and a socket is local to a process if their user numbers match
   and they are in the same host.  A process need only specify an AEN
   when it is referring to a local socket.

ネットワーク活動に従事するために、過程_は__の地方の_ソケット_をポートの1つに取り付けます。 ソケットはユーザ番号、ホスト、およびAENによって特定されます、そして、それらのユーザ番号が合って、それらが同じホストにあるなら、ソケットは過程に地方です。 地方のソケットについて言及しているとき、過程はAENを指定するだけでよいです。

   Each port has a status which is modified by system calls and by
   concurrent events outside the process.  Whenever the status of a port
   is changed, the process is sent an event over its event channel which
   specifies which port's status has changed.  The process may then look
   at a port's status.

各ポートは過程の外でシステムコールと同時発生の出来事によって変更される状態を持っています。 ポートの状態を変えるときはいつも、過程はどのポートの状態が変化したかを指定するイベントチャンネルの上に出来事を送ります。 そして、過程はポートの状態を見るかもしれません。

   These assumptions are used descriptive material which follows.
   However, these assumptions are not imposed by the network protocol
   and the implementation suggested by section IV is in no way binding.

これらの仮定はいうことになる中古の記述的な材料です。 しかしながら、これらの仮定はネットワーク・プロトコルによって課されません、そして、セクションIVによって示された実現は決して拘束力がありません。

Postel & Crocker                                               [Page 11]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[11ページ]RFC48は可能なプロトコル停滞期1970年4月です。

   We wish to make very clear that this material is offered only to
   provide clues as to what the implementation difficulties might be and
   not to impose any particular discipline.

私たちは、非常にはっきりとそれをこの材料にするのが実現困難が何であるかもしれないかに関して単に手がかりを提供して、少しの特定の規律も課さないように提供されることを願っています。

   For example, we treat <RFC>'s which arrive for unattached local
   sockets as valid and queue them.  If desired, an NCP may reject them,
   as Meyer suggests, or it might hold them for awhile and reject them
   if they're not soon satisfied.  The offered protocol supports all
   these options.

例えば、私たちは、連結していない地方のソケットのために有効であるとして届くRFC>の<ものを扱って、それらを列に並ばせます。 望まれているなら、NCPはそれらを拒絶するかもしれません、マイヤーが示すか、それらがすぐ満たされていないなら、しばらくそれらを保持して、それらを拒絶するかもしれないとき。 提供されたプロトコルはこれらのすべてのオプションをサポートします。

   Another local option is the one mentioned before of attaching
   multiple ports to a socket.  We have shown one-one correspondence but
   this may be ignored.  Similarly, the system calls are merely
   suggestive.

別の地方選択権は以前複数のポートをソケットに取り付けるのについて言及されたものです。 私たちは、通信にもかかわらず、これが無視されるかもしれないのを1-1つに示しました。 同様に、システムコールは単に思わせ振りです。

   System Calls

システムコール

   These are typical system calls which a user process might execute.
   We show these only for completeness; each site will undoubtedly
   implement whatever equivalent set is convenient.

これらはユーザ・プロセスが実行するかもしれない典型的なシステムコールです。 私たちは完全性のためだけにこれらを示しています。 各サイトは確かにどんな便利な同等なセットも実行するでしょう。

        We use the notation

私たちは記法を使用します。

        Syscall ( arg , arg ...; val ... )
                     1     2        1
   where
        Syscall is the system call
        arg  etc. are the parameters supplied with the call, and
           1
        val etc. are any values returned by the system call.
           1

Syscall(argして、…(val)をargします) Syscallがシステムコールargなどである1 2 1は呼び出しが供給されたパラメタです、そして、1valのなどはシステムコールで返されたあらゆる値です。 1

   Init (P,AEN,FS,Bsiz;C)

イニット(P、AEN、FS、Bsiz;、C)

        P      Specifies a port of the process.
        AEN    Specifies a local socket.  The user number of this
               process and host number of this host are implicit.
        FS     Specifies a socket with any user number in any host,
               with any AEN.
        Bsiz   Specified the amount of storage in bits the user wants
               to devote to buffering messages.
        C      The condition code returned.

Pは過程のポートを指定します。 AEN Specifiesのa地方のソケット。 この過程のユーザ番号とこのホストのホスト番号は暗黙です。 どんなユーザ番号もいずれにもあるソケットがどんなAENと共にも接待するFS Specifies。 ユーザがメッセージをバッファリングするのに注ぎたがっているビットの格納の量のBsiz Specified。 条件コードが返したC。

   Init attempts to attach the local socket specified by AEN to the port
   P and to initiate a connection with socket FS.  Possible returned
   values of C are

イニットは、AENによってポートPに指定された地方のソケットを取り付けて、ソケットFSとの接続を開始するのを試みます。 Cの可能な戻り値はそうです。

Postel & Crocker                                               [Page 12]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[12ページ]RFC48は可能なプロトコル停滞期1970年4月です。

        C = ok      The Init was legal and the socket FS is being
                    contacted.  When the connection is established or
                    when FS refuses, the process will receive an event.

CはOKと等しいです。Initは法的でした、そして、ソケットFSは連絡されています。 接続が確立されるか、またはFSが拒否するとき、過程は出来事を受けるでしょう。

        C = busy    The local socket was in use by a port on this or
                    some other process with the same user number.  No
                    action was taken.

C=忙しい、地方のソケットは同じユーザ番号でこれのポートかある他の工程で使用中でした。 行動を全く取りませんでした。

        C = homosex The AEN and FS were either both send or both receive
                    sockets.

C=同性愛関係のAENとFSは両方が送るどちらかであったかともにソケットを受けます。

        C = nohost  The host designated within FS isn't known.

ホストがFSの中で指定したC=nohostは知られていません。

        C = bufbig  Bsiz is too large.

C=bufbig Bsizは大き過ぎます。

   Listen (P,AEN,Bsize;C)

聴いてください。(P、AEN、Bsize;、C)

        P     Specifies a port of the process.
        AEN   Specifies a local socket.
        Bsiz  Specified a buffer size.
        C     The returned legality code.

Pは過程のポートを指定します。 AEN Specifiesのa地方のソケット。 Bsiz Specified aバッファサイズ。 C、返された合法コード。

   Codes for C are

Cコードはそうです。

        C = ok
        C = busy
        C = bufbig

忙しいC=OK C=Cはbufbigと等しいです。

   The local socket specifies by AEN is attached to P.  If there is a
   waiting call, it is processed; otherwise no action is taken.  When a
   call comes in, a connection will be established and the process
   notified via an event.

地方のソケットは取り付けられたAENでP.に指定します。そこのIfが待ち呼び出しである、それは処理されます。 さもなければ、行動を全く取りません。 呼び出しが入るとき、接続は確立して、過程は出来事を通して通知されています。

   Close (P)

閉鎖(p)

        P Specifies a port of the process.

Pは過程のポートを指定します。

   Any activity is stopped, and the port becomes free for other use.

どんな活動も止められます、そして、ポートは他の使用に自由になります。

   Transmit (P,M,L1;L2,C)

伝わってください。(P、M、L1; L2、C)

        P     Specifies port with an open connection.
        M     The text to be transmitted.
        L1    Specifies the length of the text.
        L2    The length actually transmitted.
        C     The error code.

Pはオープンな接続と共にポートを指定します。 M、伝えられるべきテキスト。 L1はテキストの長さを指定します。 長さが実際に伝えたL2。 C、エラーコード。

Postel & Crocker                                               [Page 13]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[13ページ]RFC48は可能なプロトコル停滞期1970年4月です。

   Transmission between the processes on either side of the port takes
   place.

ポートのどちらかの端の過程の間のトランスミッションは行われます。

   Codes for C are

Cコードはそうです。

        C = ok
   or
        C = not open     if no connection is currently open and
                         otherwise uninhibited
   Status (P;C)

C=OKかCはどんな接続も現在、開いていてそうでなければ、遠慮のないStatusでないならどんな戸外とも等しくはありません。(P; C)

   The status of port P is returned as C.

ポートPの状態はCとして返されます。

IV. The NCP

IV。 NCP

   We view the NCP as having five component programs, three associative
   tables, some queues and buffers, and a link assignment table.  Each
   site will of course, vary this design to meet its needs, so our
   design is only illustrative.

私たちは5つのコンポーネントプログラム、3個の結合しやすいテーブル、いくつかの待ち行列、バッファ、およびリンク課題テーブルを持っているとNCPをみなします。 各サイトはもちろん説明に役立つでしょう、このデザインを変えて、単に需要を満たしてください、したがって、私たちのデザインは説明に役立っています。

   The Component Programs

コンポーネントプログラム

      1. The Input Handler

1. 入力操作者

         This is an interrupt driven input routine.  It initiates Imp-
         to-Host transmission into a resident buffer and wakes up the
         Input Interpreter when transmission is complete.

これは入力日常的にされた中断です。 それは、ホストへのImpトランスミッションに居住しているバッファを伝授して、トランスミッションが完全であるときに、Input Interpreterを起こします。

      2. The Output Handler

2. 出力操作者

         This is an interrupt driven output routine.  It initiates
         Host-to-Imp transmission out of a resident buffer and wakes up
         the Output Scheduler when transmission is complete.

これは出力日常的にされた中断です。 それは、居住しているバッファからHostから悪童へのトランスミッションを開始して、トランスミッションが完全であるときに、Output Schedulerを起こします。

      3. The Input Interpreter

3. 入力インタプリタ

         This program decides whether the input is a regular message
         intended for a user, a control message, an Imp-to-Host message,
         or an error.  For each class of message, this program takes the
         appropriate action.

このプログラムは、入力がユーザのために意図する、通常のメッセージ、コントロールメッセージ、Impからホストへのメッセージ、または誤りであるかを決めます。 それぞれのクラスに関するメッセージのために、このプログラムは適切な行動を取ります。

      4. The Output Scheduler

4. 出力スケジューラ

         Three classes of message are sent to the Imp

メッセージの3つのクラスをImpに送ります。

            (a) Host-to-Imp messages
            (b) Control messages
            (c) Regular messages

(a) ホストから悪童メッセージ(b)コントロールメッセージ(c)通常のメッセージ

Postel & Crocker                                               [Page 14]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[14ページ]RFC48は可能なプロトコル停滞期1970年4月です。

         We believe that a priority should be imposed among these
         classes.  The priority we suggest is the ordering above. The
         Output Scheduler selects the highest priority message and
         gives it to the Output Handler.

私たちは、優先がこれらのクラスで課されるべきであると信じています。 優先権は上での私たちが、示唆する注文です。 Output Schedulerは最優先メッセージを選択して、それをOutput Handlerに与えます。

      5. The System Call Interpreter

5. システムコールインタプリタ

         This program interprets requests from the user.

このプログラムはユーザからの要求を解釈します。

   The two interesting components are the Input Interpreter and the
   System Call Interpreter.  These are similar in that the Input
   Interpreter services foreign requests and the System Call Interpreter
   services local requests.

2つのおもしろいコンポーネントが、Input InterpreterとSystem Call Interpreterです。 これらはInput Interpreterが外国要求を修理するという点において同様です、そして、System Call Interpreterはローカルの要求を修理します。

   Associative Tables

結合しやすいテーブル

   We envision that the bulk of the NCP's data base is in three
   associative tables.  By "associative", we mean that there is some
   lookup routine which is presented with a key and either returns
   successfully with a pointer to the corresponding entry, or fails if
   no entry corresponds to the key.

私たちはそれを思い描きます。NCPのデータベースの大半が3個の結合しやすいテーブルにあります。 「結合しやすいこと」で、私たちは、キーを与えて、首尾よく対応するエントリーにポインタとともに帰るか、またはエントリーが全くキーに対応していないなら失敗する何らかのルックアップルーチンがあると言っています。

      1. The Rendezvous Table

1. ランデブーテーブル

         "Requests-for-connection" and other attributes of a
         connection are held in this table.  This table is accessed by
         local socket, but other tables have pointers to existing
         entries.

「接続を求める要求」と接続の他の属性はこのテーブルに保持されます。 このテーブルは地方のソケットによってアクセスされますが、他のテーブルは既存のエントリーにポインタを持っています。

            The components of an entry are:

エントリーのコンポーネントは以下の通りです。

            (a) local socket   (key)
            (b) foreign socket
            (c) link
            (d) queue of callers
            (e) text queue
            (f) connection state
            (g) flow state
            (h) pointer to attached port

(a) 付属ポートへの訪問者(e)テキスト待ち行列(f)接続状態(g)流れ状態(h)ポインタの地方のソケットの(主要)の(b)外国ソケット(c)リンク(d)待ち行列

            An entry is created when a user executes either an Init or a
            Listen system call or when a <RFC> is received.  Some fields
            are unused until the connection is established, e.g. the
            foreign socket is not known until a <RFC> arrives if the
            user did a Listen.

ユーザがInitかListenシステムコールのどちらかを実行するか、または<RFC>が受け取られているとき、エントリーは作成されます。 接続が確立されるまでいくつかの分野が未使用である、例えば、ユーザがListenをしたなら<RFC>が届くまで、外国ソケットは知られていません。

Postel & Crocker                                               [Page 15]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[15ページ]RFC48は可能なプロトコル停滞期1970年4月です。

      2. The Input Link Table

2. 入力リンクテーブル

            The Input Interpreter uses the foreign host and link as a
            key to get a pointer to the entry in the rendezvous table
            for the connection using the incoming link.

Input Interpreterは、入って来るリンクを使用することで接続のためのランデブーテーブルのエントリーにポインタを届けるのにキーとして異種宿主とリンクを使用します。

      3. The Output Link Table

3. 出力リンクテーブル

            In order to interpret RFNM's, the Input Interpreter needs a
            table in the same form as the Input Link Table but using
            outgoing links.

RFNMのものを解釈するために、Input InterpreterはInput Link Tableにもかかわらず、使用の出発しているリンクと同じフォームでテーブルを必要とします。

   Link Assignment Table

リンク課題テーブル

   This is a very simple structure which keeps track of which links are
   in use for each host.  One word per host probably suffices.

これは各ホストにとって、リンクが使用中である道を保つ非常に簡単な構造です。 1ホストあたり1つの単語がたぶん十分です。

   The following diagram is our conception of the Network Control
   Program.  Boxes represent tables and Buffers, boxes with angled
   corners and a double bottom represent Queues, and jagged boxes
   represent component programs, the arrows represent data paths.

以下のダイヤグラムは私たちのNetwork Control Programに関する概念です。 箱はテーブルとBuffersを表します、そして、傾けられた角と二重下部がある箱はQueuesを表します、そして、ぎざぎざの箱はコンポーネントプログラムを表します、そして、矢はデータ経路を表します。

   The abbreviated names have the following meanings.

略称には、以下の意味があります。

   ILT   - Input Link Table

ILT--入力リンクテーブル

   OLT   - Output Link Table

OLT--出力リンクテーブル

   LAT   - Link Assignment Table

LAT--リンク課題テーブル

   RT    - Rendezvous Table

RT--ランデブーテーブル

   HIQ   - Host to Imp Queue

HIQ--悪童待ち行列へのホスト

   OCCQ  - Output Control Command Queue

OCCQ--アウトプット・コントロールコマンド待ち行列

   ORMQ  - Output Regular Message Queue

ORMQ--出力の通常のメッセージキュー

   IHBuf - Buffer filled by the Input Handler from the IMP and
           emptied by the Input Interpreter

IHBuf--Input HandlerによってIMPからいっぱいにされて、Input Interpreterによって空にされたバッファ

   OHBuf - Buffer of outgoing messages filled from the Queues
           by the Output Scheduler and emptied by the Output
           Handler.

OHBuf--送信されるメッセージに関するバッファは、Output SchedulerのそばでQueuesからいっぱいになって、Output Handlerで空になりました。

Postel & Crocker                                               [Page 16]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[16ページ]RFC48は可能なプロトコル停滞期1970年4月です。

                              +---------+
                              |  I M P  |
                              +---------+
                                v     ^
                                |     |
    +---------------------------|-----|------------------------------+
    |                           |     |                              |
    |   /\/\/\/\/\/\/\          |     |     /\/\/\/\/\/\/\           |
    |   \            / <--------+     +---< \            /           |
    |   /  Input     \                      /  Output    \           |
    |   \   Handler  /                      \   Handler  / <----+    |
    |   /            \ >------+             /            \      |    |
    |   \/\/\/\/\/\/\/        |             \/\/\/\/\/\/\/      ^    |
    |                         v                              +-----+ |
    |                      +-----+                           | OH  | |
    |                      | IM  |                           | Buf | |
    |                      | Buf |                           +-----+ |
    |                      +-----+          /\/\/\/\/\/\/\/\    ^    |
    | /\/\/\/\/\/\/\/\        v      +----> \              /    |    |
    | \              /        |      |      /  Output      \ >--+    |
    | /              \ <------+      ^      \              /         |
    | \  Input       /           /-----\    /   Scheduler  \         |
    | /              \ >-------->| HIQ |    \              /         |
    | \  Interpreter /           |_____|    /              \         |
    | /              \ >----+    \_____/    \/\/\/\/\/\/\/\/         |
    | \/\/\/\/\/\/\/\/      |                ^     v    ^            |
    |   ^   ^    ^   \      |    /-----\     |     |    |    /-----\ |
    |   |    \    \   \     |    |  O  |     |     |    |    |  O  | |
    |   |     \    \   \    +--->|  C  |>----+     |    +---<|  R  | |
    |   v     v     v   \        |  C  |           |         |  M  | |
    | +---+ +---+ +---+  \       |  Q  |           v         |  Q  | |
    | |   | |   | |   |   \      |_____|      +---------+    |_____| |
    | |ILT| |LAT| |OLT|    \     \_____/      |         |    \_____/ |
    | |   | |   | |   |     \       ^         |   R T   |       ^    |
    | +---+ +---+ +---+      +------|-------->|         |       |    |
    |         v                     |         +---------+       |    |
    |         |                     ^              ^            |    |
    |         |            /\/\/\/\/\/\/\/\        |            |    |
    |         |            \              /        |            |    |
    |         +----------->/    System    \<-------+            |    |
    |                      \     Call     /                     |    |
    |                      /  Interpreter \>--------------------+    |
    |                      \              /                          |
    |                  +-->/              \>--+                      |
    |                  |   \/\/\/\/\/\/\/\/   |                      |
    +------------------|----------------------|----------------------+
                       |                      |
                       +---< system calls <---+

+---------+ | I M P| +---------+ ^に対して| | +---------------------------|-----|------------------------------+ | | | | | /\/\/\/\/\/\/\ | | /\/\/\/\/\/\/\ | | \/<。--------+ +---<\/| | /入力\/出力\| | \操作者/\操作者/<。----+ | | /\>。------+ / \ | | | \/\/\/\/\/\/\/ | \/\/\/\/\/\/\/ ^ | | +に対して-----+ | | +-----+ | おお| | | | 不-| | Buf| | | | Buf| +-----+ | | +-----+ /\/\/\/\/\/\/\/\ ^ | | /\/\/\/\/\/\/\/\対+---->\/| | | \ / | | /出力\>--+| | /\<。------+ ^ \ / | | \入力//-----\/スケジューラ\| | /\>。-------->| HIQ| \ / | | \インタプリタ/|_____| / \ | | /\>。----+ \_____/ \/\/\/\/\/\/\/\/ | | \/\/\/\/\/\/\/\/ | ^^に対して| | ^ ^ ^ \ | /-----\ | | | /-----\ | | | \ \ \ | | O| | | | | O| | | | \ \ \ +--->| C| >、-、-、--+ | +---<| R| | | v対\に| C| | | M| | | +---+ +---+ +---+ \ | Q| v| Q| | | | | | | | | \ |_____| +---------+ |_____| | | |ILT| |LAT| |オルト川| \ \_____/ | | \_____/ | | | | | | | | \ ^ | R T| ^ | | +---+ +---+ +---+ +------|、-、-、-、-、-、-、--、>|、|、|、|、| v| +---------+ | | | | ^ ^ | | | | /\/\/\/\/\/\/\/\ | | | | | \ / | | | | +----------->/システム\<。-------+ | | | \呼び出し/| | | /インタプリタ\>。--------------------+ | | \ / | | +-->/\>--+| | | \/\/\/\/\/\/\/\/ | | +------------------|----------------------|----------------------+ | | +---<システムコール<。---+

Postel & Crocker                                               [Page 17]

RFC 48                A Possible Protocol Plateau             April 1970

ポステルとクロッカー[17ページ]RFC48は可能なプロトコル停滞期1970年4月です。

       [ This RFC was put into machine readable form for entry ]
   [ into the online RFC archives by Donald and Jill Eastlake 1999 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ドナルドとジル・イーストレーク1999によるオンラインRFCアーカイブへの]

[Editor's note: The original hand-drawn diagram represented
Queues by cylinders and component programs by "squishy ameoba
like things".]

[編集者注: オリジナルの手で描かれたダイヤグラムは「ぐにゃぐにゃのameobaはものが好きです」のようなシリンダとコンポーネントプログラムでQueuesを表しました。]

Postel & Crocker                                               [Page 18]

ポステルとクロッカー[18ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

sudo 指定したユーザーでコマンドを実行する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る