RFC61 日本語訳
0061 Note on Interprocess Communication in a Resource Sharing ComputerNetwork. D.C. Walden. July 1970. (Format: TXT=43946 bytes) (Obsoleted by RFC0062) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Dave Walden
Request for Comments: 61 Bolt Beranek and Newman
July 17, 1970
コメントを求めるワーキンググループデーヴウォルデンRequestをネットワークでつないでください: 61 ボルトBeranekと1970年7月17日のニューマン
A Note on Interprocess Communication
in a Resource Sharing Computer Network
リソース・シェアリングコンピュータネットワークのプロセス間通信に関する注
The attached note is a draft of a study I am still working on. It may be of general interest to network participants.
添付の注意は私がまだ働いている研究の草稿です。 それはネットワーク関係者への一般的興味のものであるかもしれません。
Walden [Page 1] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[1ページ]RFC61プロセス間通信
Interprocess Communication
in a
Resource Sharing Computer Network
リソース・シェアリングコンピュータネットワークのプロセス間通信
INTRODUCTION
序論
"A resource sharing computer network is defined to be a set of autonomous, independent computer systems, interconnected so as to permit each computer system to utilize all of the resources of each other computer system. That is, a program running in one computer system should be able to call on the resources of the other computer systems much as it would normally call a subroutine." This definition of a network and the desirability of such a network is expounded upon by Roberts and Wessler in [1].
「リソース・シェアリングコンピュータネットワークが各コンピュータ・システムが互いに関するリソースのすべてを利用することを許可するためにインタコネクトされた1セットの自治の、そして、独立しているコンピュータ・システムになるように定義される、コンピュータ・システム、」 「すなわち、1個のコンピュータ・システムへ駆け込むプログラムは通常、サブルーチンを呼び出すように他のコンピュータ・システムに関するリソースを訪問するはずであることができます。」 ネットワークが[1]でロバーツとWesslerによって述べられるネットワークのこの定義とそのようなものの願わしさ。
The actual act of resource sharing can be performed in two ways: in a pairwise ad hoc manner between all pairs of computer systems in the network or according to a systematic network wide standard. This paper develops one possible network wide system for resource sharing.
2つの方法でリソース・シェアリングの実際の行為を実行できます: ネットワークにおける、すべての組のコンピュータ・システムの間の対状の臨時の方法か系統的なネットワーク広い規格に従って。 この紙はリソース・シェアリングの1台の可能なネットワーク広いシステムを開発します。
I believe it is natural to think of resources as being associated with processes [2] and therefore view the fundamental problem of resource sharing to be the problem of interprocess communication. I also share with Carr, Crocker, and Cerf [3] the view that interprocess communication over a network is a subcase of general interprocess communication in a multiprogrammed environment.
私は、プロセス[2]に関連しているとリソースを考えて、したがって、プロセス間通信の問題になるようにリソース・シェアリングの基本的な問題を見なすのが当然であると信じています。 また、私はネットワークの上のプロセス間通信がマルチプログラムの環境における一般的なプロセス間通信に関する「副-ケース」であるという意見をカー、クロッカー、およびサーフ[3]と共有します。
These views pervade this study and have led to a two part study. First, a model for a time-sharing system having capabilities particularly suitable for enabling interprocess communication is constructed. Next, it is shown that these capabilities can be easily used in a generalized manner which permits interprocess communication between processes distributed over a computer network.
これらの視点は、この研究を瀰漫させて、2部分研究につながりました。 まず最初に、能力を特にプロセス間通信を可能にするのに適当にする時分割システムのためのモデルは構成されます。 次に、どれがコンピュータネットワークの上に分配されたプロセスの間のプロセス間通信を可能にするかは一般化された方法で容易にこれらの能力を使用できるのが示されます。
This note contains ideas based on many sources. Particularly influential were -- 1) an early sketch of a Host protocol for the ARPA Network [1][3][4] by W. Crowther of Bolt Beranek and Newman Inc. (BBN) and S. Crocker of UCLA; 2) Ackerman and Plummer's paper on the MIT PDP-1 time sharing system [5]; and 3) discussion with R. Kahn of BBN about Host protocol, message control, and routing for the ARPA Network. Hopefully, there are also some original ideas in this note. I alone am responsible for the collection of all of these ideas into the system described herein, and I am therefore responsible for any inconsistencies or bugs in this system.
この注意は多くのソースに基づく考えを含んでいます。 特に有力である、--1) Bolt Beranekとニューマン株式会社(BBN)のW.クラウザーとUCLAのS.クロッカーによるアーパネット[1][3][4]のためのHostプロトコルの早めのスケッチ。 2) MIT PDP-1タイムシェアリングシステム[5]に関するアッカーマンとプラマーの論文。 そして、アーパネットのためのHostプロトコル、メッセージ制御、およびルーティングの周りのBBNのR.カーンとの3)議論。 また、うまくいけば、この注意にはいくつかの着想があります。 私だけがここに説明されたシステムへのこれらの考えのすべての収集に責任があります、そして、したがって、このシステムのどんな矛盾や欠陥にも責任があります。
It must be emphasized that this note does not represent an official BBN position on Host protocol for the ARPA Computer Network.
この注意がARPAコンピュータNetworkのためにHostプロトコルに公式のBBN位置を表さないと強調しなければなりません。
Walden [Page 2] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[2ページ]RFC61プロセス間通信
A MODEL FOR A TIME-SHARING SYSTEM
時分割システムのためのモデル
This section describes a model time-sharing system which I think is particularly suitable for performing interprocess communication. The basic structure of this model time-sharing system is not original [5][9].
このセクションは私が特にプロセス間通信を実行するのに適当であると思うモデル時分割システムについて説明します。 このモデル時分割システムの基本構造はオリジナルの[5][9]ではありません。
The model time-sharing system has two pieces: the monitor and the processes. The monitor performs several functions, including switching control from process to process as appropriate (e.g., when a process has used "enough" time or when an interrupt occurs), managing core and the swapping medium, controlling the passing of control from one process to another (i.e., protection mechanisms), creating processes, caring for sleeping processes, etc.
モデル時分割システムには、2つの断片があります: モニターとプロセス。 モニターはいくつかの機能を実行します、適宜(例えば、プロセスがいつ「十分な」時間を費やしたか、そして、または中断はいつ発生しますか)処理するプロセスからコントロールを切り換えるのを含んでいて、コアとスワッピング媒体を管理して、コントロールの1つのプロセスから別のもの(すなわち、保護メカニズム)までの通過を制御して、プロセスを作成して、眠っているプロセスなどを保護していて
The processes perform most of the functions normally thought of as being supervisor functions in a time-sharing system (system processes) as well as the normal user functions (user processes). A typical system process is the disc handler or the file system. For efficiency reasons it may be useful to think of system processes as being locked in core.
プロセスは通常、正常なユーザ機能(ユーザ・プロセス)と同様に時分割システム(システム工程)での監督機能であるとして考えられた機能の大部分を実行します。 典型的なシステム工程は、ディスク操作者かファイルシステムです。 効率理由に、コアが閉じ込められるとシステム工程を考えるのは役に立つかもしれません。
A process can call on the monitor to perform several functions: start another, equal, autonomous process (i.e., load a program or find a copy of a program somewhere that can be shared, start it, and pass it some initial parameters); halt the running process; put the current process to sleep pending a specified event; send a message to a specified process; become available to receive a message from a specified process; become available to receive a message from any process; send a message to a process able to receive from any process; and request a unique number. There undoubtedly should also be other monitor functions. It is left as an exercise to the reader to convince himself that the monitor he is saddled with can be made to provide these functions -- most can.
プロセスは、モニターがいくつかの機能を実行するよう呼びかけることができます: 別のものを始めてください、等しいです、自治のプロセス(すなわち、プログラムをロードするか、それを共有できるところでプログラムのコピーを見つけてください、そして、それを始めてください、そして、またはいくつかの初期値パラメタをそれに通過してください)。 実行しているプロセスを止めてください。 指定されたイベントまで現在のプロセスを寝かしてください。 指定されたプロセスにメッセージを送ってください。 指定されたプロセスからメッセージを受け取るために利用可能になってください。 どんなプロセスからもメッセージを受け取るために利用可能になってください。 どんなプロセスからも受信できるプロセスにメッセージを送ってください。 そして、ユニークな数を要求してください。 また、確かに、他のモニター機能があるべきです。 読者への運動として、それが、彼が負わせられているモニターにこれらの機能を提供させることができると自分に納得させるのが残されます--大部分はそうすることができます。
I will not concern myself with protection considerations here, but instead will assume all of the processes are "good" processes which never make any mistakes. If the reader needs a protection structure to keep in mind while he reads this note, the _capability_ system described in [5][6][7][8] should be satisfying.
私は、ここで保護問題に携わりませんが、プロセスのすべてがどんな誤りも決してしない「良い」プロセスであると代わりに思うつもりです。 読者が彼がこの注意を読んでいる間、念頭に保つために保護構造を必要とするなら、[5][6][7][8]で説明された_能力_システムは満足させられているはずです。
We now look a little closer at the eight operations listed above that a process can ask the monitor to perform.
私たちは今、少しプロセスが、モニターが実行するように頼むことができる上に記載された8つの操作ときの近くを見ます。
Walden [Page 3] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[3ページ]RFC61プロセス間通信
START. This operation starts another process. It has two parameters -- some kind of identification for the program that is to be loaded and a parameter list for that program. Once the program is loaded, it is started at its given entry point and passed its parameter list in some well known manner. The process will continue to exist until it halts itself.
始まってください。 この操作は別のプロセスを始めます。 それには、2つのパラメタがあります--ロードされていることになっているプログラムのためのある種の識別とそのプログラムのためのパラメータ・リスト。 プログラムがいったんロードされていると、それは何らかのよく知られている方法で与えられたエントリー・ポイントで始められて、パラメータ・リストを渡されます。 それ自体を止めるまで、プロセスは存続するでしょう。
HALT. This operation puts the currently running process to sleep pending the completion of some event. The operation has one parameter, the event to be waited for. Sample events are arrival of a hardware interrupt, arrival of a message from another process, etc. The process is restarted at the instruction after the SLEEP command. The monitor never unilaterally puts a process to sleep except when the process overflows its quantum.
停止してください。 この操作は何らかのイベントの完成まで現在稼働しているプロセスを寝かします。 操作には、1つのパラメタ、待たれるイベントがあります。 サンプルイベントはハードウェア割込みの到着、別のプロセスからのメッセージの到着ですなど。 SLEEPが命令した後にプロセスは指示のときに再開されます。 プロセスを量子からはみ出させる時以外に、モニターは一方的にプロセスを決して寝かしません。
RECEIVE. This operation allows another process to send a message to this process. The operation has four parameters: the port (defined below) awaiting the message, the port a message will be accepted from, a specification of the buffer available to receive the message, and a location of transfer to when the transmission is complete. [In other words, an interrupt location. Any message port may be used to allow interrupts, event channels, etc. The user programs what he wants.]
受信してください。 この操作で、別のプロセスはこのプロセスにメッセージを送ることができます。 操作には、4つのパラメタがあります: メッセージを待つポート(以下では、定義される)、メッセージが受け入れられるポート、メッセージを受け取るために利用可能なバッファの仕様、およびトランスミッションが完全である時への転送の位置。 [言い換えれば、中断位置。 どんなメッセージポートも、中断、イベントチャンネルなどを許容するのに使用されるかもしれません。 ユーザは欲しいものをプログラムします。]
SEND. This operation sends a message to some other process. [I suppose a process could also send a message to itself.] It has four parameters: a port to send the message to, the port the message is being sent from, the message, and a location to transfer to when the transmission is complete.
発信してください。 この操作はある他のプロセスにメッセージを送ります。 [私は、また、プロセスがメッセージをそれ自体に送るかもしれないと思います。] それには、4つのパラメタがあります: トランスミッションが完全である時まで移すメッセージを送るポート、メッセージが送られるポート、メッセージ、および位置。
RECEIVE ANY. This operation allows any process to send a message to this process. The operation has four parameters: the port awaiting the message, the buffer available to receive the message, a location to transfer to when the message is received, and a location where the port which sent the message may be noted.
何でも受信してください。 この操作で、どんなプロセスもこのプロセスにメッセージを送ることができます。 操作には、4つのパラメタがあります: メッセージ(メッセージ、メッセージが受信されている時まで移す位置、およびメッセージを送ったポートが述べられるかもしれない位置を受け取るために利用可能なバッファ)を待つポート。
SEND FROM ANY. This operation allows a process to send a message to a process able to receive a message from any process. It has the same four parameters as SEND. The necessity for this operation will be discussed below.
いずれからも、発信してください。 この操作で、プロセスはどんなプロセスからもメッセージを受け取ることができるプロセスにメッセージを送ることができます。 それには、SENDと同じ4つのパラメタがあります。 以下でこの操作の必要性について議論するでしょう。
UNIQUE. This operation obtains a unique number from the monitor.
ユニーク。 この操作はモニターからユニークな数を得ます。
A _port_ is a particular data path to or from a process. All ports have an associated unique number which is used to identify the port. Ports are used in transmitting messages from one process to another in the following fashion. Consider two processes, A and B, wishing to communicate. Process A executes a RECEIVE at port N from port M.
_ポート_はプロセスかプロセスからの特定のデータ経路です。 すべてのポートには、ポートを特定するのに使用される関連ユニークな数があります。 ポートは以下のファッションで1つのプロセスから別のプロセスまでメッセージを送る際に使用されます。 交信することを願っていて、2プロセス、A、およびBを考えてください。 プロセスAはポートNでポートMからRECEIVEを実行します。
Walden [Page 4] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[4ページ]RFC61プロセス間通信
Process B executes a SEND to port N from port M. The monitor matches up the port numbers and transfers the message from process B to process A. As soon as the buffer has been fully transmitted out of process B, process B is restarted at the location specified in the SEND operation. As soon as the message is fully received at process A, process A is restarted at the location specified in the RECEIVE operation. Just how the processes come by the correct port numbers with which to communicate with other processes is not the concern of the monitor -- this problem is left to the processes.
プロセスBは、モニターがポートナンバーに合わせるポートM.からのNを移植するためにSENDを実行して、バッファがプロセスBから完全に伝えられたようにすぐA.Asを処理するためにプロセスBからメッセージを移して、プロセスBはSEND操作で指定された位置で再開されます。 プロセスAにメッセージを完全に受け取るとすぐに、プロセスAはRECEIVE操作で指定された位置で再開されます。 プロセスはいったい、どう、他のプロセスで交信するのが、モニターの関心でない適度のポートナンバーを得るか--この問題はプロセスに残されます。
An example. Suppose that our model time-sharing system is initialized to have several processes always running. Additionally, these permanent processes have some universally known and permanently assigned ports. [Or perhaps there is only one permanently known port which belongs to a directory-process which keeps a table of permanent-process/well-known-port associations.] Suppose that two of the permanently running processes are the logger-process and the teletype-scanner-process. When the teletype-scanner-process first starts running, it puts itself to sleep awaiting an interrupt from the hardware teletype scanner. The logger-process initially puts itself to sleep awaiting a message from the teletype-scanner-process via well-known permanent SEND and RECEIVE ports. The teletype- scanner-process keeps a table indexed by teletype number containing in each entry a port to send characters from that teletype to, and a port at which to receive characters for that teletype. If a character arrives (waking up the teletype-scanner-process) and the process does not have any entry for that teletype, it gets a pair of unique numbers from the monitor (via UNIQUE) and sends a message containing this pair of numbers to the logger-process using the ports that the logger-process is known to have a RECEIVE pending for. [Actually, the scanner process could always use the same pair of port numbers for a particular teletype as long as they were passed on to only one copy of the executive at a time.] The scanner-process also enters the pair of numbers in the teletype table, and sends the characters and all future characters from this teletype to the port with the first number from the port with the second number. The scanner-process probably also passes a second pair of unique numbers to the logger-process for it to use for teletype output and does a RECEIVE using these numbers. The logger-process when it receives the message from the scanner-process, starts up a copy of what SDS 940 TSS [12] users call the executive (that program which prints file directories, tells who is on other teletypes, runs subsystems, etc.) and passes this copy of the executive, the port numbers so this executive-process can also do its in's and out's to the teletype using these ports. If the logger-process wants to get a job number and password from the user, it can temporarily use the port numbers to communicate with the user before it passes them on to the executive.
例。 私たちのモデル時分割システムがいくつかのプロセスをいつも稼働させるように初期化されると仮定してください。 さらに、これらの永久的なプロセスには、いくつかの一般に知られていて、永久に割り当てられたポートがあります。 または、永久に、1つしかありません。[よく知られる永久的なプロセス/ポートのテーブルが協会であることを保つディレクトリプロセスに属すポートを知っている、] 2つの永久に稼働しているプロセスがきこりプロセスとテレタイプスキャナプロセスであると仮定してください。 テレタイプスキャナプロセスが最初に稼働し始めるとき、それはハードウェアテレタイプスキャナから中断を待つ睡眠にそれ自体をつけます。 きこりプロセスは初めは、よく知られる永久的なSENDとRECEIVEポートを通してそれ自体をテレタイプスキャナプロセスからメッセージを待つ睡眠につけます。 テレタイプスキャナプロセスは、各エントリーにそのテレタイプからのキャラクタを送るポート、およびそのテレタイプのためにキャラクタを受けるポートを保管しているテレタイプ番号でテーブルに索引をつけ続けます。 キャラクタが到着して(テレタイプスキャナプロセスで目覚めて)、プロセスにそのテレタイプのためのエントリーが少しのないなら、それは、きこりプロセスが未定のRECEIVEを持つのが知られているポートを使用することでモニター(UNIQUEを通した)から1組のユニークな数を得て、数のこの組を含むメッセージをきこりプロセスに送ります。 [実際に、それらが一度に幹部社員のコピー1部だけに通過された限り、スキャナプロセスは特定のテレタイプにいつもポートナンバーの同じ組を使用するかもしれません。] スキャナプロセスは、また、数の組にテレタイプテーブルに入って、最初の数と共に2番目の数でキャラクタとすべての将来のキャラクタをポートからこのテレタイプからポートに追い出します。 スキャナプロセスは、また、たぶんそれがテレタイプ出力に使用するきこりプロセスにユニークな数の2番目の組を通過して、これらの数を使用することでRECEIVEをします。 それであるときに、また、この幹部社員プロセスがコネのものができるように、きこりプロセスは、スキャナプロセスからメッセージを受け取って、SDS940TSS[12]ユーザが幹部社員(ファイルディレクトリを印刷して、だれが他のテレタイプの上にいるかを言って、サブシステムを実行するなどそのプログラム)と呼ぶことに関するコピーを立ち上げて、幹部社員、ポートナンバーのこのコピーを渡します、そして、外に、テレタイプ使用へのこれらのポートがあります。 ユーザから職務番号とパスワードを得るきこりプロセス必需品であるなら、それは、それらを幹部社員に渡す前にユーザとコミュニケートするのに一時ポートナンバーを使用できます。
Walden [Page 5] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[5ページ]RFC61プロセス間通信
_Port numbers_ are often passed among processes. More rarely, a port is transferred to another process. It is crucial that once a process transfers a _port_ to some other process that the first process no longer use the port. We could add a mechanism that enforces this. The protected object system of [8] is one such mechanism. [Of course, if the protected object system is available to us, there is really no need for two port numbers to be specified before a transmission can take place. The fact that a process knows an existing RECEIVE port number is prima facie evidence of the process' right to send to that port. The difference between RECEIVE and RECEIVE ANY ports then depends solely on the number of copies of a particular port number that have been passed out. A system based on this approach would clearly be preferable to the one described here if it was possible to assume all of the autonomous time-sharing system in a network would adopt this protection mechanism. If this assumption cannot be made, it seems more practical to require both port numbers.]
_ポートナンバー_はプロセスの中でしばしば渡されます。 よりめったに、ポートは別のプロセスに移されません。 プロセスがいったん1番目が処理するある他のプロセスに_ポート_を移すとそれがもうポートを使用しないのは、重要です。 私たちはこれを実施するメカニズムを加えることができました。 [8]の保護されたオブジェクトシステムはそのようなメカニズムの1つです。 [もちろん、私たちにとって、保護されたオブジェクトシステムが利用可能であるなら、トランスミッションが行われることができる前に2つのポートナンバーが指定される必要は本当に全くありません。 プロセスが既存のRECEIVEポートナンバーに知っている事実は一見したところではそのポートに発信する過程の権利に関する証拠です。 そして、RECEIVEとRECEIVE ANYポートの違いは唯一配られた指定港番号のコピーの数に依存します。 このアプローチに基づくシステムはネットワークにおける自動時分割システムのすべてがこの保護メカニズムを採用すると仮定するのが可能であったならここで説明されたものより明確に望ましいでしょう。 この仮定をすることができないなら、両方のポートナンバーを必要とするのは、より実用的に思えます。]
Note that somewhere in the monitor there must be a table of port numbers associated with processes and restart locations. The table entries are cleared after each SEND/RECEIVE match is made. Also note that if a process is running (perhaps asleep), and has RECEIVE ANY pending, then any process knowing the receive port number can talk to that process without going through loggers or any of that. This is obviously essential within a local time-sharing system and seems very useful in a more general network if the ideal of resource sharing is to be reached.
プロセスと再開位置に関連しているポートナンバーのテーブルがそこにモニターのどこかにあるに違いないことに注意してください。 それぞれのSEND/RECEIVEマッチが作られた後にテーブル項目はクリアされます。 また、プロセスが稼働していて(恐らく眠っている)、未定のRECEIVE ANYを持っているならいずれも知っていることを処理することに注意してください、数がそのきこりかいずれも通らないでそのプロセスと話すことができるポートを受けてください。 これは、現地時間の共有しているシステムの中で明らかに不可欠であり、リソース・シェアリングの理想が達することであるなら、より一般的なネットワークで非常に役に立つように見えます。
When a SEND is executed, nothing happens until a matching RECEIVE is executed. If a proper RECEIVE is not executed for some time the SEND is timed out after a while and the SENDing process is notified. If a RECEIVE is executed but the matching SEND does not happen for a long time, the RECEIVE is timed out and the RECEIVing process is notified.
SENDが実行されるとき、合っているRECEIVEが実行されるまで、何も起こりません。 適切なRECEIVEがしばらく実行されないなら、SENDはしばらくしてから調節されています、そして、SENDingプロセスは通知されます。 RECEIVEが実行されるか、しかし、合っているSENDは長い間、起こりません、そして、RECEIVEは外で調節されています、そして、RECEIVingプロセスは通知されます。
A RECEIVE ANY never times out, but may be taken back. A SEND FROM ANY message is always sent immediately and will be discarded if a proper receiver does not exist. An error message is not returned and acknowledgment, if any, is up to the processes. If the table where the SEND and RECEIVE are matched up ever overflows, a process originating a further SEND or RECEIVE is notified just as if the SEND or RECEIVE timed out.
RECEIVE ANY、決して取り戻すかもしれない以外の回のアウトでない。 適切な受信機が存在していないと、SEND FROM ANYメッセージは、すぐに、いつも送られて、捨てられるでしょう。 エラーメッセージは返されません、そして、もしあれば承認はプロセス次第です。 SENDとRECEIVEが今までに合っているテーブルがあふれるなら、まるでまさしくSENDかRECEIVEが外で調節するかのように一層のSENDかRECEIVEを溯源するプロセスは通知されます。
Generally, well known, permanently assigned ports are used via RECEIVE ANY and SEND FROM ANY. The permanent ports will most often be used for starting processes going and consequently little data will be sent via them.
一般に、よく知られていて、永久に割り当てられたポートはRECEIVE ANYとSEND FROM ANYを通して使用されます。 プロセスが行き始めるために永久的なポートをたいてい使用するでしょう、そして、その結果、それらを通して小さいデータを送るでしょう。
Walden [Page 6] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[6ページ]RFC61プロセス間通信
Still another example, this time a demonstration of the use of the FORTRAN compiler. We have already explained how a user sits down at his teletype and gets connected to an executive. We go on from there. The user is typing in and out of the executive which is doing SENDs and RECEIVEs. Eventually the user types RUN FORTRAN and the executive asks the monitor to start up a copy of the FORTRAN compiler and passes to FORTRAN as start up parameters the two ports the executive was using to talk to the teletype. FORTRAN is of course expecting these parameters and does SENDs and RECEIVEs to these ports to discover what input and output files the user wants to use. FORTRAN types INPUT FILE? to the user who responds F001. FORTRAN then sends a message to the file-system-process which is asleep waiting for something to do. The message is sent via well-known ports and it asks the file system to open F001 for input. The message also contains a pair of ports that the file-system-process can use to send its reply. The file-system looks up F001, opens it for input, makes some entries in its open file tables, and sends a message back to FORTRAN which contains the ports which FORTRAN can use to read the file. The same procedure is followed for the output file. When the compilation is complete, FORTRAN returns the teletype port numbers back to the executive which has been asleep waiting for a message from FORTRAN, and then FORTRAN halts itself. The file- system-process goes back to sleep when it has nothing else to do.
別の例、FORTRANコンパイラの使用のこの時間aデモンストレーションを静めてください。 私たちは既にユーザがどう彼のテレタイプに座って、幹部社員に接されるかを説明しました。 私たちはそこから先へ進みます。 ユーザは内外でSENDsとRECEIVEsをしている幹部社員にタイプしています。 結局、ユーザはRUN FORTRANをタイプします、そして、幹部社員は始動パラメタとしてのFORTRANへのFORTRANコンパイラとパスのコピーで幹部社員がテレタイプと話すのに使用していた2つのポートを始動するようにモニターに頼みます。 FORTRANは、ユーザがどんな入力と出力ファイルを使用したがっているかを発見するためにもちろんこれらのパラメタを予想していて、これらのポートにSENDsとRECEIVEsをします。 FORTRANはF001を反応させるユーザにINPUT FILEをタイプします。 そして、FORTRANはすることを待ちながら眠っているファイルシステム工程にメッセージを送ります。 ウェルノウンポートでメッセージを送ります、そして、それは入力のために開いているF001にファイルシステムを招きます。 また、メッセージはファイルシステム工程が回答を送るのに使用できる1組のポートを含んでいます。 ファイルシステムは、ファイルを読むためにF001を見上げて、入力のためにそれを開いて、オープン・ファイルテーブルでいくつかのエントリーをして、FORTRANが使用できるポートを含むFORTRANにメッセージを送り返します。 同じ手順は出力ファイルのために従われています。 編集が完全であるときに、FORTRANはFORTRAN、および次に、FORTRAN停止からのメッセージ自体を待ちながら眠っている幹部社員にテレタイプポートナンバーを返して戻します。 それにしない他に何もがないとき、ファイルシステム工程は活動を休止します。
[The reader should have noticed by now that I do not like to think of a new process (consisting of a new conceptual copy of a program) being started up each time another user wishes to use the program. Rather, I like to think of the program as a single process which knows it is being used simultaneously by many other processes and consciously multiplexes among the users or delays service to users until it can get around to them.]
[読者は、今ごろ、私が、別のユーザがプログラムを使用したがっているとその都度立ち上げられているニュープロセス(プログラムの新しい概念的なコピーから成る)を考えるのが好きでないのに気付くべきでした。 むしろ、私は、単一のプロセスとしての彼らのひまができることができるまで意識して同時に、他の多くのプロセスによって使用されていて、ユーザの中で多重送信するか、またはユーザに対するサービスを遅らせるのを知っているプログラムを考えるのが好きです。]
Again, the file-system-process can keep a small collection of port numbers which it uses over and over if it can get file system users to return the port numbers when they are done with them. Of course, when this collection of port numbers has eventually dribbled away, the file system can get some new unique numbers from the monitor.
一方、それらでそれらをするとファイルシステムユーザがそれでポートナンバーを返すことができるなら、ファイルシステム工程はそれが再三使用するポートナンバーのわずかな収集を保管できます。 もちろん、ポートナンバーのこの収集が結局遠くにしたたったとき、ファイルシステムはモニターから数個の新しいユニークな数を得ることができます。
Note that when two processes wish to communicate they set up the connection themselves, and they are free to do it in a mutually convenient manner. For instance, they can exchange port numbers or one process can pick all the port numbers and instruct the other process which to use. Of course, in a particular implementation of a time-sharing system, the builders of the system might choose to restrict the processes' execution of SENDs and RECEIVEs and might forbid arbitrary passing around of port numbers, requiring instead that the monitor be called (or some other special program) to perform these functions.
2つのプロセスが交信したがっているとき、自分たちで接続をセットアップして、互いに便利な方法で自由にそれができることに注意してください。 例えば、彼らは使用にどれを処理できるか交換ポートナンバーか1つのプロセスが、すべてのポートナンバーを選んで、もう片方を命令できる。 もちろん、システムのビルダーは、時分割システムの特定の実装では、プロセスのSENDsとRECEIVEsの実行を制限するのを選んで、ポートナンバーの任意のパスを禁じるかもしれません、代わりにモニターがこれらの機能を実行するために呼ばれるのが(または、ある他の特別なプログラム)必要であることで。
Walden [Page 7] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[7ページ]RFC61プロセス間通信
Flow control is provided in this system by the simple method of never starting a SEND from one process until a RECEIVE is executed by the receiver. Of course, interprocess messages may be sent back and forth suggesting that a process stop sending or that space be allocated, etc.
RECEIVEが受信機によって実行されるまで1つのプロセスからSENDを決して始動しないことという簡単なやり方でこのシステムにフロー制御を提供する、もちろん、プロセス停止送付かそのスペースを割り当てるのなどを示しながら、前後にインタプロセスメッセージを送るかもしれません。
INTERPROCESS COMMUNICATION BETWEEN REMOTE PROCESS
リモートプロセスの間のプロセス間通信
The system described in the previous section easily generalizes to allow interprocess communication between processes at geographically different locations as, for example, within a computer network.
前項で容易に説明されたシステムは、例えばコンピュータネットワークのように地理的に異なった位置のプロセスの間のプロセス間通信を許容するために広められます。
Consider first a simple configuration of processes distributed around the points of a star. At each point of the star there is an autonomous time-sharing system. A rather large, smart computer system, called the Network Controller, exists at the center of the star. No processes can run in this center system, but rather it should be thought of as an extension of the monitor of each time- sharing system in the network.
1番目が星のポイントの周りで分配されたプロセスの簡単な構成であると考えてください。 星の各ポイントに、自動時分割システムがあります。 Network Controllerと呼ばれるかなり大きくて、賢いコンピュータ・システムは星のセンターに存在しています。 どんなプロセスもこのセンターシステムに立候補できませんが、むしろそれはネットワークにおける、それぞれの時間共有システムのモニターの拡大として考えられるべきです。
It should be obvious to the reader that if the Network Controller is able to perform the operations SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE and that if all of the monitors in all of the time- sharing systems in the network do not perform these operations themselves but rather ask the Network Controller to perform these operations for them, then we have solved the problem of interprocess communication between remote processes. We have no further change to make.
現代のすべてでのネットワークでシステムを共有しているモニターが皆、これらの操作自体を実行するのではなく、それらのためにこれらの操作を実行するようにNetwork Controllerにむしろ頼むなら私たちがリモートプロセスの間のプロセス間通信の問題を解決したのは、Network Controllerであるなら操作のSEND、RECEIVE、SEND FROM ANY、RECEIVE ANY、およびUNIQUEを実行できる読者とそれに明白であるべきです。 私たちには、行う変更がこれ以上ありません。
The reason everything continues to work when we postulate the existence of the Network Controller is that the Network Controller can keep track of which RECEIVEs have been executed and which SENDs have been executed and match them up just as the monitor did in the model time-sharing system. A networkwide port numbering scheme is also possible with the Network Controller knowing where (i.e., at which site) a particular port is at a particular time.
すべてが、私たちがNetwork Controllerの存在を仮定するとき、働き続けている理由はちょうどモニターがモデル時分割システムでしたように、Network ControllerがどのRECEIVEsが実行されるか、そして、どのSENDsが実行されたかに関する道を保って、彼らを合わせることができるということです。 また、Network Controllerが、特定の時に、(すなわち、どのサイトの)指定港がどこにあるかを知っていて、networkwideポートナンバリングスキームも可能です。
Next, consider a more complex network in which there is no common center point making it necessary to distribute the functions performed by the Network Controller among the network nodes. In the rest of this section I will show that it is possible to efficiently and conveniently distribute the functions performed by the star Network Controller among the many network sites and still enable general interprocess communication between remote processes.
次に、ネットワーク・ノードの中にNetwork Controllerによって実行された機能を分配するのを必要にするどんな一般的な天元もないより複雑なネットワークを考えてください。 このセクションの残りでは、私は、効率的に便利にNetwork Controllerスターによって実行された機能を多くのネットワークサイトに分配して、リモートプロセスの間でまだ一般的なプロセス間通信を可能にしているのが可能であることを示すつもりです。
Some changes must be made to each of the four SEND/RECEIVE operations described above to adapt them for use in a distributed network. To RECEIVE is added a parameter specifying a site to which the RECEIVE
分配されたネットワークにおける使用のためにそれらを適合させるのをいくつかの変更を上で説明されたそれぞれの4つのSEND/RECEIVE操作にしなければなりません。 RECEIVEには、サイトを指定する付記されたaパラメタがある、どれ、RECEIVE
Walden [Page 8] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[8ページ]RFC61プロセス間通信
is to be sent. To SEND FROM ANY and SEND is added a site to send the SEND to although this is normally the local site. Both RECEIVE and RECEIVE ANY have added the provision for obtain the source site of any received message. Thus, when a RECEIVE is executed, the RECEIVE is sent to the site specified, possibly a remote site. Concurrently a SEND is sent to the same site, normally the local site of the process executing the SEND. At this site, called the rendezvous site, the RECEIVE is matched with the proper SEND and the message transmission is allowed to take place to the site from whence the RECEIVE came.
送られることになっています。 SEND FROM ANYとSENDには、これが通常ローカル・サイトですが、SENDを送る加えられたaサイトがあります。 RECEIVEとRECEIVE ANYが支給を加えた両方がどんな受信されたメッセージのソースサイトも得ます。 RECEIVEを実行するとき、したがって、指定されたサイト、ことによるとリモートサイトにRECEIVEを送ります。 同時に、同じサイト、通常SENDを実行するプロセスのローカル・サイトにSENDを送ります。 ランデブーサイトと呼ばれるこのサイトでは、RECEIVEは適切なSENDに合わせられています、そして、メッセージ送信は起源からのサイトへのRECEIVEが来た場所を取ることができます。
A RECEIVE ANY never leaves its originating site and therein lies the necessity for SEND FROM ANY. It must be possible to send a message to a RECEIVE ANY port and not have the message blocked waiting for RECEIVE at the sending site. Of course, it would be possible to construct the system so the SEND/RECEIVE rendezvous takes place at the RECEIVE site and eliminate the SEND FROM ANY operation, but in my judgment the ability to block a normal SEND transmission at the source site more than makes up for the added complexity.
RECEIVE ANYは送信側サイトを決して出ません、そして、そこに、SEND FROM ANYの必要があります。 RECEIVE ANYポートにメッセージを送って、RECEIVEを待ちながら送付サイトでメッセージを妨げさせないのは可能であるに違いありません。 もちろん、システムを構成するのが可能であるだろう、ランデブーが取るSEND/RECEIVEは、加えられた複雑さの埋め合わせをするよりRECEIVEサイトで入賞するので、SEND FROM ANY操作、ソースサイトで通常のSENDトランスミッションをさらに妨げるしかし、私の意見では能力を根絶します。
Somewhere at each site a rendezvous table is kept. This table contains an entry for each unmatched SEND or RECEIVE received at that site and also an entry for all RECEIVE ANYs given at that site. A matching SEND/RECEIVE pair is cleared from the table as soon as the match takes place or perhaps when the transmission is complete. As in the similar table kept in the model time-sharing system, SEND and RECEIVE entries are timed out if unmatched for too long and the originator is notified. RECEIVE ANY entries are cleared from the table when a fulfilling message arrives.
各サイトのどこかでは、ランデブーテーブルが保たれます。 このテーブルはそのサイトに受け取られた各優れたSENDかRECEIVEのためのエントリーとそのサイトで与えられているすべてのRECEIVE ANYsのためのエントリーも含んでいます。 マッチが行われるとすぐにか恐らくトランスミッションが完全であるときに、合っているSEND/RECEIVE組はテーブルから追い出されます。 あまりに長い間優れているならモデル時分割システム、SEND、およびRECEIVEエントリーが調節されているコネであることが保たれた同様のテーブルと創始者で通知されるように。 実現しているメッセージが到着すると、RECEIVE ANYエントリーはテーブルからクリアされます。
The final change necessary to distribute the Network Controller functions is to give each site a portion of the unique numbers to distribute via its UNIQUE operation. I'll discuss this topic further below.
Network Controller機能を分配するのに必要な最終的な変化はUNIQUE操作で分配するユニークな数の部分を各サイトに与えることになっています。 私はさらに以下のこの話題について議論するつもりです。
To make it clear to the reader how the distributed Network Controller works, an example follows. The details of what process picks port numbers, etc. are only exemplary and are not a standard specified as part of the system.
分配されたNetwork Controllerがどう働いているかを読者に断言するために、例は従います。 どんなプロセスがポートナンバーを選ぶかに関する詳細、などは、模範的であるだけであり、システムの一部として指定された規格ではありません。
Suppose there are two sites in the network: K and L. Process A at site K wishes to communicate with process B at site L. Process B has a RECEIVE ANY pending at port M.
ネットワークには2つのサイトがあると仮定してください: サイトKのAがコミュニケートしたがっているKとL.ProcessはサイトL.でBを処理します。Process Bには、ポートMで未定のRECEIVE ANYがあります。
Walden [Page 9] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[9ページ]RFC61プロセス間通信
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANY
サイトKサイトL________ ________ / \ / \ / \ / \ / \ / \ | プロセスA| | プロセスB| | | | | | | | | \/\/\/\ポートM/\________/ \____^___/ | 何でも受信してください。
Process A, fortunately, knows of the existence of port M at site L and sends messages using the SEND FROM ANY operation from port N to port M. The message contains two port numbers and instructions for process B to SEND messages to process A to port P from port Q. Site K's site number is appended to this message along with the message's SEND port N.
プロセスAは、ポートQ.からのPを移植するためにAを処理するSENDメッセージにサイトLで幸いポートMの存在を知って、プロセスBのために、M. メッセージを移植するのにポートNからSEND FROM ANY操作を使用すると2つのポートナンバーと指示が含んでいるというメッセージを送ります。メッセージのSENDポートNに伴うこのメッセージにSite Kのサイト番号を追加します。
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ port N /--->SEND FROM --->\ port M /
\________/ ANY \________/
サイトKサイトL________ ________ / \ / \ / \ / \ / \ / \ | プロセスA| | プロセスB| | | | | | | | | \/\/\ポートN/--->は発信します。--->\ポートM/\________/はあらゆる\です。________/
to port M, site L
containing K, N, P, & Q
M、K、N、P、およびQを含むサイトLを移植するために
Process A now executes a RECEIVE at port P from port Q. Process A specifies the rendezvous site to be site L.
プロセスAは現在、ポートPでポートQ.からRECEIVEを実行します。Process Aは、サイトLになるようにランデブーサイトを指定します。
Walden [Page 10] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[10ページ]RFC61プロセス間通信
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / RECEIVE ---> u \ /
\________/ MESSAGE s \________/
サイトKサイトL________ R________ /\e/\/\n T/\/\dは\です。| | e bプロセスB| | プロセスA| z l| | | eに対して| \/o\/\ポートP/RECEIVE--->u\/\________/メッセージs\________/
to site L
containing P, Q, & K
P、Q、およびKを含むサイトLに
A RECEIVE message is sent from site K to site L and is entered in the rendezvous table at site L. At some other time, process B executes a SEND to port P from port Q specifying site L as the rendezvous site.
RECEIVEメッセージは、サイトKからサイトLに送られて、いつかサイトL.Atのランデブーテーブルに入力されて、プロセスBは、ランデブーサイトとしてサイトLを指定しながらポートQからのPを移植するためにSENDを実行します。
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / u <--- port Q /
\________/ SEND s \________/
to site L
containing P & Q
サイトKサイトL________ R________ /\e/\/\n T/\/\dは\です。| | e bプロセスB| | プロセスA| z l| | | eに対して| \/o\/\ポートP/u<。--- ポートQ/\________/はs\を送ります。________P&Qを含むサイトLへの/
A rendezvous is made, the rendezvous table entry is cleared, and the transmission to port P at site K takes place. The SEND site number (and conceivably the SEND port number) are appended to the messages of the transmission for the edification of the receiving process.
ランデブーをします、そして、ランデブーテーブルエントリーはクリアされます、そして、サイトKでPを移植するトランスミッションは行われます。 SENDサイト番号(多分、SENDは数を移植する)を受信プロセスの啓発のためのトランスミッションに関するメッセージに追加します。
Walden [Page 11] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[11ページ]RFC61プロセス間通信
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and L
サイトKサイトL________ ________ / \ / \ / \ / \ / \ / \ | プロセスA| | プロセスB| | | | | | | | | \ポートP/\ポートQ/\/<。---- トランスミッション<。---- \ / \________T、サイトK\を移植する/________データとLを含む/
Process B may simultaneously wish to execute a RECEIVE from port N at port M.
プロセスBは同時に、ポートMのポートNからRECEIVEを実行したがっているかもしれません。
Note that there is only one important control message in this system which moves between sites, the type of message that is called a Host/Host protocol message in [3]. This control message is the RECEIVE message. There are two other possible intersite control messages: an error message to the originating site when a RECEIVE or SEND is timed out, and the SEND message in the rare case when the rendezvous site is not the SEND site.
サイト([3]にHost/ホストプロトコルメッセージと呼ばれるメッセージのタイプ)の間で移行するこのシステムには1つの重要なコントロールメッセージしかないことに注意してください。 このコントロールメッセージはRECEIVEメッセージです。 他の2つの可能なintersiteコントロールメッセージがあります: RECEIVEかSENDであるときに、送信側サイトへのエラーメッセージは、調節されたアウトと、ランデブーサイトがSENDサイトでないことのまれなケースの中のSENDメッセージです。
Of course there must also be a standard format for messages between ports. For example, the following:
また、もちろん、ポートの間には、メッセージのための標準書式があるに違いありません。 例えば、以下、:
Walden [Page 12] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[12ページ]RFC61プロセス間通信
+-----------------+ +-----------------+ +-----------------+
| rendezvous site | | destination site| | source site |
+-----------------+ +-----------------+ +-----------------+
| RECEIVE port | | RECEIVE port | | RECEIVE port |
+-----------------+ +-----------------+ +-----------------+
| SEND port | | SEND port | | SEND port |
+-----------------+ +-----------------+ +-----------------+
| | | source port | | |
| | +-----------------+ | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-----------------+ +-----------------+ +-----------------+
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
+-----------------+ +-----------------+ +-----------------+ | ランデブーサイト| | 目的地サイト| | ソースサイト| +-----------------+ +-----------------+ +-----------------+ | RECEIVEポート| | RECEIVEポート| | RECEIVEポート| +-----------------+ +-----------------+ +-----------------+ | SENDポート| | SENDポート| | SENDポート| +-----------------+ +-----------------+ +-----------------+ | | | ソースポート| | | | | +-----------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | データ| | データ| | データ| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-----------------+ +-----------------+ +-----------------伝えられた状態で伝えられた+はRECEIVEプロセスControllerプロセスによるNetworkによるSENDで受信しました。
Note: for a SEND FROM ANY message, the rendezvous site is the destination site.
以下に注意してください。 SEND FROM ANYメッセージに関しては、ランデブーサイトは目的地サイトです。
In the model time-sharing system it was possible to pass a port from process to process. This is still possible with a distributed Network Controller. [The reader unconvinced of the utility of port passing is directed to read the section on reconnection in [11].]
モデル時分割システムでは、プロセスからプロセスまでポートを通り過ぎるのは可能でした。 これは分配されたNetwork Controllerでまだ可能です。 [ポート通過に関するユーティリティで納得していない読者が[11]の再接続のときにセクションを読むよう指示されます。]
Remember that for a message to be sent from one process to another, a SEND to port M from port N and a RECEIVE at port M from port N must rendezvous, normally at the SEND site. Both processes keep track of where they think the rendezvous site is and supply this site as a parameter of appropriate operations. The RECEIVE process thinks it is the SEND site and the SEND process normally thinks it is the SEND site also. Since once a SEND and a RECEIVE rendezvous, the transmission is sent to the source of the RECEIVE and the entry in the rendezvous table is cleared and must be set up again for each further transmission from N to M, it is easy for a RECEIVE port to be moved. If a process sends both the port numbers and the rendezvous site number to a new process at some other site which executes a RECEIVE using these same old port numbers and rendezvous site specification, the SENDer never knows the RECEIVEr has moved. It is
1つのプロセスから別のものに送られるべきメッセージに関してMをポートNとRECEIVEからポートNからポートMに移植するSENDが集合しなければならないのを覚えていてください、通常SENDサイトで。 両方のプロセスはそれらがランデブーサイトがそうであると考えて、適切な操作のパラメタとしてこのサイトを供給するところで動向をおさえます。 RECEIVEプロセスは、それがSENDサイトであると思います、そして、通常、SENDプロセスはまた、それがSENDサイトであると思います。 かつてのSENDとRECEIVEランデブー、RECEIVEの源にトランスミッションを送って、さらなる各NからMまでのトランスミッションのためにランデブーテーブルのエントリーをクリアされて、再びセットアップしなければならないので、RECEIVEポートが動かされるのは、簡単です。 ポートナンバーとランデブーサイト番号の両方がプロセスでこれらのいつものポートナンバーとランデブーサイト仕様を使用することでRECEIVEを実行するある他のサイトのニュープロセスに行くなら、SENDerは、RECEIVErが移行したのを決して知りません。 それはそうです。
Walden [Page 13] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[13ページ]RFC61プロセス間通信
slightly harder for a SEND port to move. However, if it does, the pair of port numbers that has been being used for a SEND and the original rendezvous site number are passed to the new site. The process at the new SEND site specifies the old rendezvous site with the first SEND from the new site. The RECEIVE process will also still think the rendezvous site is the old site, so the SEND and RECEIVE will meet at the old site. When they meet, the entry in the table at that site is cleared, the rendezvous site number for the SEND message is changed to the site which originated the SEND message and both the SEND and RECEIVE messages are sent to the new SEND site just as if they had been destined for there in the first place. The SEND and RECEIVE then meet again at the new rendezvous site and transmission may continue as if the port had never moved. Since all transmissions contain the source site number, further RECEIVEs will be sent to the new rendezvous site. It is possible to discover that this special manipulation must take place because a SEND message is received at a site which did not originate the SEND message. Everything is so easily changed because there are no permanent connections to break and move as in the once proposed reconnection scheme for the ARPA network [10][11] that is, connections only exist fleetingly in the system described here and can therefore be remade between any pair of processes which at any time happen to know each other's port numbers and have some clue where they each are.
SENDポートはわずかに動きにくいです。 しかしながら、そうするなら、SENDに使用されているポートナンバーの組と元のランデブーサイト番号は新しいサイトに向かいます。 新しいSENDサイトのプロセスは最初のSENDと共に新しいサイトから古いランデブーサイトを指定します。 また、それでも、RECEIVEプロセスが、ランデブーサイトが古いサイトであると思うので、SENDとRECEIVEは古いサイトで会うでしょう。 彼らが会うと、そのサイトのテーブルのエントリーをクリアします、そして、SENDメッセージのランデブーサイト番号はSENDメッセージを溯源したサイトに変わります、そして、まるでまさしくそれらが第一にそこに運命づけられたかのようにSENDとRECEIVEメッセージの両方を新しいSENDサイトに送ります。 次に、SENDとRECEIVEは再び新しいランデブーサイトで会います、そして、まるでポートが一度も移行したことがなかったかのようにトランスミッションは続くかもしれません。 すべてのトランスミッションがソースサイト番号を含んでいるので、新しいランデブーサイトに一層のRECEIVEsを送るでしょう。 この特別な操作がSENDメッセージを溯源しなかったサイトにSENDメッセージを受け取るので行われなければならないと発見するのは可能です。 ARPAネットワークの一度提案された再接続体系のように調教して、動かす永久接続が全くいないので、すべてが[10] [11] すなわち、接続だけはここで説明されたシステムにはかなく存在していて、したがって、互いのポートナンバーを知って、いつでもたまたま、それぞれそれらがどこにあるかという何らかの手がかりを持っているどんな組のプロセスの間でも作り変えることができるように容易にあまりに変えられます。
Of course, all of this could have been done by the processes sending messages back and forth announcing any potential moves and the new site numbers.
もちろん、メッセージを前後に送るプロセスは、どんな潜在的移動と新しいサイト番号も発表しながら、このすべてをしたかもしれません。
Walden [Page 14] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[14ページ]RFC61プロセス間通信
REFERENCES
参照
[1] L. Roberts and B. Wessler, Computer Network Development to
achieve Resource Sharing, Proceedings 1970 SJCC.
[1] Resource Sharing、Proceedings1970SJCCを達成するL.ロバーツとB.Wessler、コンピュータNetwork Development。
[2] V. Vyssotsky, F. F. Corbato, and R. Graham, Structure of the
MULTICS Supervisor, Proceedings 1965 FJCC.
[2] V.Vyssotsky、F.F.CorbatoとR.グラハム、MULTICS監督の構造、議事、1965FJCC。
[3] C. Carr, S. Crocker, and V. Cerf, Host/Host Communication
Protocol in the ARPA Network, Proceedings 1970 SJCC.
[3] C.カー、S.クロッカー、およびV.サーフは、アーパネットの通信プロトコルをホスティングするか、またはホスティングして、議事は1970SJCCです。
[4] F. Heart, et al, The Interface Message Processor for the ARPA
Computer Network, Proceedings 1970 SJCC.
[4] F.心臓、他、ARPAコンピュータNetwork、Proceedings1970SJCCのためのInterface Message Processor。
[5] W. Ackerman and W. Plummer, An Implementation of Multi-
processing Computer System, Proceedings Gatlinburg Symposium on
Operating System Principles.
[5] Multi処理コンピュータSystem、Operating SystemプリンシプルズのProceedings Gatlinburg SymposiumのW.アッカーマンとW.プラマー、An Implementation。
[6] J. Dennis and E. Van Horn, Programming Semantics for
Multiprogramming Computation, Proceedings of the San Dimes
Conference on Programming Language and Pragmatics.
[6] 多重プログラミング計算、プログラミング言語とプラグマティックスにおけるサン10セント硬貨コンファレンスの議事のために意味論をプログラムするJ.デニスとE.バン・ホーン。
[7] B. Lampson, Dynamic Protection Structures, Proceedings FJCC
1969.
[7] B.ランプソン、ダイナミックな保護構造、議事FJCC1969。
[8] B. Lampson, An Overview of the CAL Time-Sharing System, Computer
Center, University of Calif., Berkeley.
[8] B.ランプソン、CALタイムシェアリングシステム、コンピュータセンター、カリフォルニア、バークレーの大学の概要。
[9] P. Hansen, The Nucleus of a Multiprogramming System, CACM, April
1970.
[9] P.ハンセン、マルチプログラミングシステム、CACM、1970年4月の核。
[10] S. Crocker, ARPA Network Working Group Note #36.
[10] S.クロッカー、アーパネット作業部会注意#36。
[11] J. Postel and S. Crocker, ARPA Network Working Group Note #48.
[11] J.ポステルとS.クロッカー、アルパは作業部会注意#48をネットワークでつなぎます。
[12] B. Lampson, 940 Lectures.
[12] B.ランプソン、940の講演。
Walden [Page 15] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[15ページ]RFC61プロセス間通信
APPENDIX: AN APPLICATION
付録: アプリケーション
Only one resource sharing computer network currently exists, the aforementioned ARPA network. In this Appendix, I hope to show that the system that was described in this note can be applied to the ARPA network. A significant body of work exists on interprocess communication within the ARPA network. This work comes in several almost distinct pieces: the Host/IMP protocol, IMP/IMP protocol, and the Host/Host protocol. I assume familiarity with this work in the subsequent discussion. [See references [1][3][4][10][11]; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822; and ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59.]
1つのリソース・シェアリングコンピュータネットワークだけが現在存在して、前述のARPAはネットワークです。 このAppendixでは、私は、この注意で説明されたシステムはARPAネットワークに適用できるのを示すことを望んでいます。 仕事の重要なボディーはARPAネットワークの中にプロセス間通信に存在します。 この仕事はいくつかのほとんど異なった断片に入ります: Host/IMPは議定書を作ります、そして、IMP/IMPは議定書を作ります、そして、Host/ホストは議定書を作ります。 私はその後の議論におけるこの仕事への親しみを仮定します。 [参照[1][3][4][10][11](IMP、BBN Report No.1822へのHostのInter-接続のための仕様)とアーパネット作業部会Notes#37、38、39、42、44、46、47、48、49、50、54、55、56、57、56、59を見てください。]
In the ARPA network, the IMP's have sole responsibility for correctly transmitting bits from one site to another. The Hosts have sole responsibility for making interprocess connections. Both the Host and IMP are concerned and take a little responsibility for flow control and message sequencing. Application of the interprocess communication system I have described leads me to different allocation of responsibility. The IMP still continues to correctly move bits from one site to another, but the Network Controller also resides in the IMP, and flow control is completely in the hands of the processes running in the Hosts although perhaps they use mechanisms provided by the IMPs.
ARPAネットワークでは、IMPのものは正しく伝わっているビットへの唯一の責任を1つのサイトから別のサイトまで持っています。 Hostsには、インタプロセス接続を作ることへの唯一の責任があります。 HostとIMPの両方が、フロー制御とメッセージ配列に関係があって、少しの責任を取ります。 私が説明したプロセス間通信システムの応用は私を責任の異なった配分に導きます。 また、Network ControllerはIMPに住んでいます、そして、IMPは、まだ正しく1つのサイトから別のものへビットを移し続けていますが、フロー制御が、彼らが恐らくIMPsによって提供されたメカニズムを使用しますが、Hostsへ駆け込みながら、完全にプロセスの手にあります。
The IMPs provide the SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE operations in slightly altered forms for the Hosts and also maintain the rendezvous tables including moving of SEND ports when necessary.
IMPsはHostsのためのわずかに変えられたフォームでSEND、RECEIVE、SEND FROM ANY、RECEIVE ANY、およびUNIQUEに操作を供給して、また、必要であるときに、SENDポートを移行させるのを含むランデブーテーブルを維持します。
It is perhaps easiest to step through the five operations again.
再び5つの操作で踏むのは恐らく最も簡単です。
SEND. The Host gives the IMP a SEND port number, a RECEIVE port number, the rendezvous site, and a buffer specification=20 (e.g., start and end, beginning and length). The SEND is sent to the rendezvous site, normally the local site. When the matching RECEIVE arrives, the Host is notified of the RECEIVE port of the just arrived receive message. This port number is sufficient to identify the SENDing process although a given time-sharing system may have to keep internal tables mapping this port number into useful internal process identifiers. Simultaneously, the IMP will begin to ask the Host for specific chunks of the data buffer. These chunks will be sent off to the destination as the IMP's RFNM control allows. If a RFNM is not received for too long, implying a message has been lost in the network, the Host is asked for the same chunk of data again [which also allows messages to be completely thrown away by the IMP network
発信してください。 HostはSENDポートナンバー、RECEIVEポートナンバー、ランデブーサイト、およびバッファ仕様=20(例えば、始め、終わり、始め、および長さ)をIMPに与えます。 ランデブーサイト、通常ローカル・サイトにSENDを送ります。 合っているRECEIVEが到着すると、HostによるRECEIVEについて通知されて、ただ到着していることのポートがメッセージを受け取るということです。 このポートナンバーは、与えられた時分割システムが内部のテーブルに役に立つ内部のプロセス識別子にこのポートナンバーを写像させ続けなければならないかもしれませんが、SENDingプロセスを特定するために十分です。 同時に、IMPはデータバッファの特定の塊をHostに求め始めるでしょう。 IMPのRFNMコントロールが許容するようにこれらの塊を目的地に送るでしょう。 メッセージがネットワークで失われたのを含意して、長い間RFNMを受け取り過ぎるというわけではないと、再びデータの同じ塊をHostに求める、[また、どれがIMPネットワークによって完全に捨てられるべきメッセージを許容するか。
Walden [Page 16] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[16ページ]RFC61プロセス間通信
if that should ever be useful], but the Host has the option to abort the transmission at this time. While a transmission is taking place, the Host may ask the IMP to perform other operations including other SENDs. A second SEND over a pair of ports already in the act of transmission is noted and the SEND becomes active as soon as the first transmission is complete. A third identical SEND results in an error message to the Host. If a SEND times out, an error is returned also.
それが役に立つべきである、]、Hostだけには、このときトランスミッションを中止するオプションがあります。 トランスミッションが行われている間、Hostは、他のSENDsを含む他の操作を実行するようにIMPに頼むかもしれません。 既にトランスミッションの行為における、1組のポートにわたる第2のSENDは注意されます、そして、最初のトランスミッションが完全であるとすぐに、SENDはアクティブになります。 第3の同じSENDはHostへのエラーメッセージをもたらします。 また、SEND回のアウトであるなら、誤りは返されます。
RECEIVE. The Host gives the IMP a SEND port, a RECEIVE port, a rendezvous site, and a buffer description. The RECEIVE message is sent to the rendezvous site. When chunks of a transmission arrive for the RECEIVE port they are passed to the Host along with RECEIVE port number (and perhaps the SEND port number), and an indication to the Host where to put the data in its input buffer. When the last of the SEND buffer is passed into the Host, it is marked accordingly and the Host can then detect this. A second RECEIVE over the same port pair is allowed. A third results in an error message to the Host. The mechanism described in this and the previous paragraphs allows a pair of processes to always have both a transmission in progress and the next one pending. Therefore, no efficiency is lost. On the other hand, each transmission must be preceded by a RECEIVE into a specified buffer, thus providing complete flow control. (It is conceivable that the RECEIVE message could allocate a piece of network bandwidth while making its network traverse to the rendezvous site.)
受信してください。 HostはSENDポート、RECEIVEポート、ランデブーサイト、およびバッファ記述をIMPに与えます。 RECEIVEメッセージをランデブーサイトに送ります。 トランスミッションの塊がRECEIVEポートに到着するとき、それらはRECEIVEポートナンバー(そして、恐らくSENDポートナンバー)に伴うHost、およびデータを入れるために、それがバッファを入力したHostへの指示に通過されます。 SENDバッファの最終がHostに通過されるとき、それはそれに従って、マークされます、そして、次に、Hostはこれを検出できます。 同じポート組の上の第2のRECEIVEは許容されています。 3分の1に、Hostへのエラーメッセージをもたらします。 これで説明されたメカニズムと前のパラグラフで、1組のプロセスはいつも進行中のトランスミッションと未定の次のものの両方を持つことができます。 したがって、どんな効率も無くなっていません。 他方では、RECEIVEは指定されたバッファの中に各トランスミッションに先行しなければなりません、その結果、完全なフロー制御を提供します。 (RECEIVEメッセージがネットワーク横断をランデブーサイトにしている間1片のネットワーク回線容量を割り当てるかもしれないのが想像できます。)
RECEIVE ANY. The Host gives the IMP a RECEIVE port and a buffer descriptor. This works the same as RECEIVE but assumes the local site to be the rendezvous site.
何でも受信してください。 HostはRECEIVEポートとバッファ記述子をIMPに与えます。 これは、RECEIVEとして同じように働いていますが、ローカル・サイトがランデブーサイトであると仮定します。
SEND FROM ANY. The Host gives the IMP RECEIVE and SEND ports, the destination site, and a buffer descriptor. The IMP requests and transmits the buffer as fast as possible. A SEND FROM ANY for a non-existent port is discarded at the destination site.
いずれからも、発信してください。 Hostはポート、目的地サイト、およびバッファ記述子をIMP RECEIVEとSENDに与えます。 IMPはできるだけ速くバッファを要求して、伝えます。 実在しないポートへのSEND FROM ANYは目的地サイトで捨てられます。
RFNM's are tied to the transmission of a particular chunk of buffer just as acknowledgments are now tied to packets and they perform the same function. If the Hosts allow the IMPs to reassemble buffers in the Hosts by the IMP telling the Host where it should put a buffer chunk as described above, chunks of a single buffer can be transmitted in parallel and several RFNMs can be outstanding simultaneously. Packet reassembly is still done in the IMPs.
ちょうど、承認が現在、パケットに結ばれて、同じ機能を実行するようにRFNMのものはバッファの特定の塊の送信に結ばれます。 HostsがIMPsにそれが上で説明されるようにバッファ塊をどこに置くべきであるかをHostに言うIMPでHostsのバッファを組み立て直させるなら、ただ一つのバッファの塊を平行に伝えることができます、そして、数個のRFNMsが同時に、傑出している場合があります。 IMPsで再アセンブリにまだパケットをしています。
A final operation must be provided by the IMP -- the UNIQUE operation. There are many ways to maintain unique numbers and three are presented here. The first possibility is for the Hosts to ask the IMPs for the unique numbers originally and then guarantee the
IMPは最終的な操作を提供しなければなりません--UNIQUE操作。 ユニークな数と3がここに提示されると主張する多くの方法があります。 最初の可能性がHostsが元々ユニークな数をIMPsに求めることであり、その時は保証です。
Walden [Page 17] RFC 61 Interprocess Communication in a Computer Network July 1970
コンピュータネットワーク1970年7月のウォルデン[17ページ]RFC61プロセス間通信
integrity of any unique numbers currently owned by local processes and programs using whatever means the Host has at its disposal. In this case the IMPs would provide a method for a unique number to be sent from one host to another and would vouch for the number's identity at the new site.
現在Hostを意味するものなら何でも使用しながら地方のプロセスとプログラムで所有されているどんなユニークな数の保全も自由に攻撃します。 この場合、IMPsはユニークな数が1人のホストから別のものに送られるメソッドを提供して、新しいサイトで数のアイデンティティを保証するでしょう。
The second method is to simply give the unique numbers to the processes that are using them, depending on the non-malicious behavior of the processes to preserve the unique numbers, or if an accident should happen, the two passwords (SEND and RECEIVE ports) that are required to initiate a transmission. If the unique numbers are given out in a non-sequential manner and are reasonably long (say 32 bits) there is little danger.
2番目のメソッドは単にそれらを使用しているプロセスにユニークな数を与えることです、ユニークな数を保存するためにプロセスの非悪意のある態度によるか、または事故が起こるなら、トランスミッションを開始するのに必要である2つのパスワード(SENDとRECEIVEポート)。 ユニークな数が非連続した方法で配られていて、適度に長いなら(32ビットを示してください)、危険がほとんどありません。
In the final method, a user identification is included in the port numbers and the individual time-sharing systems guarantee the integrity of these identification bits. Thus a process, while not able to be sure that the correct port is transmitting to him, can be sure that some port of the correct user is transmitting. This is the so-called virtual net concept suggested by W. Crowther [3].
最終的なメソッドで、ユーザ登録名はポートナンバーに含まれています、そして、個々の時分割システムはこれらの識別ビットの保全を保証します。 したがって、正しいポートが彼に伝わっているのを確信できない間、プロセスは正しいユーザのいくらかのポートが伝わっているのを確信している場合があります。 これはW.クラウザー[3]によって提案されたいわゆる仮想のネットの概念です。
Random Contents. Putting these operations in the IMP requires the Host/Host protocol program to be written only once, rather than many times as is currently being done in the ARPA Network. The IMPs can stop a specific host transmission (by not asking for the next chunk for a while) if that should seem necessary to alleviate congestion problems in the communications subnet. And the IMP might know the approximate time it takes for a RECEIVE to get to a particular other site and warn the Host to wake up a process shortly before it becomes imminent that a message for that process will be arriving.
無作為のコンテンツ。 これらの操作をIMPに入れるのは、アーパネットでしながら、Host/ホストプロトコルプログラムが現在何回もむしろ一度だけそのままで書かれるのを必要とします。 それがコミュニケーションサブネットにおける混雑問題を軽減するのに必要に見えるなら、IMPsは特定のホストトランスミッション(しばらく次の塊を求めないのによる)を止めることができます。 そして、IMPは、わざわざRECEIVEが他の特定のサイトを始めて、それがプロセスで目覚めるようにHostに警告する大体のすぐ差し迫るようになる前にそのプロセスへのメッセージが到着するのを知るかもしれません。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Katsunori Tanaka 4/99 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Katsunori田中4/99によるオンラインRFCアーカイブへの]
Walden [Page 18]
ウォルデン[18ページ]
一覧
スポンサーリンク
