RFC708 日本語訳
0708 Elements of a Distributed Programming System. J.E. White. January 1976. (Format: TXT=57888 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group James E. White Request for Comments: 708 Augmentation Research Center
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708増大リサーチセンター
Elements of a Distributed Programming System
分配されたプログラミング・システムのElements
January 5, 1976
1976年1月5日
James E. White
Augmentation Research Center
ジェームスE.ホワイト増大リサーチセンター
Stanford Research Institute
Menlo Park, California 94025
スタンフォード研究所メンローパーク、カリフォルニア 94025
(415) 326-6200 X2960
(415)326-6200X2960
This paper suggests some extensions to the simple Procedure Call Protocol described in a previous paper (27197). By expanding the procedure call model and standardizing other common forms of inter-process interaction, such extensions would provide the applications programmer with an even more powerful distributed programming system.
この紙は前の論文(27197)で説明された簡単なProcedure Callプロトコルにいくつかの拡大を示します。 手順呼び出しモデルを広げて、他の一般的なフォームの相互プロセス相互作用を標準化することによって、そのような拡大はさらに強力な分配されたプログラミング・システムをアプリケーションプログラマに提供するでしょう。
The work reported here was supported by the Advanced Research Projects Agency of the Department of Defense, and by the Rome Air Development Center of the Air Force.
ここで報告された仕事は国防総省のAdvanced Research Projects Agency、および空軍ローム航空開発センターによってサポートされました。
This paper will be submitted to publication in the Journal of Computer Languages.
コンピュータLanguagesのJournalでの公表にこの論文を提出するでしょう。
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング・システムのElements
INTRODUCTION
序論
In a companion paper [i], the author proposes a simple protocol and software framework that would facilitate the construction of distributed systems within a resource-sharing computer network by enabling distant processes to communicate with one another at the procedure call level. Although of great utility even in its present form, this rudimentary "distributed programming system (DPS)" supports only the most fundamental aspects of remote procedure calling. In particular, it permits the caller to identify the remote procedure to be called, supply the necessary arguments, determine the outcome of the procedure, and recover its results. The present paper extends this simple procedure call model and standardizes other common forms of process interaction to provide a more powerful and comprehensive distributed programming system. The particular extensions proposed in this paper serve hopefully to reveal the DPS concept's potential, and are offered not as dogma but rather as stimulus for further research.
仲間論文[i]では、作者は遠方のプロセスが手順呼び出しレベルでお互いにコミュニケートするのを可能にすることによって資源分割形計算機ネットワークの中で分散システムの工事を容易にする簡単なプロトコルとソフトウェアフレームワークを提案します。 現行様式さえのすばらしいユーティリティでは、この初歩的な「分配されたプログラミング・システム(DPS)」は、唯一の大部分がリモート手順の呼ぶことの基本的な局面であるとサポートしますが。 特に、それは、訪問者が呼ばれるためにリモート手順を特定して、必要な議論を供給して、手順の結果を決定して、結果を回復することを許可します。 現在の新聞は、より強力で包括的な分配されたプログラミング・システムを提供するためにこの簡単な手順呼び出しモデルを広げていて、他の一般的なフォームのプロセス相互作用を標準化します。 特定の拡大は、この紙のサーブでうまくいけばDPS概念の可能性を明らかにするよう提案して、さらなる調査のためにむしろ教義ではなく、刺激として申し出られます。
The first section of this paper summarizes the basic distributed programming system derived in [1]. The second section describes the general strategy to be followed in extending it. The third and longest section identifies and explores some of the aspects of process interaction that are sufficiently common to warrant standardization, and suggests methods for incorporating them in the DPS model.
この紙の最初のセクションは[1]で引き出された基本的な分配されたプログラミング・システムをまとめます。 第2セクションは、それを広げる際に続かれるように一般的な戦略を説明します。 3番目の、そして、最も長いセクションは、プロセス相互作用の標準化を保証できるくらい一般的な局面のいくつかを特定して、探検して、DPSモデルにそれらを取り入れるためのメソッドを示します。
REVIEWING THE BASIC SYSTEM
基本体系を見直します。
The distributed programming system derived in [1] assumes the existence of and is built upon a network-wide "inter-process communication (IPC)" facility. As depicted in Figure 1, DPS consists of a high-level model of computer processes and a simple, application-independent "procedure call protocol (PCP)" that implements the model by regulating the dialog between two processes interconnected by means of an IPC communication "channel." DPS is implemented by an installation-provided "run-time environment (RTE)," which is link loaded with (or otherwise made available to) each applications program.
[1]で引き出されたシステムをプログラムするのが存在を仮定して、ネットワーク全体の「相互プロセスコミュニケーション(IPC)」施設に建てられる分配。 図1に表現されるように、DPSはコンピュータプロセスのハイレベルのモデルとIPCコミュニケーションによってインタコネクトされた2つのプロセスの間の対話を規制することによってモデルを実装する簡単で、アプリケーションから独立している「手順呼び出しプロトコル(PCP)」「チャンネル」から成ります。 DPSはインストールに提供された「ランタイム環境(RTE)」によって実装されます。(それは、それぞれのアプリケーションプログラムに積んだ(または、別の方法で利用可能に作られています)リンクです)。
-1-
-1-
Network Working Group James E. White Requests for Comments: 708 Elements of a Distributed Programming System Reviewing the Basic System
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 基本体系を見直す分配されたプログラミング・システムのElements
The Model
モデル
The procedure call model (hereafter termed the Model) views a process as a collection of remotely callable subroutines or "procedures." Each procedure is invoked by name, can be supplied a list of arguments, and returns to its caller both a boolean outcome, indicating whether it succeeded or failed, and a list of results. The Model permits the process at either end of the IPC channel to invoke procedures in its neighbor, and further permits a process to accept two or more procedure calls for concurrent execution.
手順呼び出しモデル(今後Modelと呼ばれる)はほんの少し呼ぶことのできるサブルーチンか「手順」の収集としてプロセスを見なします。 各手順は、名前によって呼び出されて、議論のリストを提供できて、それが成功したかどうかを示したか、または失敗された論理演算子結果、結果のリストの両方を訪問者に返します。 Modelは、IPCチャンネルのどちらかの端のプロセスが隣人に手順を呼び出すのを可能にして、プロセスが同時発生の実行のために2つ以上の手順呼び出しを受け入れるのをさらに可能にします。
The arguments and results of procedures are modeled from a small set of primitive "data types," listed below:
手順の議論と結果は以下に記載された小さいセットの原始の「データ型」からモデル化されます:
LIST: A list is an ordered sequence of N data objects called "elements" (here and throughout these descriptions, N is confined to the range [0, 2**15-1]). A LIST may contain other LISTs as elements, and can therefore be employed to construct arbitrarily complex, composite arguments or results.
以下を記載してください。 リストは「要素」と呼ばれるNデータ・オブジェクトの規則正しい系列(こことこれらの記述の間中、Nは範囲[0、2**15-1]に閉じ込められる)です。 LISTは要素として他のLISTsを含むかもしれなくて、したがって、任意に複雑で、合成している議論か結果を構成するのに使うことができます。
CHARSTR: A character string is an ordered sequence of N ASCII characters, and conveniently models a variety of textual entities, from short user names to whole paragraphs of text.
CHARSTR: 文字列は、N ASCII文字の規則正しい系列であり、便利にさまざまな原文の実体をモデル化します、短いユーザ名から全体のパラグラフのテキストまで。
BITSTR: A bit string is an ordered sequence of N bits and, therefore, provides a means for representing arbitrary binary data (for example, the contents of a word of memory).
BITSTR: ストリングは、少し、Nビットの規則正しい系列であり、したがって、任意のバイナリ・データ(例えば、メモリの単語のコンテンツ)を表すための手段を提供します。
INTEGER: An integer is a fixed-point number in the range [-2**31, 2**31-1], and conveniently models various kinds of numerical data, including time intervals, distances, and so on.
整数: 整数は範囲[-2**31、2**31-1]と、便利に時間間隔を含む様々な種類に関する数値データが遠ざけるモデル、などに固定小数点数です。
INDEX: An index is an integer in the range [1, 2**15-1]. As its name and value range suggest, an INDEX can be used to address a particular bit of character within a string, or element within a list. Furthermore, many of the protocol extensions to be proposed in this paper will employ INDEXES as handles for objects within the DPS environment (for example, processes and channels).
以下に索引をつけてください。 インデックスは範囲[1、2**15-1]の整数です。 その名前と値の範囲が示すように、リストの中でストリング、または要素の中でキャラクタの特定のビットを扱うのにINDEXを使用できます。 その上、この紙で提案されるべきプロトコル拡大の多くがオブジェクトのためのハンドルとしてDPS環境(例えば、プロセスとチャンネル)の中でINDEXESを使うでしょう。
BOOLEAN: A boolean represents a single bit of information and has either the value true or false.
論理演算子: 論理演算子で、情報の1ビットを表して、値は本当であるか誤るようになります。
EMPTY: An empty is a valueless place holder within a LIST of parameter list.
空になります: 空であるのは、パラメータ・リストのLISTの中の無価値な場所所有者です。
-2-
-2-
Network Working Group James E. White Requests for Comments: 708 Elements of a Distributed Programming System Reviewing the Basic System
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 基本体系を見直す分配されたプログラミング・システムのElements
The Protocol
プロトコル
The procedure call protocol (hereafter terms the Protocol), which implements the Model, defines a "transmission format" (like those suggested in Appendix A) for each of the seven data types listed above, and requires that parameters be encoded in that format whenever they are transported between processes.
手順呼び出しプロトコル(今後、プロトコルを呼ぶ)は、上にリストアップされたそれぞれに関する7つのデータ型のために、「トランスミッション形式」(それらがAppendix Aに示されたように)を定義して、それらがプロセスの間で輸送されるときはいつも、パラメタがその形式でコード化されるのを必要とします。(それは、Modelを実装します)。
The Protocol also specified the inter-process messages by which remote procedures are invoked. These messages can be described symbolically as follows:
また、プロトコルはリモート手順が呼び出される相互プロセスメッセージを指定しました。 以下の通り象徴的にこれらのメッセージについて説明できます:
message-type=CALL [tid] procedure-name arguments message-type=RETURN tid outcome results
CALL[tid]プロシージャ名議論メッセージメッセージタイプ=タイプはRETURN tid結果結果と等しいです。
The first message invokes the procedure whose NAME is specified using the ARGUMENTS provided. The second is returned in eventual response to the first and reports the OUTCOME and RESULTS of the completed procedure. Whenever OUTCOME indicates that a procedure has failed, the procedure's RESULTS are required to be an error number and diagnostic message, the former to help the invoking program determine what to do next, the latter for possible presentation to the user. The presence of an optional "transaction identifier (TID)" in the CALL message constitutes a request by the caller for an acknowledging RETURN message echoing the identifier.
最初のメッセージはNAMEが提供されたARGUMENTSを使用することで指定される手順を呼び出します。 完成した手順のレポートの1番目、OUTCOME、およびRESULTSへの最後の応答で2番目を返します。 OUTCOMEが、手順が失敗したのを示すときはいつも、プロシージャのRESULTSがエラー番号と診断メッセージであることが必要です、呼び出しプログラムが、次に何をしたらよいかを決定するのを助ける前者、ユーザへの可能なプレゼンテーションのための後者。 CALLメッセージでの任意の「トランザクション識別子(TID)」の存在は訪問者による識別子を反映する承認しているRETURNメッセージに関する要求を構成します。
Although data types and their transmission formats serve primarily as vehicles for representing the arguments and results of remote procedures, they can just as readily and effectively be employed to represent the messages by which those parameters are transmitted. The Protocol, therefore, represents each of the two messages described above as a PCP data object, namely, a LIST whose first element is an INDEX message type. The following concise statement of the Protocol results:
データ型とそれらのトランスミッション形式は主として議論を表すための乗り物とリモート手順の結果として機能しますが、それらのパラメタが伝えられるメッセージを表すのにただ同じくらい容易に同じくらい事実上それらを使うことができます。 したがって、プロトコルは上でPCPデータ・オブジェクトと説明されたそれぞれに関する2つのメッセージを表します、すなわち、最初の要素のLISTはINDEXメッセージタイプです。 プロトコルの以下の簡明な表明は結果として生じます:
LIST (CALL, tid, procedure, arguments)
INDEX=1 [INDEX] CHARSTR LIST
LIST (RETURN, tid, outcome, results)
INDEX=2 INDEX BOOLEAN LIST
LIST(CALL、tid、手順、議論)INDEX=1[INDEX]CHARSTR LIST LIST(RETURN(tid、結果)は結果になる)INDEX=2 INDEX BOOLEAN LIST
Here and in subsequent protocol descriptions, elements enclosed in square brackets are optional (that is, may be EMPTY). The RESULTS of an unsuccessful procedure would be represented as follows:
こことその後のプロトコル記述では、角括弧で同封された要素は任意です(すなわち、EMPTYであるかもしれません)。 失敗の手順のRESULTSは以下の通り表されるでしょう:
LIST (error, diagnostic) INDEX CHARSTR
LIST(誤り、病気の特徴)INDEX CHARSTR
-3-
-3-
Network Working Group James E. White Requests for Comments: 708 Elements of a Distributed Programming System Reviewing the Basic System
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 基本体系を見直す分配されたプログラミング・システムのElements
The Run-Time Environment
ランタイム環境
The run-time environment (hereafter termed the environment) interfaces the applications program to a remote process via an IPC channel. In doing so, it provides the applications program with a collection of "primitives," implemented either as subroutines or system calls, that the applications program can employ to manipulate the remote process to which the channel connects it. The environment implements these primitives by sending and receiving various protocol messages via the channel.
ランタイム環境(今後環境と呼ばれる)はIPCチャンネルでリモートプロセスにアプリケーションプログラムを連結します。 そうする際に、それはアプリケーションプログラムがチャンネルがそれを接続するリモートプロセスを操るのに使うことができるサブルーチンかシステムコールとして実装された「基関数」の収集をアプリケーションプログラムに提供します。 環境は送受信の様々なプロトコルメッセージでチャンネルでこれらの基関数を実装します。
In its present rudimentary form, the Protocol enables the environment to make a single, remote procedure calling primitive like the following available to the applications program:
現在の初歩的なフォームでは、プロトコルは、環境でシングル、リモート手順の呼ぶのがアプリケーションプログラムに利用可能な以下のように原始的になるのを可能にします:
CALLPROCEDURE (procedure, arguments -> outcome, results) CHARSTR LIST BOOLEAN LIST
CALLPROCEDURE(手順(議論->結果)は結果として生じる)CHARSTR LIST BOOLEAN LIST
This primitive invokes the indicated remote PROCEDURE using the ARGUMENTS provided and returns its OUTCOME and RESULTS. While this primitive blocks the invoking applications program until the remote procedure returns, a variant that simply initiates the call and allows the applications program to collect the outcome and results in a second operation can also be provided.
この基関数は、提供されたARGUMENTSを使用することで示されたリモートPROCEDUREを呼び出して、そのOUTCOMEとRESULTSを返します。 これである間、呼び出しアプリケーションがリモート手順までプログラムする原始のブロックは戻ります、また、単に呼び出しを開始して、アプリケーションプログラムが2番目の操作における結果、結果を集めるのを許容する異形は提供できます。
Since the interface between the environment and the applications program is machine- and possibly even language-dependent, environment-provided primitives can only be described in this paper symbolically. Although PCP data types provide a convenient vehicle for describing their arguments and results are therefore used for that purpose above and throughout the paper, such parameters will normally be transmitted between the environment and the applications program in some internal format.
以来、環境とアプリケーションプログラムとのインタフェースはマシンです、そして、この紙で象徴的にことによると言語依存してさえ、環境に提供された基関数について説明できるだけです。 PCPデータ型は彼らの議論について説明するための便利な乗り物を提供します、そして、したがって、結果はそのために紙の上と、そして、紙中で使用されますが、通常、そのようなパラメタは何らかの内部の形式で環境とアプリケーションプログラムの間に伝えられるでしょう。
BOOTSTRAPPING THE NEW PROTOCOL FUNCTIONS
新しいプロトコル機能を独力で進みます。
Since the Protocol already provides a mechanism for invoking arbitrary
remote procedures, the Model extensions to be proposed in this paper
will be implemented whenever possible as procedures, rather than as
additional messages. Unlike applications procedures, these special
"system procedures" will be called and implemented by run-time environments,
rather than by the applications programs they serve. Although inaccessible
to the remote applications program via the normal environment-provided
remote procedure calling primitive, system procedures will enable the
environment to implement and offer new primitives to its applications
program.
-4-
プロトコルが既に任意のリモート手順を呼び出すのにメカニズムを提供するので、手順として可能であるときはいつも、この紙で提案されるべきModel拡張子は実装されるでしょう、むしろ追加メッセージより。 アプリケーション手順と異なって、これらの特別な「システム手順」は、それらが役立つアプリケーションプログラムでというよりむしろランタイム環境によって呼ばれて、実装されるでしょう。 正常な環境に提供されたリモート手順の呼ぶことを通した原始のリモートアプリケーションプログラムに近づきがたいのですが、システム手順は、環境が新しい基関数をアプリケーションプログラムに実装して、提供するのを可能にするでしょう。 -4-
Network Working Group James E. White Requests for Comments: 708 Elements of a Distributed Programming System Bootstrapping the New Protocol Functions
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 新しいプロトコル機能を独力で進む分配されたプログラミング・システムのElements
The calling sequences of many of these new primitives will closely correspond to those of the remote system procedures by which they are implemented. Other primitives will be more complex and require for their implementation calls to several system procedures, possibly in different processes. Besides describing the Protocol additions required by various Model extensions proposed, the author will, throughout this paper, suggest calling sequences for the new primitives that become available to the applications program.
これらの新しい基関数の多くに関する呼出し手順は密接にそれらが実装されるリモートシステム手順のものに対応するでしょう。 他の基関数は、より複雑であり、それらの実装のためにいくつかのシステム手順と、ことによると異なったプロセスで呼び出しを必要とするでしょう。 さらに様々なModel拡張子で必要であるプロトコル追加について説明するのは提案して、作者はこの紙中でアプリケーションプログラムに利用可能になる新しい基関数のための呼出し手順を勧めるでしょう。
-5-
-5-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理はモデルへのいくつかの可能な拡大です。
SOME POSSIBLE EXTENSIONS TO THE MODEL
モデルへのいくつかの可能な拡大
1. Creating Remote Processes
1. リモートプロセスを作成します。
Before a program in one machine can use resources in another, it must either create a new process in the remote machine, or gain access to an existing one. In either case, the local process must establish an IPC channel to a resident dispatching process within the remote system, specify the program to be started or contacted. and identify itself so that its access to the program can be established and billing carried out. After these preliminary steps have been accomplished, the requested process assumes responsibility for the IPC channel and substantive communication begins.
1台のマシンのプログラムが別のものでリソースを使用できる前に、それは、リモートマシンでニュープロセスを作成しなければならないか、または既存のものへのアクセスを得なければなりません。 どちらの場合ではも、地方のプロセスはリモートシステムの中でプロセスを派遣する居住者のIPCチャンネルを確立しなければならなくて、プログラムを指定します。. 始められるか、または連絡されてください、そして、行われて、プログラムへのアクセスが設立されて、請求できるように、それ自体を特定してください。 これらの予備のステップが実行された後に、要求されたプロセスは、IPCチャンネルと実質的なコミュニケーションへの責任が始まると仮定します。
The manner in which the environment carries out the above scenario is largely dictated by the IPC facility upon which the distributed system is based. If the IPC facility itself provides single primitive that accomplishes the entire task, then the environment need only invoke that primitive. If, on the other hand, it only provides a mechanism by which the environment can establish a channel to the remote dispatcher, as is the case within the ARPA computer Network (the ARPANET), then the Protocol itself must contain provisions for naming the program to be run and presenting the required credential.
環境が上のシナリオを行う方法は分散システムが基づいているIPC施設によって主に書き取られます。 IPC施設自体が原始的にシングルを提供するなら、それは全体のタスクを達成して、次に、環境は原始的にそれを呼び出すだけでよいです。 他方では、ARPAコンピュータNetwork(アルパネット)の中でそうであるように環境がチャンネルを確立できるメカニズムをリモート発送者に提供するだけであるなら、プロトコル自体は実行されるためにプログラムを命名して、必要な資格証明書を提示するための条項を含まなければなりません。
Adding to the Protocol the following system procedure enables the local environment to provide the remote dispatcher with the necessary information in this latter case:
以下のシステム手順をプロトコルに追加するのは、地方の環境がこの後者のケースの中の必要事項をリモート発送者に提供するのを可能にします:
INIPROCESS (program, credential) CHARSTR LIST (user, password, account) CHARSTR CHARSTR CHARSTR
INIPROCESS(プログラム、資格証明書)CHARSTR LIST(ユーザ、パスワードは説明される)CHARSTR CHARSTR CHARSTR
Its arguments include the name of the applications PROGRAM to be run; and the USER name, PASSWORD, and ACCOUNT of the local user to whom its use is to be billed.
議論は実行されるために、アプリケーションPROGRAMという名前を含んでいます。 請求される使用がことである地元のユーザのUSER名、PASSWORD、およびACCOUNT。
This new procedure effectively adds to the Model the notion of "creation," and enables the environment to offer the following primitives to its applications program:
この新しい手順は、事実上、「作成」の概念をModelに言い足して、環境が以下の基関数をアプリケーションプログラムに提供するのを可能にします:
CRTPROCESS (computer, program, credential -> ph) CHARSTR CHARSTR (as above) INDEX DELPROCESS (ph) INDEX
CRTPROCESS(コンピュータ、プログラム、資格証明->ph)CHARSTR CHARSTR (as above) INDEX DELPROCESS(ph)INDEX
-6-
-6-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Creating Remote Processes
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル作成にリモートないくつかの可能な拡大が処理する分配されたプログラミング・システムのElements
The first primitive creates a new process or establishes contact with an existing one by first creating a channel to the dispatcher within the indicated COMPUTER and then invoking the remote system procedure INIPROCESS with the specified PROGRAM name and CREDENTIALS as arguments. The primitive returns a "process handle PH" by which the applications program can refer to the newly created process in subsequent dialog with the local environment by the IPC facility, an index into a table within the environment, or anything else the environment's implementor may find convenient.
基関数がa新しく作成する1番目は、処理するか、または最初にによる既存のものが示されたコンピュータの中で発送者のチャンネルを創造して、次に、議論として指定されたPROGRAM名があるリモートシステム手順INIPROCESSとCREDENTIALSを呼び出していて、接触します。 原始のリターンアプリケーションがプログラムを作る「プロセスハンドルPH」はIPC施設のそばの地方の環境、環境の中のテーブルへのインデックス、または環境の作成者が便利であることがわかるかもしれない他の何かでその後の対話で新たに作成されたプロセスを示すことができます。
The second primitive "deletes" the previously created process whose handle PH is specified by simply deleting the IPC channel to the remote process and reclaiming any internal table space that may have been allocated to the process.
プロセスに割り当てられたかもしれない以前に作成されているのがPHがIPCチャンネルを削除しながら単に指定されるハンドルを加工処理する2番目の原始の「削除」のリモートプロセスの、そして、開墾しているいずれも内部のテーブルスペース。
2. Introducing Processes to One Another
2. お互いにプロセスを紹介します。
The simplest distributed systems begin with a single process that creates, via the CRTPROCESS primitive described above, one or more "inferior" processes whose resources it requires. Some or all of these inferiors may in turn require other remote resources and so create interiors of their own. This creative activity can proceed, in principle, to arbitrary depth. The distributed system is thus a tree structure whose nodes are processes and whose branches are IPC channels.
最も簡単な分散システムはCRTPROCESSを通してそれがリソースを必要とする1つ以上の上で説明された原始の「劣る」プロセスを作成する単一のプロセスで始まります。 いくつかかこれらの目下が皆、順番に他の遠隔資源を必要とするので、それら自身の内部を作成するかもしれません。 この創造的活動は原則として任意の深さに続くことができます。 その結果、分散システムはノードがプロセスであり、ブランチがIPCチャンネルである木構造です。
Although a distributed system can include an arbitrarily large number of processes, each process is cognizant of only the process that created it and those it itself creates, that is, its parent and sons. The radius within which a process can access the resources of the tree is thus artificially small. This limited sharing range, which prevents the convenient implementation of many distributed systems, can be overcome by extending the Model to permit an arbitrarily complex network of communication paths to be superimposed upon the process tree.
すなわち、その親と息子、分散システムは任意に多くのプロセスを含むことができますが、各プロセスはそれを作成したプロセスとそれ自体が作成するものだけを認識しています。 その結果、プロセスが木に関するリソースにアクセスできる半径は人工的に小さいです。 通信路の任意に複雑なネットワークがプロセス木で重ねられることを許可するためにModelを広げることによって、この限られた共有範囲(多くの分散システムの便利な実装を防ぐ)に打ち勝つことができます。
One of the many ways by which the Protocol can provide for such communication paths is to permit one process to "introduce" and thereby make known to one another any two processes it itself knows (for example, two of its sons, or its parent and son). Once introduced, the two processes would be able to invoke one another's procedures with the same freedom the introducing process enjoys. They could also introduce one another to other processes, and so create even longer communication paths.
プロトコルがそのような通信路に備えることができる多くの方法の1つは1つのプロセスがそれ自体が知っているどんな2つのプロセス(その息子か、親と例えば、2人の息子)もお互いに「導入し」て、その結果、明らかにすることを許可することです。 一度導入しています、2つのプロセスが導入プロセスが楽しむ同じ自由でお互いの手順を呼び出すことができるでしょう。 彼らは、また、他のプロセスをお互いに紹介するので、さらに長い通信路を作成するかもしれません。
-7-
-7-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Introducing Processes to One Another
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル導入へのいくつかの可能な拡大がお互いに処理する分配されたプログラミング・システムのElements
2.1 Introductions Within a Homogeneous Environment
2.1 均質の環境の中の序論
Provided one remains within a "homogeneous environment" (that is, the domain of a single IPC facility), the introduction of two processes requires little more than the formation of an IPC channel between them. Adding to the Protocol the following system procedures, which manipulate IPC "ports," enables the run-time environment of the process performing the introduction to negotiate such a channel:
1つが「均質の環境」(すなわち、ただ一つのIPC施設のドメイン)に残っているなら、2つのプロセスの導入はただそれらの間のIPCチャンネルの構成を必要とします。 IPC「ポート」を操る以下のシステム手順をプロトコルに追加すると、そのようなチャンネルを交渉するために序論を実行するプロセスのランタイム環境は可能にされます:
ALOPORT (-> ph, COMPUTER, PORT) INDEX CHARSTR any CNNPORT (ph, computer, port) INDEX CHARSTR any DCNPORT (ph) INDEX
ALOPORT(->ph、コンピュータ、PORT)INDEX CHARSTR、どんなCNNPORT(ph、コンピュータ、ポート)INDEX CHARSTR、もどんなDCNPORT(ph)INDEX
The detailed calling sequences for these procedures are dictated by the IPC facility that underlies the distributed system. Those above are therefore only representative of what may be required within any particular network, but are only slightly less complicated than those required, for example, within the ARPANET.
これらの手順のための詳細な呼出し手順は分散システムの基礎となるIPC施設によって書き取られます。 したがって、どんな特定のネットワークの中でも必要であるかもしれないことには代表しか上にいませんが、それらはわずかにだけいます。例えば、それらがアルパネットの中で必要であるほど複雑ではありません。
To create the channel, the introducing process' run-time environment allocates a PORT in each target process via ALOPORT, and then instructs each process via CNNPORT to connect its port to the other's via the IPC facility. The process handle PH returned by ALOPORT serves as a handle both initially for the allocated port, and then later for the process to which the attached channel provides access. To "separate" the two processes, the introducing process' environment need only invoke the DCNPORT procedure in each process, thereby dissolving the channel, releasing the associated ports, and deallocating the process handles.
導入の過程のランタイム環境は、チャンネルを創造するために、ALOPORTを通してそれぞれの目標プロセスにPORTを割り当てて、次に、もう片方のものにポートをつなげるようCNNPORTを通した各プロセスにIPC施設で命令します。 ALOPORTによって返されたプロセスハンドルPHは初めは、割り当てのためにハンドルの両方としてポートで、次に、付属チャンネルがアクセサリーを提供するプロセスにより遅れていた状態で機能します。 2つのプロセスを「切り離す」ためには、導入の過程の環境は各プロセスにDCNPORT手順を呼び出すだけでよいです、その結果、チャンネルを溶かします、関連ポート、およびプロセスが扱う「反-割り当て」をリリースして。
Armed with these three new system procedures, the environment can provide the following new primitives to its applications program:
これらの3つの新しいシステム手順で武装していて、環境は以下の新しい基関数をアプリケーションプログラムに供給できます:
ITDPROCESS (ph1, ph2 -> ph12, PH21, ih) INDEX INDEX INDEX INDEX INDEX SEPPROCESS (ih) INDEX
ITDPROCESS(ph1、ph2->ph12、PH21、ih)INDEX INDEX INDEX INDEX INDEX SEPPROCESS(ih)INDEX
-8-
-8-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Introducing Process to One Another
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル導入へのいくつかの可能な拡大がお互いに処理する分配されたプログラミング・システムのElements
The first primitive introduces the two processes whose handles PH1 and PH2 are specified. Each handle may designate either a son, in which case the handle is one returned by CRTPROCESS; the parent process, for which a special handle (for example, 1) must always be defined; or a previously introduced process, in which case the handle is one obtained in a previous invocation of ITDPROCESS.
最初に原始はハンドルPH1とPH2が指定される2つのプロセスを導入します。 各ハンドルは息子を任命するかもしれなくて、その場合、ハンドルはCRTPROCESSによって返されたものです。 親プロセス(それにおいて特別なハンドル(例えば、1)をいつも定義しなければなりません)。 以前に導入されたプロセスでありその場合、または、ハンドルはITDPROCESSの前の実施で得られたものです。
ITDPROCESS returns handles PH12 and PH21 by which the two processes will know one another, as well as an "introduction handle IH" that the applications program can later employ to separate the two processes via SEPPROCESS. The applications program initiating the introduction assumes responsibility for communicating to each introduced applications program its handle for the other.
ITDPROCESSはSEPPROCESSを通して2つのプロセスがお互いを知っているPH12とPH21をハンドルに返して、アプリケーションプログラムが後で二人を引き離すのに使うことができる「序論ハンドルIH」にプロセスを返します。 序論を開始するアプリケーションプログラムは、もう片方のためにそれぞれの導入されたアプリケーションプログラムに伝えることへの責任がハンドルであると仮定します。
2.2 Introductions Within a Heterogeneous Environment
2.2 異機種混在環境の中の序論
While their interconnection via an IPC channel is sufficient to introduce two processes to one another, in a heterogeneous environment the creation of such a channel is impossible. Suppose, as depicted in Figure 2, that processes P1 and P2 (in computers C1 and C2, respectively) are interconnected within a distributed system by means of a network IPC facility. Assume further that P2 attaches to the system another process P3 in a minicomputer M that although attached to C2 is not formally a part of the network. With this configuration, it is impossible for P2 to introduce processes P1 and P3 to one another by simply establishing an IPC channel between them, since they are not within the domain of a single IPC facility.
IPCチャンネルを通したそれらのインタコネクトは異機種混在環境で2つのプロセスをお互いに紹介するために十分ですが、そのようなチャンネルの作成は不可能です。 それは図2に表現されるようにP1を処理します、そして、思ってください、そして、P2(コンピュータのC1とC2でそれぞれ)はネットワークIPC施設による分散システムの中でインタコネクトされます。 P2がC2に付けられていますが、正式に、aが離れているということでないネットワークのミニコンピュータMに別のプロセスP3をシステムに取り付けるとさらに仮定してください。 この構成では、P2が単にそれらの間のIPCチャンネルを確立することによってプロセスのP1とP3をお互いに紹介するのは、不可能です、ただ一つのIPC施設のドメインの中にそれらがないので。
One way of overcoming this problem is to extend the Model to embrace the notion of a composite or "logical channel" composed of two or more physical (that is, IPC) channels. A message transmitted by process P1 via the logical channel to Pn (n=3 in the example above) would be relayed over successive physical channels by the environments of intermediate processes P2 through Pn-1. Although more expensive than physical channels, since each message must traverse at least two physical channels and be handled by all the environments along the way, logical channels would nevertheless enable processes that could not otherwise do so to access one another's resources. Since the relaying of messages is a responsibility of the environment, the applications program need never be aware of it.
この問題を克服する1つの方法は2個以上の物理的な(すなわち、IPC)チャンネルで構成された合成物か「論理チャネル」の概念を受け入れるためにModelを広げることです。 Pnへの論理チャネルでプロセスP1によって伝えられて、(上記の例のn=3)が連続した物理的なチャンネルの上に中間的環境によってリレーされるだろうというメッセージはPn-1を通してP2を処理します。 物理的なチャンネルより高価ですが、各メッセージを少なくとも2個の物理的なチャンネルを横断して、道に沿ってすべての環境で扱わなければならないので、それにもかかわらず、論理チャネルは、そうでなければそうできなかったプロセスがお互いのリソースにアクセスするのを可能にするでしょう。 メッセージのリレーが環境の責任であるので、アプリケーションプログラムはそれを決して意識していてはいけません。
-9-
-9-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Introducing Processes to One Another
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル導入へのいくつかの可能な拡大がお互いに処理する分配されたプログラミング・システムのElements
As depicted in Figure 3, a logical channel would consist of table entries maintained by the environment of each process P1 through Pn, plus the environment to forward messages that arrive with a "routing code" addressing the local table entry. Each table entry would contain process handles for the two adjacent processes, as well as the routing code recognized by each. To communicate a message to its distant neighbor, the source process (say P1) would transmit it via its IPC channel to P2, with a routing code addressing the appropriate table entry within P2. Upon receipt of the message, P2 would locate its table entry via the routing code, update the message with the routing code recognized by P3, and forward the message to P3. Eventually the message would reach its final destination, Pn.
図3に表現されるように、論理チャネルは「ルーティングコード」が地方のテーブル項目を扱っていて到着するメッセージを転送するためにPn、および環境を通してそれぞれのプロセスP1の環境によって維持されたテーブル項目から成るでしょう。 各テーブル項目は2つの隣接しているプロセスのためのプロセスハンドルを含んでいるでしょう、それぞれによって認識されたルーティングコードと同様に。 冷ややかな隣人にメッセージを伝えるために、ソースプロセス(P1を言う)はP2のIPCチャンネルでそれを伝えるでしょう、ルーティングコードがP2の中で適切なテーブル項目を扱っていて。 メッセージを受け取り次第、P2はルーティングコードでテーブル項目の場所を見つけて、ルーティングコードがP3によって認識されている状態でメッセージをアップデートして、メッセージをP3に転送するでしょう。 Pn、結局、メッセージは最終的な目的地に達するでしょう。
Adding to the Protocol the following system procedures enables the environment to construct a logical channel like that described above:
以下のシステム手順をプロトコルに追加するのは、環境が以下の上で説明されたそのような論理チャネルを構成するのを可能にします。
CRTROUTE (mycode, oldcode -> code, ph)
INDEX [INDEX] INDEX INDEX
DELROUTE (yourcode)
INDEX
CRTROUTE(mycode、oldcode->コード、ph)INDEX[INDEX]INDEX INDEX DELROUTE(yourcode)INDEX
The simplest logical channel (n=3) is created by P2, which invokes CRTROUTE in both P1 and P3, specifying in each case the routing code MYCODE it has assigned to its segment of the logical channel, and receiving in return the routing CODES and process handles PHs assigned by the two processes. OLDCODE is not required in this simple case and is therefore EMPTY.
最も簡単な論理チャネル(n=3)はP2によって作成されます、そして、代わりにルーティングCODESとプロセスを受けると、2つのプロセスによって割り当てられたPHsは扱われます。(その都度それが論理チャネルのセグメントに割り当てたルーティングコードMYCODEを指定して、P2はP1とP3の両方にCRTROUTEを呼び出します)。 OLDCODEはこの簡単な場合で必要でなく、したがって、EMPTYです。
More complicated logical channels (n>3) are required when one or both of the processes to be introduced is already linked, by a logical channel, to the process performing the introduction. In such cases, a portion of the new channel to be constructed must replicate the existing channel, and hence the routing code OLDCODE for the table entry that represents that channel within the target process is specified as an additional argument of the system procedure. The target process must call CRTROUTE recursively in the adjacent process to replicate the rest of the model channel.
より複雑な論理チャネル(n>3)はプロセスの1か両方であるときに、必要であることで、導入するのが既に繋がっています、論理チャネルで、序論を実行するプロセスにことです。 そのような場合、組み立てられるべき新しいチャンネルの一部が既存のチャンネルを模写しなければなりません、そして、したがって、目標プロセスの中でそのチャンネルの代理をするテーブル項目へのルーティングコードOLDCODEはシステム手順の追加議論として指定されます。 目標プロセスは、モデルチャンネルの残りを模写するために隣接しているプロセスに再帰的にCRTROUTEと呼ばなければなりません。
-10-
-10-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Introducing Processes to One Another
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル導入へのいくつかの可能な拡大がお互いに処理する分配されたプログラミング・システムのElements
The process Pi that creates a logical channel assumes responsibility for insuring that it is eventually dismantled. It deletes the logical channel by invoking DELROUTE in Pi-1 and Pi+1, each of which propagates the call toward its end of the channel.
論理チャネルを作成するプロセスPiがそれが結局解体されるのを保障することへの責任を負います。 それは、Pi-1とPi+1にDELROUTEを呼び出すことによって、論理チャネルを削除します。それはそれぞれチャンネルの端に向かって呼び出しを伝播します。
3. Controlling Access to Local Resources
3. ローカル資源へのアクセスを制御します。
The process introduction primitive proposed above effectively permits access to a process to be transmitted from one process to another. Any process P2 that already possesses a handle to a process P1 can obtain a handle for use by a third process P3. Once P1 and P3 have been introduced, P3 can freely call procedures in P1 (and vice versa).
上で有効に提案されたプロセス序論基関数は、あるプロセスから別のプロセスまで伝えられるためにプロセスにアクセスを許可します。 既にプロセスP1としてハンドルを所有しているどんなプロセスP2も第3のプロセスP3による使用のためにハンドルを入手できます。 いったんP1とP3を導入すると、P3は、自由にP1(逆もまた同様である)の手順と呼ぶことができます。
Although a process can, by aborting the ALOPORT system procedure, prevent its introduction to another process and so restrict the set of processes that gain access to it, finer access controls may sometimes be required. A process may, for example, house two separate resources, one of which is to be made available only to its parent (for example), and the other to any process to which the parent introduces it. Before such a strategy can be conveniently implemented, the Model must be extended to permit access controls to be independently applied to individual resources within a single process.
プロセスは、ALOPORTシステム手順を中止することによって別のプロセスに序論を防ぐので、アクセスを得るプロセスのセットをそれに制限する場合がありますが、よりすばらしいアクセス制御が時々必要であるかもしれません。 プロセスは切り離すかもしれなくて、例えば、家twoは親がそれを導入するどんなプロセスにもリソース、およびもう片方を切り離します。その1つは親(例えば)だけに利用可能にされることになっています。 便利にそのような戦略を実装することができる前に、アクセス制御が独自に単一のプロセスの中の個々のリソースに適用されることを許可するためにModelを広げなければなりません。
Although a single procedure can be considered a resource, it is more practical and convenient to conceive of larger, composite resources consisting of a number of related procedures. A simple data base management module containing procedures for creating, deleting, assigning values to, reading, and searching for data objects exemplifies such composite resources. Although each procedure is useless in isolating, the whole family of procedures provides a meaningful service. Such "package" of logically related procedures might thus be the most reasonable object of the finer access controls to be defined.
リソースであるとただ一つの手順を考えることができますが、多くの関連する手順から成るより大きくて、合成しているリソースを想像するのは、より実用的であって、便利です。 簡単なデータベースの管理モジュール、オブジェクトが例示するデータを読んで、検索して、作成しながら手順を含んでいて、削除して、値を割り当てる、そのような合成リソース。 それぞれの手順は隔離で役に立たないのですが、手順の家族全員は重要なサービスを提供します。 その結果、論理的に関連する手順のそのような「パッケージ」は定義されるべきよりすばらしいアクセス制御の最も妥当なオブジェクトであるかもしれません。
Access controls can be applied to packages by requiring that a process first "open" and obtain a handle for a remote package before it may call any of the procedures it contains. When the process attempts to open the package, its right to do so can be verified and the attempt aborted if necessary. Challenging the open attempt would, of course, be less expensive than challenging every procedure call. The opening of a package would also provide a convenient time for package-dependent state information to be initialized.
それが含む手順のどれかを呼ぶかもしれない前に、プロセスが最初にリモートパッケージにハンドルを「開い」て、入手するのを必要とすることによって、アクセス制御をパッケージに適用できます。 プロセスが、パッケージを開けるのを試みると、そうする権利について確かめることができました、そして、必要なら、試みは中止になりました。 開いている試みに挑戦するのはもちろんあらゆる手順呼び出しに挑戦するより高価でないでしょう。 また、パッケージの始まりはパッケージ依存する州の情報が初期化される便利な時間を提供するでしょう。
-11-
-11-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Controlling Access to Local Resources
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル制御へのいくつかの可能な拡大がローカル資源にアクセスする分配されたプログラミング・システムのElements
Adding to the Protocol the following pair of system procedures enables the environment to open and close packages within another process. For efficiency, these procedures manipulate an arbitrary number of packages in a single transaction.
システム手順の以下の組をプロトコルに追加するのは、環境が別のプロセスの中でパッケージを開けて、閉じるのを可能にします。 効率のために、これらの手順は単一取引でパッケージの特殊活字の数字を操ります。
OPNPACKAGE (packages -> pkhs) LISTofCHARSTRs LISTofINDEXs CLSPACKAGE (pkhs) (as above)
OPNPACKAGE(パッケージ->pkhs)LISTofCHARSTRs LISTofINDEXs CLSPACKAGE(pkhs)(as above)
The first procedure opens and returns "package handles PKHS" for the specified PACKAGES; the second closes one or more packages and releases the handles PKHS previously obtained for them.
最初の手順は、指定されたパッケージのために「パッケージハンドルPKHS」を開いて、返します。 秒は1個以上のパッケージとハンドルPKHSが以前に彼らに入手したリリースを終えます。
Besides incorporating these two new system procedures, the Protocol must further require that a package handle accompany the procedure name in every CALL message (an EMPTY handle perhaps designating a system procedure). Note that this requirement has the side effect of making the package the domain within which procedure names must be unique.
これらの2つの新しいシステム手順を取り入れること以外に、プロトコルは、パッケージハンドルがあらゆるCALLメッセージ(恐らくシステム手順を指定するEMPTYハンドル)のプロシージャ名に伴うのをさらに必要としなければなりません。 この要件にはパッケージをプロシージャ名がユニークであるに違いないドメインにする副作用があることに注意してください。
The system procedures described above enable the environment to make available to its applications program, primitives that have calling sequences similar to those of the corresponding system procedures but which accept the process handle of the target process as an additional argument. Their implementation requires only that the environment identify the remote process from its internal tables and invoke OPNPACKAGE or CLSPACKAGE in that process.
上で説明されたシステム手順はアプリケーションプログラムに利用可能にする環境、対応するシステム手順のものと同様の呼出し手順を持っていますが、追加議論として目標プロセスのプロセスハンドルを認める基関数を可能にします。 それらの実装は、環境が内部のテーブルからリモートプロセスを特定して、そのプロセスにOPNPACKAGEかCLSPACKAGEを呼び出すだけであるのを必要とします。
4. Standardizing Access to Global Variables
4. 大域変数へのアクセスを標準化します。
Conventional systems often maintain global "variables" that can be accessed by modules throughout the system. Such variables are typically manipulated using primitives of the form:
従来のシステムはしばしばモジュールでシステム中でアクセスできるグローバルな「変数」を維持します。 そのような変数はフォームに関する基関数を使用することで通常操られます:
(1) Return the current value of V.
(2) Replace the current contents of V with a new value.
(1) V.の現行価値を返してください。(2) Vの現在のコンテンツを新しい値に取り替えてください。
These primitives are either provided as language constructs or implemented by specialized procedures. The former approach encourages uniform treatment of all variables within the system.
これらの基関数を言語構築として提供するか、または専門化している手順で実装します。 前のアプローチはシステムの中のすべての変数の一定の治療法を奨励します。
Those distributed systems that maintain remotely-accessible variables must also select a strategy for implementing the required access primitives. While such primitives can, of course, be implemented as specialized
また、ほんの少しアクセスしやすい変数を維持するそれらの分散システムは必要なアクセスが基関数であると実装するための戦略を選択しなければなりません。 もちろん専門にされるようにそのような基関数を実装することができますが
-12-
-12-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Standardizing Access to Global Variables
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 モデル標準化へのいくつかの可能な拡大が大域変数にアクセスする分配されたプログラミング・システムのElements
applications procedures, adding to the Protocol the following new system procedures insures a uniform run-time access mechanism:
アプリケーション手順であり、以下の新しいシステム手順をプロトコルに追加すると、一定のランタイムアクセス機構は保障されます:
RDVARIABLE (pkh, variable -> value) INDEX CHARSTR any WRVARIABLE (pkh, variable, value) INDEX CHARSTR any
RDVARIABLE(pkh、可変->値)INDEX CHARSTR、どんなWRVARIABLE(pkh、変数、値)INDEX CHARSTR、もいくらか。
These procedures effectively define variables as named data objects modeled from PCP data types, and suggest that they be clustered in packages with related procedures. The system procedures return and specify, respectively, the VALUE of the VARIABLE whose name and package handle PKH are specified.
これらの手順は、事実上、PCPデータ型からモデル化された命名されたデータ・オブジェクトと変数を定義して、それらがパッケージの中に関連する手順でクラスタリングしているのを示します。 システム手順は、戻って、指定して、それぞれ、名前とパッケージがPKHを扱うVARIABLEのVALUEは指定されています。
These new procedures enable the environment to make available its applications program, primitives that have calling sequences similar to those of the corresponding system procedures but which accept the process handle of the target process as an additional argument. These primitives provide a basis upon which a suitably modified compiler can reestablish the compile-time uniformity that characterizes the manipulation of variables in conventional programming environments. Their implementation requires only that the local environment identify the remote process from its internal tables and invoke RDVARIABLE or WRVARIABLE in that process.
これらの新しい手順は、環境でアプリケーションプログラムが利用可能になるのを可能にします、対応するシステム手順のものと同様の呼出し手順を持っていますが、追加議論として目標プロセスのプロセスハンドルを認める基関数。 これらの基関数は適当に変更されたコンパイラが従来のプログラミング環境での変数の操作を特徴付けるコンパイル時の一様性を回復させることができる基礎を提供します。 それらの実装は、地方の環境が内部のテーブルからリモートプロセスを特定して、そのプロセスにRDVARIABLEかWRVARIABLEを呼び出すだけであるのを必要とします。
Most variables will restrict the range of data types and values that may be assigned to them; some may even be read-only. But because they are modeled using PCP data types, their values can, in principle, be arbitrarily complex (for example, a LIST of LISTS) and the programmer may sometimes wish to manipulate only a single element of the variable (or, if the element is itself a LIST, just one of its elements; and so on, to arbitrary depth).
ほとんどの変数がそれらに割り当てられるかもしれないデータ型と値の範囲を制限するでしょう。 何かが書き込み禁止でさえあるかもしれません。 しかし、それらがPCPデータ型を使用することでモデル化されるので、それらの値は原則として任意に複雑である場合があります、そして、(例えば、LISTSのLIST)プログラマは時々変数のただ一つの要素だけを操作したがっているかもしれません(要素がそれ自体でLISTであることのちょうどとても任意の深さにオンな要素の1つ)。
Adding the following argument to their calling sequences extends the system procedures proposed above to optionally manipulate a single element of a variable's composite value:
以下の議論をそれらの呼出し手順に追加すると、手順が上で任意に変数の合成価値のただ一つの要素に操作するよう提案したシステムは拡張しています:
substructure (LISTofINDEXs)
基礎(LISTofINDEXs)
At successive levels of the value's tree structure, the INDEX of the desired element is identified; the resulting list of indices identifies the SUBSTRUCTURE whose value is to be returned or replaced.
連続したレベルの値の木構造では、必要な要素のINDEXは特定されます。 インデックスリストの結果として起こるリストは返すか、または取り替える値がことであるSUBSTRUCTUREを特定します。
-13-
-13-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Routing Parameters Between Procedures
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理は手順の間のモデルルート設定パラメタへのいくつかの可能な拡大です。
5. Routing Parameters Between Procedures
5. 手順の間のルート設定パラメタ
In conventional programming systems, the results of procedures are used in a variety of ways, depending upon the context of the calls made upon them. A result may, for example:
従来のプログラミング・システムでは、手順の結果はさまざまな方法で使用されます、それらでかけられる電話の文脈によって。 結果がそうするかもしれない、例えば:
(1) Provide the basis for a branch decision within the calling program. (2) Become an argument to a subsequent procedure call. (3) Be ignored and thus effectively discarded.
(1) 呼ぶプログラムの中のブランチ決定の基礎を提供してください。 (2) その後の手順呼び出しへの議論になってください。 (3) 無視されて、このようにして事実上捨てられます。
At run-time, the knowledge of a result's intended use usually lies solely within the calling program, which examines the results, passes it to a second procedure, or ignores it as it chooses.
ランタイムのときに、通常、結果の意図している使用に関する知識は唯一呼ぶプログラムに属します。(それは、結果を調べるか、2番目の手順にそれを通過するか、または選ぶようにそれを無視します)。
In a distributed system, the transportation of results from callee to caller, carried out by means of one of more inter-process messages, can be an expensive operation, especially when the results are large. Data movement can be reduced in Cases 2 and 3 above by extending the Model to permit the intended disposition of each procedure result to be made known in advance to the callee's environment. In Case 2, provided both callees reside within the same process, the result can be held at its source and later locally supplied to the next procedure. In Case 3, the result can be discarded at its source (perhaps not even computed), rather than sent and discarded at its destination.
分散システムでは、結果の訪問される人から、より多くの相互プロセスメッセージの1つによって運び出された訪問者までの輸送は高価な操作であるかもしれません、特に結果が大きいときに。 それぞれの手順結果の意図している気質があらかじめ訪問される人の環境に明らかにされることを許可するためにModelを広げるのによる上のCases2と3でデータ運動を抑えることができます。 Case2では、両方の訪問される人が同じプロセスの中にあるなら、ソースにおいて後で局所的に次の手順に供給しているのに結果を保つことができます。 Case3では、目的地で送られて、捨てられるよりソース(恐らく計算さえされない)でむしろ結果を捨てることができます。
5.1 Specifying Parameters Indirectly
5.1 間接的にパラメータを指定すること。
Variables offer potential for the eliminating the inefficiencies involved in Case 2 above by providing a place within the callees' process where results generated by one procedure can be held until required by another. The Protocol can be extended to permit variables to be used in this way by allowing the caller of any procedure to include optional "argument- and result-list mask" like the following as additional parameters of the CALL message:
変数は別のものが必要になるまで1つの手順で生成された結果を保持できる訪問される人のプロセスの中で場所を提供するのによる上のCase2にかかわる非能率を排泄の可能性に提供します。 どんな手順の訪問者もCALLメッセージの以下のように追加している「議論と結果リストマスク」任意のパラメタを入れるのを許容することによって変数がこのように使用されることを許可するためにプロトコルを広げることができます:
parameter list mask [LIST variable, ...)] [CHARSTR]
パラメータ・リストマスク[LIST変数、…][CHARSTR]
A parameter list mask would permit each parameter to be transmitted either directly, via the parameter list, or indirectly via a VARIABLE within the callee's process. Thus each element of the mask specifies how the callee's
パラメータ・リストマスクは、各パラメタが直接かパラメータ・リストの近く、または、間接的に訪問される人のプロセスの中のVARIABLEを通して伝えられるのを可能にするでしょう。 したがって、マスクの各要素がその方法を指定する、訪問される人のもの
-14-
-14-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Routing Parameters Between Procedures
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理は手順の間のモデルルート設定パラメタへのいくつかの可能な拡大です。
environment is to obtain or dispose of the corresponding parameter. To supply the result of one procedure as an argument to another, the caller need only then appropriately set corresponding elements of the result and argument list masks in the first and second calls, respectively. The result list mask should be ignored if the procedure fails, and the error number and diagnostic message returned directly to the caller.
環境は、対応するパラメタを得るか、または処分することです。 次に、議論として1つの手順の結果を別のものに供給するためには、訪問者は1番目に適切に結果とアーギュメントの並びマスクの対応する要素を設定するだけでよいです、そして、秒はそれぞれ呼びます。 直接訪問者に返された手順が失敗するならリストマスクが無視されるべきであるという結果、エラー番号、および診断メッセージ。
5.2 Providing Scratch Variables for Parameter Routing
5.2 かすり傷変数をパラメタルート設定に提供すること。
Although each applications program could provide variables for use as described above, a more economical approach is to extend the Model to permit special "scratch variables," maintained by the environment without assistance from its applications program, to be created and deleted as necessary at run-time. Adding to the Protocol the following pair of system procedures enables the local environment to create and delete such variables in a remote process:
それぞれのアプリケーションプログラムは上で説明されるように変数を使用に提供するかもしれませんが、より経済的なアプローチはランタイムのときに環境によってアプリケーションプログラムから支援なしで維持された特別な「かすり傷変数」が必要に応じて作成されて、削除されることを許可するためにModelを広げることです。 システム手順の以下の組をプロトコルに追加するのは、地方の環境がリモートプロセスでそのような変数を作成して、削除するのを可能にします:
CRTVARIABLE (variable, value) CHARSTR any DELVARIABLE (variable) CHARSTR
CRTVARIABLE(変数、値)CHARSTRはあらゆるDELVARIABLEの(可変)のCHARSTRです。
These procedures create and delete the specified VARIABLE, respectively. CRTVARIABLE also assigns an initial VALUE to the newly-created variable.
これらの手順は、それぞれ指定されたVARIABLEを作成して、削除します。 また、CRTVARIABLEは新たに作成された変数に初期のVALUEを割り当てます。
These new procedures enable the environment to make available to its applications program, primitives that have calling sequences similar to those of the corresponding system procedures but which accept the process handle of the target process as an additional argument. Their implementation required only that the environment identify the remote process from its internal tables and invoke CRTVARIABLE or DELVARIABLE in that process.
これらの新しい手順はアプリケーションプログラムに利用可能にする環境、対応するシステム手順のものと同様の呼出し手順を持っていますが、追加議論として目標プロセスのプロセスハンドルを認める基関数を可能にします。 それらの実装は、環境が内部のテーブルからリモートプロセスを特定して、そのプロセスにCRTVARIABLEかDELVARIABLEを呼び出すだけであるのを必要としました。
5.3 Discarding Results
5.3 捨てる結果
The inefficiencies that result in Case 3 above are conveniently eliminated by allowing the caller to identify via the result list mask (for example, via a zero-length CHARSTR) that a result will be ignored and therefore need not be returned to the caller.
上にCase3の結果を便利にある非能率を、訪問者が、結果リストマスク(例えば無の長さのCHARSTRを通して)を通して結果が無視されるのを特定するのを許容することによって根絶して、したがって、訪問者に返す必要はありません。
-15-
-15-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Supporting a Richer Spectrum of Control Transfers
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理はコントロール転送の、より豊かなスペクトルをサポートするモデルへのいくつかの可能な拡大です。
6. Supporting a Richer Spectrum of Control Transfers
6. コントロール転送の、より豊かなスペクトルをサポートします。
As currently defined by the Model, a procedure call is a simple two-stage dialog in which the caller first describes the operation it wishes performed and the callee, after performing the operation, reports its outcome. Although this simple dialog form is sufficient to conveniently implement a large class of distributed systems, more complex forms are sometimes required. The Model can be extended to admit a variety of more powerful dialog forms, of which the four described below are examples.
現在Modelによって定義されるように、手順呼び出しは訪問者が最初にそれが実行されていることを願っている操作について説明する簡単な2ステージの対話です、そして、操作を実行した後に、訪問される人は結果を報告します。 この簡単な対話フォームは便利に多人数のクラスの分散システムを実装するために十分ですが、より複雑なフォームが時々必要です。 さまざまなより強力な対話フォームを認めるためにModelを広げることができます。(以下で説明されたそれに関する4はフォームのための例です)。
6.1 Transferring Control Between Caller and Callee
6.1 訪問者と訪問される人の間にコントロールを移すこと。
Many conventional programming systems permit caller and callee to exchange control any number of times before the callee returns. Such "coroutine linkages" provide a means, for example, by which the callee can obtain help with a problem that it has encountered or deliver the results of one suboperation and obtain the arguments for the next.
訪問される人が戻る前に多くの従来のプログラミング・システムが、訪問者と訪問される人がいろいろな回コントロールを交換するのを可能にします。 そのような「コルーチンリンケージ」は例えば訪問される人がそれが行きあたった問題で助けを得るか、1つの副操作の結果を提供して、または次のための議論を得ることができる手段を提供します。
Adding to the Protocol the following system procedure, whose invocation relinquishes control of another, previously initiated procedure, enables the environment to effect a coroutine linkage between caller and callee:
プロトコルに加えて、以下のシステム手順(実施は別のもののコントロールを放棄します)(以前に開始している手順)は、環境が訪問者と訪問される人の間のコルーチンリンケージに作用するのを可能にします:
TAKEPROCEDURE (tid, yourtid, parameters) INDEX BOOLEAN LIST
TAKEPROCEDURE(tid、yourtid、パラメタ)INDEX BOOLEAN LIST
Its arguments include the identifier TID of the affected transaction, an indication YOURTID of from whose name space the identifier was assigned (that is, whether the process relinquishing control is the caller or callee), and PARAMETERS provided by the procedure surrendering control. By exploiting an existing provision of the Protocol (that is, by declining acknowledgment of its calls to TAKEPROCEDURE) the invoking environment can effect the control transfer with a single inter-process message.
議論は影響を受けるトランザクションの識別子TIDを含んで、指示は識別子がだれの名前スペースから割り当てられたかに関する(すなわち、コントロールを放棄するプロセスが訪問者か訪問される人であることにかかわらず)YOURTIDです、そして、PARAMETERSはコントロールを明け渡しながら、手順で提供しました。 プロトコル(すなわち、呼び出しの承認をTAKEPROCEDUREに断つのによる)の既存の条項を利用することによって、呼び出し環境はただ一つの相互プロセスメッセージでコントロール転送に作用できます。
The addition of this new procedure to the Protocol enables the environment to provide the following new primitive to its applications program:
プロトコルへのこの新しい手順の追加は、環境が新しい状態で以下を提供するのをアプリケーションプログラムに原始的に可能にします:
LINKPROCEDURE (tid, arguments -> outcome, results) INDEX LIST [BOOLEAN] LIST
LINKPROCEDURE(tid(議論->結果)は結果として生じる)のINDEX LISTの[ブール]のLIST
-16-
-16-
Network Working Group James E. White
Request for Comments: 708 Elements of a Distributed Programming System
Some Possible Extensions to the Model
Supporting a Richer Spectrum of Control Transfers
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理はコントロール転送の、より豊かなスペクトルをサポートするモデルへのいくつかの可能な拡大です。
This primitive assumes that the CALLPROCEDURE primitive is also modified to return the pertinent transaction identifier should the callee initiate a coroutine linkage rather than return. Invocation of LINKPROCEDURE then continues the dialog by supplying ARGUMENTS and returning control to the remote procedure, and then awaiting the next transfer of control and the RESULTS that accompany it. If the remote procedure then returns, rather than initiating another coroutine linkage, the primitive reports its OUTCOME and invalidates the transaction identifier.
この基関数は、訪問される人がリターンよりむしろコルーチンリンケージを起こすならまた基関数が変更されるCALLPROCEDUREが適切なトランザクション識別子を返すと仮定します。 そしてLINKPROCEDUREの実施は、ARGUMENTSと戻っているコントロールをリモート手順に供給して、次に、それに伴うコントロールとRESULTSの次の転送を待つことによって、対話を続けています。 次に、リモート手順が別のコルーチンリンケージを起こすよりむしろ戻るなら、原始は、OUTCOMEを報告して、トランザクション識別子を無効にします。
While this primitive blocks the applications program until the remoter procedure relinquishes control, a variant that simply initiates the coroutine linkage and allows the applications program to collect the outcome and results in a second operation can also be provided.
これである間、よりリモートな手順がそんなに単にコントロール、異形を放棄するまでアプリケーションがプログラムする原始のブロックは、コルーチンリンケージを起こして、アプリケーションプログラムが結果を集めるのを許容します、そして、また、2番目の操作における結果を前提とすることができます。
6.2 Signaling the Caller/Callee
6.2 訪問者/訪問される人に合図すること。
A monolog is often more appropriate than the dialog initiated by a coroutine linkage. The caller or callee might wish, for example, to report an event it has detected or send large parameters piecemeal to minimize buffering requirements. Since no return parameters are required in such cases, the initiating procedure need only "signal" its partner, while retaining control of the call.
モノローグはコルーチンリンケージによって開始された対話よりしばしば適切です。 訪問者か訪問される人が、それが検出したイベントを報告したいか、または例えば、要件をバッファリングしながら、最小にするためにばらばらの大きいパラメタを送りたがっているかもしれません。 リターンパラメタは全くそのような場合必要でないので、開始手順は呼び出しのコントロールを保有している間、パートナーに「合図するだけでよいです」。
Adding to the Protocol the following system procedure extends the Model to support signals and enables the environment to transmit parameters to or from another, previously initiated procedure without relinquishing control of the call:
以下のシステム手順をプロトコルに追加するのは、信号を支えるためにModelを広げていて、環境が呼び出しのコントロールを放棄しないでものか別のものからのパラメタ、以前に開始している手順を伝えるのを有効にします:
SGNLPROCEDURE (tid, yourtid, parameters) INDEX BOOLEAN LIST
SGNLPROCEDURE(tid、yourtid、パラメタ)INDEX BOOLEAN LIST
Like the TAKEPROCEDURE procedure already described, its arguments include the identifier TID of the affected transaction, an indication YOURTID of from whose name space the identifier was assigned, and the PARAMETERS themselves.
既に説明されたTAKEPROCEDURE手順のように議論が影響を受けるトランザクションの識別子TIDを含んで、指示が識別子がだれの名前スペースから割り当てられたかに関するYOURTIDであり、PARAMETERSは自分たちです。
This new procedure enables the environment to make available to its applications program a primitive that has a calling sequence similar to that of the system procedure but which does not require YOURTID as an argument. Its implementation requires only that the environment identify the remote process via its internal tables and invoke SGNLPROCEDURE in that process.
この新しい手順はa原始的にアプリケーションプログラムに利用可能な造への環境を可能にします(システム手順のものと同様の呼出し手順を持っていますが、議論としてYOURTIDを必要としません)。 実装は、環境が内部のテーブルを通してリモートプロセスを特定して、そのプロセスにSGNLPROCEDUREを呼び出すだけであるのを必要とします。
-17-
-17-
Network Working Group James E. White
Request for Comments: 708 Elements of a Distributed Programming System
Some Possible Extensions to the Model
Supporting a Richer Spectrum of Control Transfers
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理はコントロール転送の、より豊かなスペクトルをサポートするモデルへのいくつかの可能な拡大です。
By requesting the acknowledgment of each call to SGNLPROCEDURE and, if necessary, delaying subsequent calls affecting the same transaction until the acknowledgment arrives, the invoking environment effects a crude form of flow control and so prevents the remote process' buffers from being overrun.
それぞれの呼び出しの承認をSGNLPROCEDUREに要求して、必要なら、承認が到着するまで同じトランザクションに影響するその後の呼び出しを遅らせることによって、呼び出し環境は、粗雑なフォームのフロー制御に作用するので、リモート過程のバッファがオーバランするのを防ぎます。
6.3 Soliciting Help from Superiors
6.3 上司からヘルプに請求すること。
As in conventional programming systems, remotely callable procedures within a distributed system will sometimes call upon others to carry out portions of their task. Each procedure along the "thread of control" resulting from such nested calls is, in a sense, responsible to not only its immediate caller but also to all those procedures that lie above it along the control thread. To properly discharge its responsibilities, a procedure must sometimes communicate with these "superiors."
従来のプログラミング・システムのように、分散システムの中のほんの少し呼ぶことのできる手順は、時々他のものがそれらのタスクの部分を行うのを要求するでしょう。 そのような入れ子にされた呼び出しから生じる「コントロールのスレッド」に沿ったそれぞれの手順は単に即座の訪問者に原因となるのではなく、ある意味でコントロールスレッドに沿ってそれの上にあるそれらのすべての手順にも原因となります。 適切に職責を果たすために、手順は時々これらの「上司」とコミュニケートしなければなりません。
Occasionally a procedure reaches a point in its execution beyond which it cannot proceed without external assistance. It might, for example, require additional resources or further direction from the human user upon whose behalf it is executing. Before reaching this impasse, the procedure may have invested considerable real and/or processing time that will be lost if it aborts.
時折、手順はそれが対外援助なしで続くことができない実行でポイントに達します。 例えば、それは実行している利益として人間のユーザから追加リソースかさらなる方向を必要とするかもしれません。 この行き詰まりに達する前に、手順は中止になるなら失われるかなりの本物、そして/または、処理時間を費やしたかもしれません。
Adding to the Protocol the following system procedure minimizes such inefficiencies by enabling the environment to solicit help from a callee's superiors:
以下のシステム手順をプロトコルに追加すると、環境を可能にするのによるそのような非能率は訪問される人の上司から助けに請求するために最小にされます:
HELPPROCEDURE (tid, number, information -> solution) INDEX INDEX any any
HELPPROCEDURE(tid、数、情報->解決)INDEX INDEX、少しもいくらか。
Its arguments include the identifier TID of the affected transaction (the direction of the control transfer being implicit in this case), a NUMBER identifying the problem encountered, and arbitrary supplementary INFORMATION.
議論は影響を受けるトランザクション(コントロール転送のこの場合暗黙であることの方向)(問題の遭遇していて、任意の補っている情報を特定するNUMBER)の識別子TIDを含んでいます。
The primitive that this new procedure enables the environment to provide its applications program has an identical calling sequence. Its implementation requires only that the environment identify the remote process from its internal tables and invoke HELPPROCEDURE in that process.
この新しい手順が、環境がアプリケーションプログラムを提供するのを可能にする原始は同じ呼出し手順を持っています。 実装は、環境が内部のテーブルからリモートプロセスを特定して、そのプロセスにHELPPROCEDUREを呼び出すだけであるのを必要とします。
The search for help begins with invocation of HELPPROCEDURE in the caller's environment. If the caller understands the problem (that is, recognizes
助けの検索はHELPPROCEDUREの実施で訪問者の環境で始まります。 訪問者は問題を理解しています。(それがそう、認識
-18-
-18-
Network Working Group James E. White
Request for Comments: 708 Elements of a Distributed Programming Model
Supporting a Richer Spectrum of Control Transfers
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 コントロール転送の、より豊かなスペクトルをサポートする分配されたプログラミングモデルのElements
its number) and is able to solve it, HELPPROCEDURE will simply return whatever SOLUTION information the caller provides. Otherwise, HELPPROCEDURE must give the next superior an opportunity to respond by calling itself recursively in that process. The search terminates as soon as a superior responds positively or when the end of the control thread is reached. In the latter case, each of the nested HELPPROCEDURE procedures returns unsuccessfully to indicate to its caller that the search failed.
そして、番号)、訪問者がどういったソリューション情報を提供しても、それを解決できるHELPPROCEDURE意志は単にリターンですか? さもなければ、HELPPROCEDUREはそのプロセスで再帰的に自称することによって応じる機会を次の上司に与えなければなりません。 上司が積極的に対応するとすぐにかコントロールスレッドの端に達しているとき、検索は終わります。 後者の場合では、それぞれの入れ子にされたHELPPROCEDURE手順は戻って、失敗した検索が失敗したのを訪問者に示します。
6.4 Reporting an Event to Superiors
6.4 イベントを上司に報告すること。
A procedure sometimes witnesses or causes an event of which its superiors should be made aware (for example, the start or completion of some major step in the procedure's execution). Adding to the Protocol the following system procedure enables the environment to notify a callee's superiors of an arbitrary event:
手順は、時々上司が意識するようにされるべきであるイベント(例えば、プロシージャの実行における、何らかの主要なステップの始めか完成)を目撃するか、または引き起こします。 以下のシステム手順をプロトコルに追加するのは、環境が訪問される人の任意のイベントの上司に通知するのを可能にします:
NOTEPROCEDURE (tid, number, information) INDEX INDEX any
NOTEPROCEDURE(tid、数、情報)INDEX INDEX、いくらか。
Like HELPPROCEDURE, its arguments include the identifier TID of the transaction it affects, a NUMBER identifying the event being reports, and arbitrary supplementary INFORMATION.
HELPPROCEDUREのように、議論はそれが影響するトランザクション、レポートであるイベントを特定するNUMBER、および任意の補っている情報の識別子TIDを含んでいます。
The primitive that this new procedure enables the environment to provide its applications program has an identical calling sequence. Its implementation requires only that the environment identify the remote process from its internal tables and invoke NOTEPROCEDURE in that process.
この新しい手順が、環境がアプリケーションプログラムを提供するのを可能にする原始は同じ呼出し手順を持っています。 実装は、環境が内部のテーブルからリモートプロセスを特定して、そのプロセスにNOTEPROCEDUREを呼び出すだけであるのを必要とします。
By requesting acknowledgment of each call to NOTEPROCEDURE and, if necessary, delaying subsequent calls that affect that transaction until the acknowledgment arrives, the invoking environment effects a crude form of flow control and so prevents the remote process' buffers from being overrun.
それぞれの呼び出しの承認をNOTEPROCEDUREに要求して、必要なら、承認が到着するまでそのトランザクションに影響するその後の呼び出しを遅らせることによって、呼び出し環境は、粗雑なフォームのフロー制御に作用するので、リモート過程のバッファがオーバランするのを防ぎます。
Notification of the procedure's superiors begins with invocation of NOTEPROCEDURE in the caller's process and works its way recursively up the thread of control until the top is reached.
プロシージャの上司の通知は、訪問者のプロセスでNOTEPROCEDUREの実施で始まって、先端に達するまで、コントロールのスレッドに再帰的に進んでいます。
-19-
-19-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Some Possible Extensions to the Model Aborting Executing Procedures
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 分配されたプログラミング・システムの708の原理は手順を実行するのを中止するモデルへのいくつかの可能な拡大です。
7. Aborting Executing Procedures
7. 手順を実行するのを中止します。
Conventional systems that accept commands from the user sometimes permit him to cancel an executing command issued inadvertently or with erroneous parameters, or one for whose completion he cannot wait. This ability is particularly important when the command (for example, one that compiles a source file) has a significant execution time. In a distributed system, the execution of such a command may involve the invocation of one or more remote procedures. Its cancellation, therefore, requires the abortion of any outstanding remote procedure calls.
ユーザからコマンドを受け入れる従来のシステムは、時々彼がうっかりか誤ったパラメタで発行された実行コマンド、または彼がだれの完成を待つことができないように1つを取り消すかを可能にします。 コマンド(例えば、ソースファイルをコンパイルするもの)が重要な実行時間を過すとき、この能力は特に重要です。 分散システムに、そのようなコマンドの実行は1つ以上のリモート手順の実施にかかわるかもしれません。 したがって、キャンセルはどんな傑出している遠隔手続き呼び出しの妊娠中絶も必要とします。
Adding to the Protocol the following system procedure provides the basis for a command cancellation facility by enabling the environment to abort another, previously invoked procedure:
以下のシステム手順をプロトコルに追加すると、呼び出された手続きは環境が以前に別のものを堕胎するのを可能にするのによるコマンドキャンセル施設の基礎に提供されます:
ABRTPROCEDURE (tid) INDEX
ABRTPROCEDURE(tid)インデックス
Its sole argument is the identified TID of the transaction it affects.
唯一の議論はそれが影響するトランザクションの特定されたTIDです。
The primitive that this new procedure enables the environment to make available to the applications program has an identical calling sequence. Its implementation requires only that the local environment identify the remote process from its internal tables and invoke ABRTPROCEDURE in that process.
この新しい手順が、環境がアプリケーションプログラムに利用可能に作るのを可能にする原始は同じ呼出し手順を持っています。 実装は、地方の環境が内部のテーブルからリモートプロセスを特定して、そのプロセスにABRTPROCEDUREを呼び出すだけであるのを必要とします。
-20-
-20-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Conclusions
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング・システム結論のElements
CONCLUSION
結論
The EXPANDED Protocol and Model that result from the extensions proposed in the present paper are summarized in Appendixes B and C, respectively. Needless to say, many additional forms and aspects of process interaction, of which Appendix D suggests a few, remain to be explored. Nevertheless, the primitives already made available by the run-time environment provide the applications programmer with a powerful and coherent set of tools for constructing distributed systems.
EXPANDEDプロトコルと拡大からの結果が現在の新聞で提案したModelはAppendixes BとCにそれぞれまとめられます。 言うまでもなく、多くの追加フォームとプロセス相互作用の局面は、探検されるために残っています。(そこでは、Appendix Dはいくつかを勧めます)。 それにもかかわらず、ランタイム環境によって既に利用可能にされた基関数は、分散システムを構成するために強力で一貫性を持っているセットのツールをアプリケーションプログラマに提供します。
-21-
-21-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Acknowledgments
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミングシステム承認のElements
ACKNOWLEDGMENTS
承認
Many individuals within both SRI's Augmentation Research Center (ARC) and the larger ARPANET community have contributed their time and ideas to the development of the Protocol and Model described in this and its companion paper. The contributions of the following individuals are expressly acknowledged: Dick Watson, Jon Postel, Charles Irby, Ken Victor, Dave Maynard, Larry Garlick of ARC; and Bob Thomas and Rick Schantz of Bolt, Beranek and Newman, Inc.
SRIのAugmentation Researchセンター(ARC)と、より大きいアルパネット共同体の両方の中の多くの個人がプロトコル、これで説明されたModel、およびその仲間論文の開発に彼らの時間と考えを寄付しました。 以下の個人の貢献は明白に承諾されます: ディック・ワトソン、ジョン・ポステル、チャールズ・イルビー、ケンビクタ、デーヴ・メイナード、アークのラリー・ガーリック。 そして、ボルト、Beranek、およびニューマンInc.のボブ・トーマスとリックSchantz
ARC has been working toward a high-level framework for network-based distributed systems for a number of years now [2]. The particular Protocol and Model result from research begun by ARC in July of 1974. This research included developing the Model; designing and documenting, and implementing a prototype run-time environment for a particular machine [4, 5], specifically a PDP-10 running the Tenex operating system developed by Bolt, Beranek and Newman, Inc. [6]. Three design iterations were carried out during a 12-month period and the resulting specification implemented for Tenex. The Tenex RTE provides a superset of the capabilities proposed in this paper.
ARCは多年にわたり現在[2]、ネットワークベースの分散システムのためにハイレベルのフレームワークに向かって取り組んでいます。 特定のプロトコルとModelは1974年7月にARCによって始められた研究から生じます。 この研究は、Modelを開発するのを含んでいました。 特定のマシン[4、5]のためにプロトタイプランタイム環境を設計して、記録して、実装して、明確にTenexオペレーティングシステムを動かすPDP-10はBolt、Beranek、およびニューマンInc.[6]で展開しました。 3つのデザイン繰り返しが12カ月の期間とTenexのために履行された結果として起こる仕様の間、行われました。 Tenex RTEはこの紙で提案された能力のスーパーセットを提供します。
The work reported here was supported by the Advanced Research Project Agency of the Department of Defense, and by the Rome Air Development Center of the Air Force.
ここで報告された仕事は国防総省のAdvanced Research Project Agency、および空軍ローム航空開発センターによってサポートされました。
-22-
-22-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Appendix A: Transmission Formats for PCP Data Objects
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング・システム付録A:のElements トランスミッションはPCPのためにデータ・オブジェクトをフォーマットします。
APPENDIX A
付録A
TRANSMISSION FORMATS FOR PCP DATA OBJECTS
トランスミッションはPCPのためにデータ・オブジェクトをフォーマットします。
Data objects must be encoded in a standard transmission format before they can be sent from one process to another via the Protocol. An effective strategy is to define several formats and select the most appropriate one at run-time, adding to the Protocol a mechanism for format negotiation. Format negotiation would be another responsibility of the environment and could thus be made completely invisible to the applications program.
プロトコルで1つのプロセスから別のものにそれらを送ることができる前に、標準のトランスミッション形式でデータ・オブジェクトをコード化しなければなりません。 効果的な戦略は、いくつかの書式を定義して、ランタイムのときに最も適切な1つを選択することです、形式交渉のためにメカニズムをプロトコルに追加して。 形式交渉を環境の別の責任であるだろう、その結果、アプリケーションプログラムに完全に目に見えなくすることができました。
Suggested below are two transmission formats. The first is a 36-bit binary format for use between 36-bit machines, the second an 8-bit binary, "universal" format for use between dissimilar machines. Data objects are fully typed in each format to enable the environment to automatically decode and internalize incoming parameters should it be desired to provide this service to the applications program.
以下に示されているのは、2つのトランスミッション形式です。 1番目は36ビットのマシンの間の使用のための36ビットのバイナリフォーマットであり、秒は8ビットのバイナリーです、異なったマシンの間の使用のための「普遍的な」形式。 アプリケーションプログラムに対するこのサービスを提供することが望まれているなら環境が入って来るパラメタを自動的に解読して、内面化させるのを可能にするために各形式でタイプされて、データ・オブジェクトは完全にそうです。
PCPB36, For Use Between 36-Bit Machines
36ビットのマシンの間の使用のためのPCPB36
Bits 0-13 Unused (zero) Bits 14-17 Data type EMPTY =1 INTEGER=4 LIST=7 BOOLEAN=2 BITSTR =5 INDEX -3 CHARSTR=6 Bits 18-20 Unused (zero) Bits 21-35 Value or length N EMPTY unused (zero) BOOLEAN 14 zero-bits + 1-bit value (TRUE=1/FALSE=0) INDEX unsigned value INTEGER unused (zero) BITSTR unsigned bit count N CHARSTR unsigned character count N LIST unsigned element count N Bits 36- Value EMPTY unused (nonexistent) BOOLEAN unused (nonexistent) INDEX unused (nonexistent) INTEGER two's complement full-word value BITSTR bit string + zero padding to word boundary CHARSTR ASCII string + zero padding to word boundary LIST element data objects
5INDEX-3CHARSTR=6 Bits18-20Unused(ゼロ)ビット21-35 2 1ビット0-13Unused(ゼロ)ビット14-17DataタイプEMPTY=INTEGER=4 LIST=7 BOOLEAN=BITSTR=Valueか未署名の14ゼロ・ビットの未使用(ゼロ)のブール+ 長さのNのEMPTYの1ビットの価値(TRUE=1/FALSE=0)の値のINTEGER(ゼロ)未使用のBITSTR未署名のビットカウントN INDEX CHARSTR未署名です; キャラクタカウントN LISTの未署名の要素カウントN Bits36は語境界LIST要素データ・オブジェクトにそっと歩くCHARSTR ASCIIストリング+ゼロを語境界に水増しするEMPTYの未使用のブール(実在しない)未使用(実在しない)のINDEX未使用(実在しない)のINTEGER2の補数フルワード値のBITSTRビット列+ゼロを評価します。
-23-
-23-
Network Working James E. White Request for Comments: 708 Elements of a Distributed Programming System Appendix A: Transmission Formats for PCP Data Objects
コメントを求める働くジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング・システム付録A:のElements トランスミッションはPCPのためにデータ・オブジェクトをフォーマットします。
PCPB8, For Use Between Dissimilar Machines
異なったマシンの間の使用のためのPCPB8
Byte 0 Data type EMPTY =1 INTEGER=4 LIST=7 BOOLEAN=2 BITSTR =5 INDEX =3 CHARSTR=6 Bytes 1- Value EMPTY unused (nonexistent) BOOLEAN 7 zero-bits + 1-bit value (TRUE=1/FALSE=0 INDEX 2 byte unsigned value INTEGER 4-type two's complement value BITSTR 2-byte unsigned bit count N + bit string + zero padding to byte boundary CHARSTR 2-byte unsigned character count N + ASCII string LIST 2-byte element count N + element data objects
3 5 2 1バイト0DataタイプEMPTY=INTEGER=4 LIST=7 BOOLEAN=BITSTR=INDEX=CHARSTR=6 Bytes1が7ゼロ・ビットの未使用(実在しない)のブール+ EMPTYの1ビットの値を評価する、(未署名のTRUE=1/FALSE=0 INDEX2のバイトの値のINTEGERの4タイプの2の補数は2バイトの未署名のバイト境界のキャラクタカウントN+ASCIIストリングLISTの2バイトの要素カウントN+要素CHARSTRデータ・オブジェクトにそっと歩くBITSTRの2バイトの未署名のビットカウントN+ビット列+ゼロを評価します。
-24-
-24-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Appendix B: The Expanded Procedure Call Protocol
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング・システム付録BのElements: 拡張手順呼び出しプロトコル
APPENDIX B
付録B
THE EXPANDED PROCEDURE CALL PROTOCOL
拡張手順呼び出しプロトコル
The Protocol that results from the extensions proposed in this paper is summarized below. The reader should note the concise syntactic description made possible by the underlying notion of PCP data types.
拡大からの結果がこの紙で提案したプロトコルは以下へまとめられます。 読者はPCPデータ型の基本的な概念によって可能にされた簡潔な構文の記述に注意するべきです。
Parameter list masks have been included not only as additional parameters of the CALL message, as proposed in the paper, but as arguments of the TAKEPROCEDURE and SGNLPROCEDURE system procedures as well. Throughout the Protocol description, "MASK" is shorthand for:
パラメータ・リストマスクは単にCALLメッセージのどんな追加パラメタとしても含まれていません、紙で提案されますが、また、TAKEPROCEDUREとSGNLPROCEDUREシステム手順の議論として提案されるように。 プロトコル記述の間中、「マスク」は以下のための速記です。
[LIST (variable [CHARSTR], ...)]
[リスト(変数[CHARSTR]、…)]
Messages
メッセージ
LIST (route INDEX, opcode INDEX CALL=1, tid [INDEX], pkh [INDEX], procedure CHARSTR, arguments LIST, argumentlistmask MASK, resultlistmask MASK) LIST (route INDEX, opcode INDEX RETURN=2, tid INDEX, outcome BOOLEAN, results LIST)
LIST(ルートINDEX、opcode INDEX CALL=1、tid[INDEX]、pkh[INDEX]、手順CHARSTR、議論LIST、argumentlistmask MASK、resultlistmask MASK)LIST(ルートINDEX、opcode INDEX RETURN=2、tid INDEX、ブール結果結果LIST)
If OUTCOME is FALSE RESULTS is LIST (error INDEX, diagnostic CHARSTR)
OUTCOMEがそうであるなら、FALSE RESULTSはLISTです。(誤りINDEX、診断CHARSTR)
Process-Related System Procedures
プロセス関連のシステム手順
INIPROCESS (program CHARSTR, credentials LIST (error CHARSTR, password CHARSTR, account CHARSTR)) ALOPORT (-> ph INDEX, computer CHARSTR, port) CNNPORT (ph INDEX, computer CHARSTR, port) DCNPORT (ph INDEX) CRTROUTE (mycode INDEX, oldcode [INDEX] -> code INDEX, ph INDEX) DELROUTE (yourcode INDEX)
INIPROCESS(CHARSTRをプログラムしてください、資格証明書LIST(誤りCHARSTR(パスワードCHARSTR)はCHARSTRを説明する))ALOPORT(ph INDEX(コンピュータCHARSTR)が移植する->)CNNPORT(ph INDEX、コンピュータCHARSTR、ポート)DCNPORT(ph INDEX)CRTROUTE(mycode INDEX、oldcode[INDEX]->コードINDEX、ph INDEX)DELROUTE(yourcodeインデックス)
Package-Related System Procedures
パッケージ関連のシステム手順
OPNPACKAGE (packages LISTofCHARSTRs -> pkhs LISTofINDEXs) CLSPACKAGE (pkhs LISTofINDEXs)
OPNPACKAGE(パッケージLISTofCHARSTRs->pkhs LISTofINDEXs)CLSPACKAGE(pkhs LISTofINDEXs)
-25-
-25-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming System Appendix B: The Expanded Procedure Call Protocol
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング・システム付録BのElements: 拡張手順呼び出しプロトコル
Variable-Related System Procedures
変数関連のシステム手順
CRTVARIABLE (variable CHARSTR, value) DELVARIABLE (variable CHARSTR) RDVARIABLE (pkh INDEX, variable CHARSTR, substructure [LISTofINDEXs] -> value)
CRTVARIABLE(可変CHARSTR、値)DELVARIABLE(可変CHARSTR)RDVARIABLE(pkh INDEX、可変CHARSTR、基礎[LISTofINDEXs]->価値)
Procedure-Related System Procedures
手順関連のシステム手順
TAKEPROCEDURE (tid INDEX, yourtid BOOLEAN, parameters LIST, argumentlistmask MASK, resultlistmask MASK) SGNLPROCEDURE (tid INDEX, yourtid BOOLEAN, parameters LIST, parameterlistmask MASK) HELPPROCEDURE (tid INDEX, number INDEX, information -> solution) NOTEPROCEDURE (tid INDEX, number INDEX, information) ABRTPROCEDURE (tid INDEX)
TAKEPROCEDURE(tid INDEX、ブールyourtidパラメタLIST、argumentlistmask MASK、resultlistmask MASK)SGNLPROCEDURE(tid INDEX、ブールyourtidパラメタLIST、parameterlistmask MASK)HELPPROCEDURE(tid INDEX、数のINDEX、情報->解決)NOTEPROCEDURE(tid INDEX、数のINDEX、情報)ABRTPROCEDURE(tidインデックス)
-26-
-26-
Network Working Group James E. White Request for Comments: 708 Elements of a Distributed Programming Appendix C: Summary of RTE Primitives
コメントを求めるワーキンググループジェームスE.ホワイトの要求をネットワークでつないでください: 708 分配されたプログラミング付録CのElements: RTE基関数の概要
APPENDIX C
付録C
SUMMARY OF RTE PRIMITIVES
RTE基関数の概要
The DPS primitives made available to the applications program as a result of the Model extensions proposed in this paper are summarized below. Collectively, they provide the applications programmer with a powerful and coherent set of tools for constructing distributed systems. Some of the primitives (for example, CRTPROCESS and DELPROCESS) are necessary elements for a "network operating system (NOS)," into which DPS may itself one day evolve.
この紙で提案されたModel拡張子の結果、アプリケーションプログラムに利用可能にされたDPS基関数は以下へまとめられます。 彼らは、分散システムを構成するために強力で一貫性を持っているセットのツールをアプリケーションプログラマにまとめて、提供します。基関数(例えば、CRTPROCESSとDELPROCESS)のいくつかが「ネットワークOS(NOS)」のための必要な要素であり、1日自体はどのDPSに発展するかもしれないか。
CRTPROCESS (computer, program, credentials -> PH) DELPROCESS (ph) ITDPROCESS (ph1, ph2 -> ph12, ph21, ih) SEPPROCESS (ih)
CRTPROCESS(コンピュータ、プログラム、資格証明書->PH)DELPROCESS(ph)ITDPROCESS(ph1、ph2->ph12、ph21、ih)SEPPROCESS(ih)
Packages
パッケージ
OPNPACKAGE (ph, packages -> pkhs) CLSPACKAGE (ph, pkhs)
OPNPACKAGE(ph、パッケージ->pkhs)CLSPACKAGE(ph、pkhs)
Variables
変数
CRTVARIABLE (ph, variable, value) DELVARIABLE (ph, variable) RDVARIABLE (ph, pkh, variable, substructure -> value) WRTVARIABLE (ph, pkh, variable, substructure, value)
CRTVARIABLE(ph、変数、値)DELVARIABLE(ph、変数)RDVARIABLE(ph、pkh、可変基礎->価値)WRTVARIABLE(ph、pkh、変数、基礎、値)
Procedures
手順
CALLPROCEDURE (ph, pkh, procedure, arguments, argumentlistmask, resultlistmask, -> outcome, results, tid) LINKPROCEDURE (tid, arguments, argumentlistmask, resultlistmask, -> outcome, results) SGNLPROCEDURE (tid, parameters, parameterlistmask) HELPPROCEDURE (tid, number, information -> solution) NOTEPROCEDURE (tid, number, information) ABRTPROCEDURE (tid)
CALLPROCEDURE(ph、pkh、手順、議論、argumentlistmask、resultlistmask(->結果)は結果として生じます、tid)LINKPROCEDURE(tid、議論、argumentlistmask、resultlistmask(->結果)は結果として生じる)SGNLPROCEDURE(tid、パラメタ、parameterlistmask)HELPPROCEDURE(tid、数、情報->解決)NOTEPROCEDURE(tid、数、情報)ABRTPROCEDURE(tid)
-27-
-27-
Network Working Group Elements of a Distributed Programming System Request for Comments: 708 Appendix D: Additional Areas for Investigation
コメントを求める分配されたプログラミング・システム要求のワーキンググループのElementsをネットワークでつないでください: 708 付録D: 調査のための追加領域
APPENDIX D
付録D
ADDITIONAL AREAS FOR INVESTIGATION
調査のための追加領域
Although the expanded distributed programming system developed in this paper and summarized in the previous appendix is already very powerful, many additional aspects of process interaction remain, of course, to be explored. Among the additional facilities that the Protocol must eventually enable the environment to provide are mechanisms for:
この紙で開発されて、前の付録にまとめられた拡張分配されたプログラミング・システムは既に非常に強力ですが、プロセス相互作用の多くの追加局面が、探検されるためにもちろん残っています。 追加の中では、プロトコルが、結局環境が提供するのを可能にしなければならない施設は以下のためのメカニズムです。
(1) Queuing procedure calls for long periods of time (for example, days).
(1) 手順を列に並ばせると、長期間(例えば、何日も)は求められます。
(2) Broadcasting requests to groups of processes.
(2) プロセスのグループに要求を放送すること。
(3) Subcontracting work to other processes (without remaining a middleman).
(3) 他のプロセス(仲買人のままで残っていることのない)に仕事を下請けすること。
(4) Supporting brief or infrequent inter-process exchanges with minimal startup overhead.
(4) 最小量の始動オーバーヘッドで簡潔であるか珍しい相互プロセス交換をサポートすること。
(5) Recovering from and restarting after system errors.
(5) システム・エラーの後に回復して、再開すること。
-28-
-28-
Network Working Group Elements of a Distributed Programming System Request for Comments: 708 References
コメントを求める分配されたプログラミング・システム要求のワーキンググループのElementsをネットワークでつないでください: 708の参照箇所
REFERENCES
参照
1. White, J. E., "A High-Level Framework for Network-Based Resource Sharing,"
submitted for publication in the AFIPS Conference Proceedings of the 1976
National Computer Conference.
1. ホワイト、「ネットワークベースのリソース・シェアリングのためのハイレベルのフレームワーク」というJ.E.は1976年のNationalコンピュータコンファレンスのAFIPSコンファレンスProceedingsでの公表のために提出されました。
2. Watson, R. W., Some Thoughts on System Design to Facilitate Resource
Sharing, ARPA Network Working Group Request for Comments 592, Augmentation
Research Center, Stanford Research Institute, Menlo Park, California,
November 20, 1973 (SRI-ARC Catalog Item 20391).
2. ワトソン、R.W.、リソース・シェアリング、アーパネット作業部会を容易にするシステム設計に関するいくつかの考えが1973年11月20日(様アークカタログ項目20391)をコメント592、増大リサーチセンター、スタンフォード研究所、メンローパーク、カリフォルニアに要求します。
3. White, J. E., DPS-10 Version 2.5 Implementor's Guide, Augmentation
Research Center, Stanford Research Institute, Menlo Park, California,
August 15, 1975 (SRI-ARC Catalog Item 26282).
3. ホワイト、J.E.、2.5作成者のガイド、増大リサーチセンター、スタンフォード研究所、メンローパーク、1975年8月15日の毎秒壊変数-10Versionカリフォルニア(様アークカタログ項目26282)。
4. White, J. E., DPS-10 Version 2.5 Programmer's Guide, Augmentation Research
Center, Stanford Research Institute, Menlo Park, California, August 13,
1975 (SRI-ARC Catalog Item 26271).
4. ホワイト、J.E.、毎秒壊変数-10バージョン2.5プログラマーズガイド、増大リサーチセンター、スタンフォード研究所、メンローパーク、1975年8月13日のカリフォルニア(様アークカタログ項目26271)。
5. White, J. E., DPS-10 Version 2.5 Source Code, Augmentation Research
Center, Stanford Research Institute, Menlo Park, California, August 13,
1975 (SRI-ARC Catalog Item 26267).
5. ホワイト、J.E.、毎秒壊変数-10バージョン2.5ソースコード、増大リサーチセンター、スタンフォード研究所、メンローパーク、1975年8月13日のカリフォルニア(様アークカタログ項目26267)。
6. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R. S., "TENEX,
a paged Time Sharing System for the PDP-10," Communications of the ACM,
Vol. 15, No. 3, pp. 135-143, March 1972.
6. Bobrow、D.G.、Burchfiel、J.D.、マーフィー、D.L.、トムリンスン、R.S.、「TENEX、PDP-10のための呼び出されたタイムシェアリングシステム」Communications、ACM、Vol.15、No.3、ページ 135-143と、1972年3月。
-29-
Network Working Group Elements of a Distributed Programming System
Request for Comments: 708 Figure List
-29 -コメントを求める分配されたプログラミング・システム要求のワーキンググループのElementsをネットワークでつないでください: 708図リスト
FIGURE LIST
図リスト
Fig. 1 Interfacing distant applications programs via their run-time environments and an IPC channel.
図1 彼らのランタイム環境とIPCを通したInterfacingのよそよそしいアプリケーションプログラムは精神を集中します。
Fig. 2 Two processes that can only be introduced via a logical channel.
図2 論理チャネルで導入できるだけであるTwoプロセス。
Fig. 3 A logical channel.
図3 A論理チャネル。
-30-
-30-
一覧
スポンサーリンク
