RFC707 日本語訳
0707 High-level framework for network-based resource sharing. J.E.White. December 1975. (Format: TXT=57254 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263 NCC 76 A High-Level Framework for Network-Based Resource Sharing
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリングのためのハイレベルのフレームワークあたり51 34263NCC76
THE GOAL, RESOURCE SHARING 1
目標、リソース共有1
The principal goal of all resource-sharing computer networks, including the now international ARPA Network (the ARPANET), is to usefully interconnect geographically distributed hardware, software, and human resources [1]. Achieving this goal requires the design and implementation of various levels of support software within each constituent computer, and the specification of network-wide "protocols" (that is, conventions regarding the format and the relative timing of network messages) governing their interaction. This paper outlines an alternative to the approach that ARPANET system builders have been taking since work in this area began in 1970, and suggests a strategy for modeling distributed systems within any large computer network. 1a
現在国際的なアーパネット(アルパネット)を含むすべての資源分割形計算機ネットワークの主な目的は有効に地理的に分配されたハードウェア、ソフトウェア、および人的資源[1]とインタコネクトすることです。 この目標を達成するのはそれぞれの構成しているコンピュータの中の様々なレベルに関する支援ソフトウェアの設計と実装、およびそれらの相互作用を治めるネットワーク全体の「プロトコル」(すなわち、ネットワークメッセージの形式と相対的なタイミングに関するコンベンション)の仕様を必要とします。 この領域での仕事がどんな大きいコンピュータネットワークの中のモデル分散システムのために1970年に始まって、戦略を示すので、この論文はアルパネットシステムビルダーが取っているアプローチへの代替手段を概説します。 1a
The first section of this paper describes the prevailing ARPANET protocol strategy, which involves specifying a family of application-dependent protocols with a network-wide inter-process communication facility as their common foundation. In the second section, the application-independent command/response discipline that characterizes this protocol family is identified and its isolation as a separate protocol proposed. Such isolation would reduce the work of the applications programmer by allowing the software that implements the protocol to be factored out of each applications program and supplied as a single, installation-maintained module. The final section of this paper proposes an extensible model for this class of network interaction that in itself would even further encourage the use of network resources. 1b
この紙の最初のセクションは行き渡っているアルパネットプロトコル戦略を説明します。(それは、それらの一般的な基礎としてネットワーク全体のプロセス間通信機能でアプリケーション依存するプロトコルのファミリーを指定することを伴います)。 第2セクションで、このプロトコルファミリーについて描写するアプリケーションから独立しているコマンド/応答規律は特定されました、そして、別々のプロトコルとしての分離は提案しました。 プロトコルを実装するソフトウェアがそれぞれのアプリケーションプログラムから因数分解されて、単一の、そして、インストールで維持されたモジュールとして提供されるのを許容することによって、そのような分離はアプリケーションプログラマの仕事を抑えるでしょう。 この紙の最後のセクションは本来さらにネットワーク資源の使用を奨励さえするこのクラスのネットワーク相互作用のために広げることができるモデルを提案します。 1b
-1-
-1-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
The Current Software Approach to Resource Sharing
NWG/RFC#707JEW14 1月の76 19: リソース・シェアリングへの現在のソフトウェアアプローチを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
THE CURRENT SOFTWARE APPROACH TO RESOURCE SHARING 2
リソース・シェアリング2への現在のソフトウェアアプローチ
Function-Oriented Protocols 2a
機能指向のプロトコル2a
The current ARPANET software approach to facilitating resource sharing has been detailed elsewhere in the literature [2, 3, 4]. Briefly, it involves defining a Host-Host Protocol by which the operating systems of the various "host" computers cooperate to support a network-wide inter-process communication (IPC) facility, and then various function-oriented protocols by which processes deliver and receive specific services via IPC. Each function-oriented protocol regulates the dialog between a resident "server process" providing the service, and a "user process" seeking the service on behalf of a user (the terms "user" and "user process" will be used consistently throughout this paper to distinguish the human user from the computer process acting on his behalf). 2a1
リソース・シェアリングを容易にすることへの現在のアルパネットソフトウェアアプローチは文学[2、3、4]のほかの場所で詳しく述べられました。 簡潔に、それは、ネットワーク全体の相互プロセスコミュニケーション(IPC)施設をサポートして、次に、プロセスがIPCを通して特定のサービスを提供して、受ける様々な機能指向のプロトコルをサポートするために様々な「ホスト」コンピュータのオペレーティングシステムが協力するHost-ホストプロトコルを定義することを伴います。 それぞれの機能指向のプロトコルはサービスを提供する居住している「サーバプロセス」と、ユーザを代表してサービスを求める「ユーザ・プロセス」の間の対話を規制します(用語「ユーザ」と「ユーザ・プロセス」はコンピュータプロセスと人間のユーザを区別するのに彼の代理に影響しながら、この紙中で一貫して使用されるでしょう)。 2a1
The current Host-Host Protocol has been in service since 1970. Since its initial design and implementation, a variety of deficiencies have been recognized and several alternative protocols suggested [5, 6]. Although improvements at this level would surely have a positive effect upon Network resource sharing, the present paper simply assumes the existence of some form of IPC and focuses attention upon higher level protocol design issues. 2a2
1970年以来現在のHost-ホストプロトコルは使用中です。 初期の設計と実装以来、さまざまな欠乏が認識されていました、そして、いくつかの代替のプロトコルが[5、6]を示しました。 このレベルにおける改良は確実にNetworkリソース・シェアリングに明白な効果を持っているでしょうが、現在の新聞は、単にIPCの何らかのフォームの存在を仮定して、より高い平らなプロトコルデザイン問題に注意の焦点を合わせます。 2a2
Each of the function-oriented protocols mentioned in this paper constitutes the official ARPANET protocol for its respective application domain and is therefore implemented at nearly all of the 75 host installations that now comprise the Network. It is primarily upon this widely implemented protocol family (and the philosophy it represents) that the present paper focuses. Needless to say, other important resource sharing tools have also been constructed within the ARPANET. The Resource Sharing Executive (RSEXEC), designed and implemented by Bolt, Beranek and Newman, Inc [7], provides an excellent example of such work. 2a3
この紙で言及されたそれぞれの機能指向のプロトコルは、公式のアルパネットプロトコルをそれぞれのアプリケーションドメインに構成して、したがって、ほとんど現在Networkを包括する75のホストインストールのすべてで実装されます。 主としてこの広く実装しているプロトコルファミリー(そして、それが表す哲学)に現在の新聞は集中します。 また、言うまでもなく、他の重要なリソース・シェアリングツールはアルパネットの中で構成されました。 Bolt、Beranek、およびニューマンによって設計されて、実装されたResource Sharing Executive(RSEXEC)(Inc[7])はそのような仕事に関する好例を提供します。 2a3
Experience with and Limitations of Hands-On Resource Sharing 2b
実地のリソース・シェアリング2bの経験と限界
The oldest and still by far the most heavily used function-oriented protocol is the Telecommunications Network protocol (TELNET) [8], which effectively attaches a terminal on one computer to an interactive time-sharing system on another, and allows a user to interact with the remote system via the terminal as if he were one of its local users. 2b1
最も古くてまだ最も大いに断然使用された機能指向のプロトコルはTelecommunications Networkプロトコル(TELNET)[8]です。(その[8]は、事実上、別のものに1台のコンピュータで対話的な時分割システムに端末を取り付けて、まるで彼が地元のユーザのひとりであるかのようにユーザが端末を通してリモートシステムと対話するのを許容します)。 2b1
-2-
-2-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
The Current Software Approach to Resource Sharing
NWG/RFC#707JEW14 1月の76 19: リソース・シェアリングへの現在のソフトウェアアプローチを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
As depicted in Figure 1, TELNET specifies the means by which a user process monitoring the user's terminal is interconnected, via an IPC communication channel, with a server process with access to the target time-sharing system. TELNET also legislates a standard character set in which the user's commands and the system's responses are to be represented in transmission between machines. The syntax and semantics of these interchanges, however, vary from one system to another and are unregulated by the protocol; the user and server processes simply shuttle characters between the human user and the target system. 2b2
図1に表現されるように、TELNETはユーザの端末をモニターするユーザ・プロセスがインタコネクトされる手段を指定します、IPC通信チャネルで、目標時分割システムへのアクセスがあるサーバプロセスで。 また、TELNETはマシンの間のトランスミッションで表されるユーザのコマンドとシステムの応答がことである標準文字セットを制定します。 これらの置き換えの構文と意味論は、しかしながら、1台のシステムから別のものに異なって、プロトコルで調節されません。 ユーザとサーバプロセスは人間のユーザと目標システムの間のキャラクタを単に往復させます。 2b2
Although the hands-on use of remote resources that TELNET makes possible is a natural and highly visible form of resource sharing, several limitations severely reduce its long-term utility: 2b3
TELNETが可能にする遠隔資源の実地の使用は自然で非常に目に見えるフォームのリソース・シェアリングですが、いくつかの制限が厳しく長期のユーティリティを減らします: 2b3
(1) It forces upon the user all of the trappings of the
resource's own system.
(1) それはリソースの自身のシステムの衣裳のすべてをユーザに強制します。
To exploit a remote resource, the user must leave the
familiar working environment provided by his local system and
enter an alien one with its own peculiar system structure
(login, logout, and subsystem entry and exit procedures) and
command language discipline (command recognition and
completion conventions, editing characters, and so on).
Hands-on resource sharing thus fails to provide the user with
the kind of organized and consistent workshop he requires to
work effectively [9].
そして、ユーザが遠隔資源を利用するために、身近な作業環境を彼のローカルシステムで提供するままにし、それ自身の独特のシステム構造に従った異質のものに入らなければならない、(ログインしてくださいといって、ログアウトしてください、サブシステムエントリーと出口手順) そして、コマンド言語規律(コマンド認識、完成コンベンション、編集用文字など)。 その結果、実地のリソース・シェアリングは彼が[9]を有効に働かせるのを必要とする組織化されて一貫したワークショップの種類をユーザに提供しません。
(2) It provides no basis for bootstrapping new composite
resources from existing ones.
(2) それは既存のものから新しい合成リソースを独力で進む基礎を全く提供しません。
Because the network access discipline imposed by each
resource is a human-engineered command language, rather than a
machine-oriented communication protocol, it is virtually
impossible for one resource to programatically draw upon the
services of others. Doing so would require that the program
deal successfully with complicated echoing and feedback
characteristics; unstructured, even unsolicited system
responses; and so forth. Hands-on resource sharing thus does
nothing to provide an environment in which existing resources
can be used as building blocks to construct new, more powerful
ones.
各リソースによって課されたネットワークアクセス規律がマシン指向の通信プロトコルよりむしろ人間によって設計されたコマンド言語であるので、1つのリソースがprogramaticallyに他のもののサービスを利用するのは、実際には不可能です。 そうするのは、プログラムが首尾よく複雑な反響とフィードバックの特性に対処するのを必要とするでしょう。 不統一で、求められていないシステム・レスポンスさえ。 そして、など。 その結果、実地のリソース・シェアリングは新しい状態で組み立てるブロックとして既存のリソースを使用できる環境を提供するようなことを何もしません、より強力なもの。
These inherent limitations of hands-on resource sharing are removed by a protocol that simplifies and standardizes the dialog between user and server processes. Given such a protocol, the
ユーザとサーバプロセスの間の対話を簡素化して、標準化するプロトコルは実地のリソース・シェアリングのこれらの固有の制限を取り除きます。 そのようなプロトコルを与えます。
-3-
-3-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
The Current Software Approach to Resource Sharing
NWG/RFC#707JEW14 1月の76 19: リソース・シェアリングへの現在のソフトウェアアプローチを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
various remote resources upon which a user might wish to draw can indeed be made to appear as a single, coherent workshop by interposing between him and them a command language interpreter that transforms his commands into the appropriate protocol utterances [10, 11]. The construction of composite resources also becomes feasible, since each resource is accessible by means of a machine-oriented protocol and can thus be readily employed by other processes within the network. 2b4
本当に、ユーザが描きたがっているかもしれない様々な遠隔資源は、単一の、そして、一貫性を持っているワークショップとして彼とそれらの間で彼のコマンドを適切なプロトコル発声[10、11]に変えるコマンド言語インタプリタを挿入することによって、現れさせられることができます。 また、合成リソースの工事は可能になります、各リソースを、マシン指向のプロトコルによるアクセスしやすく、その結果、ネットワークの中の他のプロセスは容易に使うことができます。 2b4
Standardizing the Inter-Machine Dialog in Specific Application Areas 2c
特定の応用分野2cでの相互マシン対話を標準化します。
After the TELNET protocol had been designed and widely implemented within the ARPANET, work began on a family of function-oriented protocols designed for use by programs, rather than human users. Each such protocol standardizes the inter-machine dialog in a particular application area. While TELNET dictates only the manner in which user and server processes are interconnected via the IPC facility, and the character set in which the two processes communicate once connected, each member of this family specifies in addition the syntax and semantics of the commands and responses that comprise their dialog. 2c1
TELNETプロトコルが設計されて、アルパネットの中で広く実装された後に、仕事は使用のために人間のユーザよりむしろプログラムで設計された機能指向のプロトコルのファミリーで始まりました。 そのような各プロトコルは特定用途部で相互マシン対話を標準化します。 どのユーザとサーバプロセスがIPC施設でインタコネクトされているかでTELNETは方法だけを書き取ります、そして、2つのプロセスが一度交信する文字集合は接続しましたが、このファミリーの各メンバーはさらに、それらの対話を包括するコマンドと応答の構文と意味論を指定します。 2c1
Protocols within this family necessarily differ in substance, each specifying its own application-specific command set. The File Transfer Protocol (FTP) [12], for example, specifies commands for manipulating files, and the Remote Job Entry Protocol (RJE) [13] specifies commands for manipulating batch jobs. Protocols throughout the family are, however, similar in form, each successive family member having simply inherited the physical features of its predecessors. Thus FTP and RJE enforce the same conventions for formulating commands and responses. 2c2
実のところ、それぞれそれ自身のアプリケーション特有のコマンドセットを指定して、このファミリーの中のプロトコルは必ず異なります。 例えば、File Transferプロトコル(FTP)[12]はファイルを操作するためのコマンドを指定します、そして、Remote Job Entryプロトコル(RJE)[13]はバッチ・ジョブを操るためのコマンドを指定します。 しかしながら、ファミリー中のプロトコルはフォームにおいて同様です、それぞれの連続した親族が単に前任者の身体的な特徴を引き継いで。 したがって、FTPとRJEは、コマンドと応答を定式化するために同じコンベンションを実施します。 2c2
This common command/response discipline requires that commands and responses have the following respective formats: 2c3
この一般的なコマンド/応答規律は、コマンドと応答には以下のそれぞれの形式があるのを必要とします: 2c3
command-name <SP> parameter <CRLF> response-number <SP> text <CRLF>
コマンド名<SP>パラメタ<CRLF>応答番号<SP>テキスト<CRLF>。
Each command invoked by the user process is identified by NAME and is allowed a single PARAMETER. Each response generated by the server process contains a three-digit decimal response NUMBER (to be interpreted by the user process) and explanatory TEXT (for presentation, if necessary, to the user). Response numbers are assigned in such a way that, for example, positive and negative acknowledgments can be easily distinguished by the user process. 2c4
ユーザ・プロセスで呼び出された各コマンドは、NAMEによって特定されて、独身のPARAMETERを許容されています。 サーバプロセスによって生成された各応答は3ケタの小数に、応答NUMBER(ユーザ・プロセスによって解釈される)と説明しているTEXT(必要ならユーザへのプレゼンテーションのための)を含んでいます。 応答番号はユーザ・プロセスで容易に例えば、積極的で否定的な承認を区別できるような方法で割り当てられます。 2c4
-4-
-4-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
The Current Software Approach to Resource Sharing
NWG/RFC#707JEW14 1月の76 19: リソース・シェアリングへの現在のソフトウェアアプローチを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
FTP contains, among others, the following commands (each listed with one of its possible responses) for retrieving, appending to, replacing, and deleting files, respectively, within the server process' file system: 2c5
FTPは検索のために特に以下のコマンドを含んでいます(可能な応答の1つによってそれぞれ記載されます)、それぞれファイルを置き換えて、削除して、過程のサーバところの中にシステムをファイルするために追加して: 2c5
Command Response
コマンド応答
RETR <SP> filename <CRLF> 250 <SP> Beginning transfer. <CRLF> APPE <SP> filename <CRLF> 400 <SP> Not implemented. <CRLF> STOR <SP> filename <CRLF> 453 <SP> Directory overflow. <CRLF> DELE <SP> filename <CRLF> 450 <SP> File not found. <CRLF>
RETR<SP>ファイル名<CRLF>250<SP>Beginningは移します。 <CRLF>400<SP>Notが実装した<CRLF>APPE<SP>ファイル名。 <CRLF>STOR<SP>ファイル名<CRLF>453<SP>ディレクトリオーバーフロー。 <CRLF>450<SP>Fileが見つけなかった<CRLF>DELE<SP>ファイル名。 <CRLF>。
The first three commands serve only to initiate the transfer of a file from one machine to another. The transfer itself occurs on a separate IPC channel and is governed by what amounts to a separate protocol. 2c6
最初の3つのコマンドが、単にファイルの1台のマシンから別のマシンまでの転送を起こすのに役立ちます。 転送自体は、別々のIPCチャンネルの上に起こって、別々のプロトコルに達することによって治められます。 2c6
Since the general command format admits but a single parameter, multiparameter operations must be implemented as sequences of commands. Thus two commands are required to rename a file: 2c7
形式が認める一般的なコマンドにもかかわらず、ただ一つのパラメタ以来、コマンドの系列としてマルチパラメータ操作を実装しなければなりません。 したがって、2つのコマンドがファイルを改名するのに必要です: 2c7
Command Response
コマンド応答
RNFR <SP> oldname <CRLF> 200 <SP> Next parameter. <CRLF> RNTO <SP> newname <CRLF> 253 <SP> File renamed. <CRLF>
RNFR<SP>oldname<CRLF>200<SP>Nextパラメタ。 <CRLF>253<SP>Fileが改名した<CRLF>RNTO<SP>newname。 <CRLF>。
-5-
-5-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A Command/Response Protocol, the Basis for an Alternative Approach
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソースのためのコマンド/応答プロトコルを共有するハイレベルのフレームワーク、代替的アプローチの51 34263NCC76基礎
A COMMAND/RESPONSE PROTOCOL, THE BASIS FOR AN ALTERNATIVE APPROACH 3
コマンド/応答プロトコル、代替的アプローチ3の基礎
The Importance of Factoring Out the Command/Response Discipline 3a
コマンド/応答から規律3aを因数分解する重要性
That FTP, RJE, and the other protocols within this family share a common command/response discipline is a fact not formally recognized within the protocol literature, and each new protocol document describes it in detail, as if for the first time. Nowhere are these conventions codified in isolation from the various contexts in which they find use, being viewed as a necessary but relatively unimportant facet of each function-oriented protocol. "This common command/response discipline has thus gone unrecognized as the important, application-independent protocol that it is." 3a1
FTP、RJE、およびこのファミリーの中の他のプロトコルが一般的なコマンド/応答規律を共有するのは、プロトコル文学の中で正式に認識されなかった事実です、そして、それぞれの新しいプロトコルドキュメントは詳細にそれについて説明します、まるで初めてかのように。 どこにも、分離してそれらが使われる様々な文脈から成文化されたこれらのコンベンションがあります、それぞれの機能指向のプロトコルの必要な、しかし、比較的重要でない一面として見なされて。 「その結果、この一般的なコマンド/応答規律は重要で、アプリケーションから独立しているプロトコルとして認識されていなくなりました。」 3a1
This oversight has had two important negative effects upon the growth of resource sharing within the ARPANET: 3a2
この見落としはアルパネットの中に2回の重要なマイナスの効果をリソース・シェアリングの成長に持っていました: 3a2
(1) It has allowed the command/response discipline to remain
crude.
(1) それはコマンド/応答規律がままに粗雑な状態でしました。
As already noted, operations that require more than a
single parameter are consistently implemented as two or more
separate commands, each of which requires a response and thus
incurs the overhead of a full round-trip network delay.
Furthermore, there are no standards for encoding parameter
types other than character strings, nor is there provision for
returning results in a command response.
すでに言及したように、2以上がコマンド(それのそれぞれが、応答を必要として、その結果、完全な往復のネットワーク遅延のオーバーヘッドを被る)を切り離すとき、ただ一つのパラメタ以上を必要とする操作が一貫して実装されます。 その上、文字列以外のパラメータの型をコード化する規格が全くありません、そして、戻っている結果への支給はコマンド応答中ではありません。
(2) It has placed upon the applications programmer the burden of
implementing the network "run-time environment (RTE)" that
enables him to access remote processes at the desired,
functional level.
(2) それはネットワークが彼が必要で、機能的なレベルでリモートプロセスにアクセスするのを可能にする「ランタイム環境(RTE)」であると実装する負担をアプリケーションプログラマにかけました。
Before he can address remote processes in terms like the
following:
以前、彼は以下のような用語でリモートプロセスを扱うことができます:
execute function DELE with argument TEXTFILE
on machine X
マシンXの上の議論TEXTFILEと共に機能DELEを実行してください。
the applications programmer must first construct (as he
invariably does in every program he writes) a module that
provides the desired program interface while implementing the
agreed upon command/response discipline. This run-time
environment contains the code required to properly format
outgoing commands, to interface with the IPC facility, and to
parse incoming responses. Because the system provides only
アプリケーションプログラマは最初に、コマンド/応答規律で同意を実装している間に必要なプログラムインタフェースを提供するモジュールを構成しなければなりません(彼があらゆるプログラムで不変的にするように、彼は書きます)。 このランタイム環境は適切にIPC施設に連結する外向的なコマンドをフォーマットして、入って来る応答を分析するのに必要であるコードを含んでいます。 システムが提供される、唯一
-6-
-6-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A Command/Response Protocol, the Basis for an Alternative Approach
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソースのためのコマンド/応答プロトコルを共有するハイレベルのフレームワーク、代替的アプローチの51 34263NCC76基礎
the IPC facility as a foundation, the applications programmer
is deterred from using remote resources by the amount of
specialized knowledge and software that must first be
acquired.
基礎としてのIPC施設、アプリケーションプログラマは最初に入手しなければならない専門知識とソフトウェアの量に従って遠隔資源を使用するのが思いとどまらせられます。
If, on the other hand, the command/response discipline were
formalized as a separate protocol, its use in subsequent
function-oriented protocols could rightly be anticipated by
the systems programmer, and a single run-time environment
constructed for use throughout an installation (in the worst
case, one implementation per programming language per machine
might be required). This module could then be placed in a
library and, as depicted in Figure 2, link loaded with (or
otherwise made available to) each new applications program,
thereby greatly simplifying its use of remote resources.
他方では、コマンド/応答規律が別々のプロトコルとして正式にされるなら、その後の機能指向のプロトコルにおける使用は環境がインストールの間中使用のために構成したシステム・プログラマ、およびただ一つのランタイムによって正しく予期されるかもしれないでしょうに(最悪の場合には、1マシンあたりのプログラミング言語あたり1つの実装が必要であるかもしれません)。 このモジュールは、それぞれの新しいアプリケーションプログラムに積んで(または、別の方法で利用可能に作られています)、その結果、遠隔資源の使用を大いに簡素化しながら、次に、ライブラリに置かれて、図2に表現されるようにリンクされることができました。
Furthermore, since enhancements to it would pay dividends
to every applications program employing its services, the
run-time environment would gradually be augmented to provide
additional new services to the programmer.
それへの増進はサービスを使うあらゆるアプリケーションプログラムに配当を払うでしょう、その上、したがって、ランタイム環境が、プログラマへの追加新種業務を提供するために徐々に増大するでしょう。
The thesis of the present paper is that one of the keys to facilitating network resource sharing lies in (1) isolating as a separate protocol the command/response discipline common to a large class of applications protocols; (2) making this new, application-independent protocol flexible and efficient; and (3) constructing at each installation a RTE that employs it to give the applications programmer easy and high-level access to remote resources. 3a3
現在の新聞の論文はネットワーク資源共有を容易にするキーの1つが別々のプロトコルとして多人数のクラスのアプリケーションプロトコルに共通のコマンド/応答規律を隔離しながら(1)に横たわっているということです。 (2) この新しくて、アプリケーションから独立しているプロトコルをフレキシブルで効率的にします。 そして、(3) 各インストールのときにRTEを組み立てて、それは、遠隔資源への簡単でハイレベルのアクセスをアプリケーションプログラマに与えるのにそれを使います。 3a3
Specifications for the Command/Response Protocol 3b
コマンド/応答プロトコル3bのための仕様
Having argued the value of a command/response protocol (hereafter termed the Protocol) as the foundation for a large class of applications protocols, there remains the task of suggesting the form that the Protocol might take. There are eight requirements. First, it must reproduce the capabilities of the discipline it replaces: 3b1
多人数のクラスのアプリケーションプロトコルの基礎としてコマンド/応答プロトコル(今後プロトコルと呼ばれる)の値について論争したので、プロトコルが取るかもしれない形を示すタスクは残っています。 8つの要件があります。 まず最初に、それが置き換える規律の能力を再生させなければなりません: 3b1
(1) Permit invocation of arbitrary, named commands (or functions)
implemented by the remote process.
(1) リモートプロセスによって実装された任意の、そして、命名されたコマンド(または、機能)の実施を可能にしてください。
(2) Permit command outcomes to be reported in a way that aids
both the program invoking the commmand and the user under
whose control it may be executing.
(2) コマンド結果がそれがコントロールを実行しているかもしれないそれがcommmandを呼び出すプログラムとユーザの両方を支援する方法の中報告されることを許可してください。
-7-
-7-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A Command/Response Protocol, the Basis for an Alternative Approach
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソースのためのコマンド/応答プロトコルを共有するハイレベルのフレームワーク、代替的アプローチの51 34263NCC76基礎
Second, the Protocol should remove the known deficiencies of its predecessor, that is: 3b2
2番目に、すなわち、プロトコルは前任者の知られている欠乏を取り除くべきです: 3b2
(3) Allow an arbitrary number of parameters to be supplied as
arguments to a single command.
(3) シングルへの議論が命令するようにパラメタの特殊活字の数字を供給させてください。
(4) Provide representations for a variety of parameter types,
including but not limited to character strings.
(4) 他の文字列を含むさまざまなパラメータの型の表現を提供してください。
(5) Permit commands to return parameters as results as well as
accept them as arguments.
(5) 結果としてパラメタを返して、議論としてそれらを認めるコマンドを可能にしてください。
And, finally, the Protocol should provide whatever additional capabilities are required by the more complex distributed systems whose creation the Protocol seeks to encourage. Although others may later be identified, the three capabilities below are recognized now to be important: 3b3
そして、最終的に、プロトコルはプロトコルが作成を奨励しようとするより複雑な分散システムによって必要とされるどんな追加能力も提供するべきです。 他のものは後で特定されるかもしれませんが、以下の3つの能力が現在、重要になるように認識されます: 3b3
(6) Permit the server process to invoke commands in the user
process, that is, eliminate entirely the often inappropriate
user/server distinction, and allow each process to invoke
commands in the other.
(6) サーバプロセスがユーザ・プロセスにおけるコマンドを呼び出すことを許可してください、そして、すなわち、しばしば不適当なユーザ/サーバ区別を完全に排除してください、そして、各プロセスにもう片方におけるコマンドを呼び出させてください。
In the workshop environment alluded to earlier, for
example, the user process is the command language interpreter
and the server process is any of the software tools available
to the user. While most commands are issued by the
interpreter and addressed to the tool, occasionally the tool
must invoke commands in the interpreter or in another tool. A
graphical text editor, for example, must invoke commands
within the interpreter to update the user's display screen
after an editing operation.
より早く暗示されたワークショップ環境で、例えば、ユーザ・プロセスはコマンド言語インタプリタです、そして、サーバプロセスはユーザにとって、利用可能なソフトウェアツールのいずれでもあります。 ほとんどのコマンドが、インタプリタによって発行されて、ツールに扱われますが、時折、ツールはインタプリタか別のツールにおけるコマンドを呼び出さなければなりません。 例えば、グラフィカルなテキストエディタは編集操作の後にユーザのディスプレイの画面をアップデートするインタプリタの中のコマンドを呼び出さなければなりません。
(7) Permit a process to accept two or more commands for
concurrrent execution.
(7) プロセスがconcurrrent実行のために2つ以上のコマンドを受け入れることを許可してください。
The text editor may wish to permit the user to initiate a
long formatting operation with one command and yet continue to
issue additional, shorter commands before there is a response
to the first.
テキストエディタは、ユーザが、1つのコマンドで長い形式操作を開始しますが、1日への応答がある前に追加していて、より短いコマンドを発行し続けているのを許容したがっているかもしれません。
(8) Allow the process issuing a command to suppress the response
the command would otherwise elicit.
(8) そうでなければコマンドが引き出す応答を抑圧するコマンドを発行するプロセスを許容してください。
This feature would permit network traffic to be reduced in
those cases in which the process invoking the command deems a
この特徴は、ネットワークトラフィックがコマンドを呼び出すプロセスがaを考えるそれらの場合で減少するのを許容するでしょう。
-8-
-8-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A Command/Response Protocol, the Basis for an Alternative Approach
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソースのためのコマンド/応答プロトコルを共有するハイレベルのフレームワーク、代替的アプローチの51 34263NCC76基礎
response unnecessary. Commands that always succeed but never
return results are obvious candidates for this kind of
treatment.
応答不要です。 いつも成功しますが、結果を決して返さないコマンドはこの種類の処理の明白な候補です。
A Formulation of the Protocol That Meets These Specifications 3c
これらの仕様3cに会うプロトコルの定式化
The eight requirements listed above are met by a protocol in which the following two messages are defined: 3c1
上にリストアップされた8つの必要条件が以下の2つのメッセージが定義されるプロトコルによって満たされます: 3c1
message-type=COMMAND [tid] command-name arguments message-type=RESPONSE tid outcome results
COMMAND[tid]コマンド名議論メッセージメッセージタイプ=タイプはRESPONSE tid結果結果と等しいです。
Here and in subsequent protocol descriptions, elements enclosed in square brackets are optional. 3c2
こことその後のプロトコル記述では、角括弧で同封された要素は任意です。 3c2
The first message invokes the command whose NAME is specified using the ARGUMENTS provided. The second is issued in eventual response to the first and returns the OUTCOME and RESULTS of the completed command. Whenever OUTCOME indicates that a command has failed, the command'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 protocol thus provides a framework for reporting errors, while leaving to the applications program the tasks of assigning error numbers and composing the text of error messages. 3c3
最初のメッセージはNAMEが提供されたARGUMENTSを使用することで指定されるコマンドを呼び出します。 秒は、1日への最後の応答で発行されて、完成したコマンドのOUTCOMEとRESULTSを返します。 OUTCOMEが、コマンドが失敗したのを示すときはいつも、コマンドのRESULTSがエラー番号と診断メッセージであることが必要です、呼び出しプログラムが、次に何をしたらよいかを決定するのを助ける前者、ユーザへの可能なプレゼンテーションのための後者。 その結果、プロトコルはエラー番号を割り当てて、エラーメッセージのテキストを構成するタスクをアプリケーションプログラムに残している間、誤りを報告するのにフレームワークを提供します。 3c3
There are several elements of the Protocol that are absent from the existing command/response discipline: 3c4
プロトコルのいくつかの既存のコマンド/応答規律から欠けている原理があります: 3c4
(1) RESULTS, in fulfillment of Requirement 5.
(1) Requirement5の遂行におけるRESULTS。
(2) A MESSAGE TYPE that distinguishes commands from responses,
arising from Requirement 6.
(2) Requirement6から起こって、区別するMESSAGE TYPEは応答から命令します。
In the existing discipline, this distinction is implicit,
since user and server processes receive only responses and
commands, respectively.
既存の規律で、この区別は、ユーザとサーバプロセスが応答だけを受けるので暗黙であり、それぞれ命令します。
(3) An optional transaction identifier TID by which a command and
its response are associated, arising from Requirements 7 and
8.
(3) Requirements7と8から起こって、コマンドとその応答が関連している任意のトランザクション識別子TID。
The presence of a transaction identifier in a command
implies the necessity of a response echoing the identifier;
and no two concurrently outstanding commands may bear the same
identifier.
コマンドにおける、トランザクション識別子の存在は応答が識別子を反映するという必要性を含意します。 そして、2つの同時に傑出しているコマンドが同じ識別子を持ってはいけません。
-9-
-9-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A Command/Response Protocol, the Basis for an Alternative Approach
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソースのためのコマンド/応答プロトコルを共有するハイレベルのフレームワーク、代替的アプローチの51 34263NCC76基礎
Requirements 3 and 4--the ability to transmit an arbitrary number of parameters of various types with each command or response--are most economically and effectively met by defining a small set of primitive "data types" (for example, booleans, integers, character strings) from which concrete parameters can be modeled, and a "transmission format" in which such parameters can be encoded. Appendix A suggests a set of data types suitable for a large class of applications; Appendix B defines some possible transmission formats. 3c5
最も経済的に事実上、必要条件3と4(各コマンドか応答のときに様々なタイプのパラメタの特殊活字の数字を伝える能力)は、具体的なパラメタをモデル化できる小さいセットの原始の「データ型」(論理演算子、例えばキャラクタが結ぶ整数)、およびそのようなパラメタをコード化できる「トランスミッション形式」を定義することによって、満たされます。 付録Aは多人数のクラスのアプリケーションに適したデータ型のセットを示します。 付録Bはいくつかの可能なトランスミッション書式を定義します。 3c5
The protocol description given above is, of course, purely symbolic. Appendix C explores one possible encoding of the Protocol in detail. 3c6
上に与えられたプロトコル記述はもちろん純粋にシンボリックです。 プロトコルが詳細にコード化されながら、付録Cは可能な1つを探検します。 3c6
Summarizing the Arguments Advanced So Far 3d
議論をまとめると、3dは今までのところ、進められました。
The author trusts that little of what has been presented thus far will be considered controversial by the reader. The following principal arguments have been made: 3d1
作者は、読者によって論議を呼ぶとこれまでのところ提示されたことについて少ししか考えられないと信じます。 以下の主偏角をしました: 3d1
(1) The more effective forms of resource sharing depend upon
remote resources being usefully accessible to other programs,
not just to human users.
(1) リソース・シェアリングの、より効果的なフォームは有効に人間のユーザだけではなく、他のプログラムにアクセス可能な遠隔資源に依存します。
(2) Application-dependent protocols providing such access using
the current approach leave to the applications programmer the
task of constructing the additional layer of software (above
the IPC facility provided by the system) required to make
remote resources accessible at the functional level, thus
discouraging their use.
(2) 現在のアプローチを使用することでそのようなアクセスを提供するアプリケーション依存するプロトコルが追加層のソフトウェア(システムによって提供されたIPC施設の上の)を構成するタスクが遠隔資源を機能的なレベルでアクセスしやすくするのを必要としたアプリケーションプログラマに任せます、その結果、彼らの使用に水をさしています。
(3) A single, resource-independent protocol providing flexible
and efficient access at the functional level to arbitrary
remote resources can be devised.
(3) 機能的なレベルでフレキシブルで効率的なアクセスを任意の遠隔資源に提供する単一の、そして、リソースから独立しているプロトコルについて工夫できます。
(4) This protocol would make possible the construction at each
installation of an application-independent, network run-time
environment making remote resources accessible at the
functional level and thus encouraging their use by the
applications programmer.
(4) このプロトコルで、アプリケーションプログラマによるアプリケーション独立者と、遠隔資源を機能的なレベルでアクセスしやすくするネットワークランタイム環境とその結果、彼らの使用を奨励する各インストールにおける工事は可能になるでしょう。
A protocol as simple as that suggested here has great potential for stimulating the sharing of resources within a computer network. First, it would reduce the cost of adapting existing resources for network use by eliminating the need for the design, documentation, and implementation of specialized delivery protocols. Second, it
ここでそんなに示されるのと同じくらい簡単なプロトコルには、コンピュータネットワークの中でリソースの共有を刺激するための素晴らしい潜在能力があります。 まず最初に、それは専門化している配送プロトコルのデザイン、ドキュメンテーション、および実装の必要性を排除することによってネットワーク使用のための既存のリソースを適合させるコストを削減するでしょう。 2番目に、それ
-10-
-10-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A Command/Response Protocol, the Basis for an Alternative Approach
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソースのためのコマンド/応答プロトコルを共有するハイレベルのフレームワーク、代替的アプローチの51 34263NCC76基礎
would encourage the use of remote resources by eliminating the need for application-specific interface software. And finally, it would encourage the construction of new resources built expressly for remote access, because of the ease with which they could be offered and used within the network software marketplace. 3d2
アプリケーション特有のインタフェースソフトウェアの必要性を排除することによって、遠隔資源の使用を奨励するでしょう。 そして、最終的に、遠隔アクセスのために明白に築き上げられた新しいリソースの工事を奨励するでしょう、ネットワークソフトウェア市場の中でそれらを提供して、使用できた容易さのために。 3d2
-11-
-11-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A High-Level Model of the Network Environment
NWG/RFC#707JEW14 1月の76 19: ネットワーク環境のハイレベルのモデルを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
A HIGH-LEVEL MODEL OF THE NETWORK ENVIRONMENT 4
ネットワーク環境4のハイレベルのモデル
The Importance of the Model Imposed by the Protocol 4a
プロトコル4aによって課されたモデルの重要性
The Protocol proposed above imposes upon the applications programmer a particular model of the network environment. In a heterogeneous computer network, nearly every protocol intended for general implementation has this effect, since it idealizes a class of operations that have concrete but slightly different equivalents in each system. Thus the ARPANET's TELNET Protocol alluded to earlier, for example, specifies a Network Virtual Terminal that attempts to provide a best fit to the many real terminals in use around the Network. 4a1
上で提案されたプロトコルはネットワーク環境の特定のモデルをアプリケーションプログラマに課します。 異種計算機ネットワークでは、一般的な実装のために意図するほとんどあらゆるプロトコルがこの効果を持っています、各システムの具体的な、しかし、わずかに異なった同等物を持っている操作のクラスを理想化するので。 したがって、例えばより早く暗示されたアルパネットのTELNETプロトコルはNetworkの周りで使用中の多くの本当の端末に最良適合を供給するのを試みるNetwork Virtual Terminalを指定します。 4a1
As now formulated, the Protocol models a remote resource as an interactive program with a simple, rigidly specified command language. This model follows naturally from the fact that the function-oriented protocols from which the Protocol was extracted were necessitated by the complexity and diversity of user-oriented command languages. The Protocol may thus legitimately be viewed as a vehicle for providing, as an adjunct to the sophisticated command languages already available to users, a family of simple command languages that can readily be employed by programs. 4a2
現在定式化されるように、プロトコルは双方向番組として簡単で、厳格に指定されたコマンド言語で遠隔資源をモデル化します。 このモデルはプロトコルが抜粋された機能指向のプロトコルが利用者志向コマンド言語の複雑さと多様性によって必要とされたという事実から自然に続きます。 その結果、プロトコルは提供するための乗り物として合法的に見なされるかもしれません、ユーザには、既に利用可能な精巧なコマンド言語への付属物として、プログラム4a2が容易に使うことができる簡単なコマンド言語のファミリー
While the command/response model is a natural one, others are possible. A remote resource might also be modeled as a process that services and replies to requests it receives from other computer processes. This request/reply model would emphasize the fact that the Protocol is a vehicle for inter-process communication and that no human user is directly involved. 4a3
コマンド/応答モデルは自然なものですが、他のものは可能です。 また、遠隔資源はそれが他のコンピュータプロセスから受け取る要求に修理して、答えるプロセスとしてモデル化されるかもしれません。 この要求/回答モデルはプロトコルが相互プロセスコミュニケーションのための手段であり、どんな人間のユーザも直接かかわらないという事実を強調するでしょう。 4a3
Substituting the request/reply model for the command/response model requires only cosmetic changes to the Protocol: 4a4
要求/回答モデルをコマンド/応答モデルの代わりに用いるのはプロトコルへの表面の変化だけを必要とします: 4a4
message-type=REQUEST [tid] op-code arguments message-type=REPLY tid outcome results
REQUEST[tid]演算コード議論メッセージメッセージタイプ=タイプはREPLY tid結果結果と等しいです。
In the formulation above, the terms "REQUEST", "REPLY", and "op-code" have simply been substituted for "COMMAND", "RESPONSE", and "command-name", respectively. 4a5
上では、用語が「要求する」定式化では、それぞれ単に「コマンド」、「応答」、および「コマンド名」に「回答」、および「演算コード」を代入しました。 4a5
The choice of model need affect neither the content of the Protocol nor the behavior of the processes whose dialog it governs. Use of the word "command" in the command/response model, for example, is not meant to imply that the remote process can be coerced into action. Whatever model is adopted, a process has
モデルの選択はプロトコルの内容もそれが対話を支配するプロセスの振舞いも影響する必要はありません。 例えば、コマンド/応答モデルにおける「コマンド」という言葉の使用は、リモートプロセスを動作に強制できるのを含意することになっていません。 採用されるどんなモデル、プロセスもそうしました。
-12-
-12-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A High-Level Model of the Network Environment
NWG/RFC#707JEW14 1月の76 19: ネットワーク環境のハイレベルのモデルを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
complete freedom to reject an incoming remote request that it is incapable of or unwilling to fulfill. 4a6
不可能であるか実現したがっていないという入って来るリモート要求を拒絶する自由を完成してください。 4a6
But even though it has no substantive effect upon the Protocol, the selection of a model--command/response, request/reply, and so on--is an important task because it determines the way in which both applications and systems programmers perceive the network environment. If the network environment is made to appear foreign to him, the applications programmer may be discouraged from using it. The choice of model also constrains the kind and range of protocol extensions that are likely to occur to the systems programmer; one model may suggest a rich set of useful extensions, another lead nowhere (or worse still, in the wrong direction). 4a7
しかし、どんな実質的な影響もプロトコルに与えませんが、アプリケーションとシステム・プログラマの両方がネットワーク環境を知覚する方法を決定するので、モデルの選択(コマンド/応答、要求/回答など)は、重要な仕事です。 ネットワーク環境は彼にとって外国に見えさせられるなら、アプリケーションプログラマが、それを使用して、がっかりするかもしれません。 また、モデルの選択はシステム・プログラマの心に浮かびそうなプロトコル拡大の種類と範囲を抑制します。 1つのモデルはどこにも(まだ間違った方向によりひどい)豊かな役に立つ拡大、別のリードを勧めないかもしれません。 4a7
In this final section of the paper, the author suggests a network model (hereafter termed the Model) that he believes will both encourage the use of remote resources by the applications programmer and suggest to the systems programmer a wide variety of useful Protocol extensions. Unlike the substance of the Protocol, however, the Model has already proven quite controversial within the ARPANET community. 4a8
紙のこの最後のセクションで、作者はアプリケーションプログラマで遠隔資源の使用を奨励して、さまざまな役に立つプロトコル拡大をシステム・プログラマに勧めると信じているネットワークモデル(今後Modelと呼ばれる)を勧めます。 しかしながら、プロトコルの実体と異なって、Modelは、アルパネット共同体の中でかなり論議を呼ぶと既に判明しました。 4a8
Modeling Resources As Collections of Procedures 4b
手順4bの収集としてリソースをモデル化します。
Ideally, the goal of both the Protocol and its accompanying RTE is to make remote resources as easy to use as local ones. Since local resources usually take the form of resident and/or library subroutines, the possibility of modeling remote commands as "procedures" immediately suggests itself. The Model is further confirmed by the similarity that exists between local procedures and the remote commands to which the Protocol provides access. Both carry out arbitrarily complex, named operations on behalf of the requesting program (the caller); are governed by arguments supplied by the caller; and return to it results that reflect the outcome of the operation. The procedure call model thus acknowledges that, in a network environment, programs must sometimes call subroutines in machines other than their own. 4b1
理想的に、プロトコルとその付随のRTEの両方の目標は地方のものとして使用する簡単であるとして遠隔資源を作ることです。 ローカル資源が通常居住者、そして/または、ライブラリ・サブルーチンの形を取るので、すぐに「手順」としてリモートコマンドをモデル化する可能性は連想されます。 Modelはローカルの手順の間に存在する類似性とプロトコルがアクセサリーを提供するリモートコマンドでさらに確認されます。 両方が要求プログラム(訪問者)を代表して任意に複雑で、命名された操作を行います。 訪問者によって供給された議論で、治められます。 そして、操作の結果を反映する結果をそれに返してください。 その結果、手順呼び出しモデルは、プログラムがそれら自身のを除いたマシンにネットワーク環境で時々サブルーチンを呼び出さなければならないと認めます。 4b1
Like the request/reply model already described, the procedure call model requires only cosmetic changes to the Protocol: 4b2
既に説明された要求/回答モデルのように、手順呼び出しモデルはプロトコルへの表面の変化だけを求めます: 4b2
message-type=CALL [tid] procedure-name arguments message-type=RETURN tid outcome results
CALL[tid]プロシージャ名議論メッセージメッセージタイプ=タイプはRETURN tid結果結果と等しいです。
In this third formulation, the terms "CALL", "RETURN", and "procedure-name" have been substituted for "COMMAND, "RESPONSE", and
そして、用語が、「リターン」、および「プロシージャ名」のためにこの3番目の定式化で代理をされたと「呼ぶ」、「「応答」と命令してください、」
-13-
-13-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A High-Level Model of the Network Environment
NWG/RFC#707JEW14 1月の76 19: ネットワーク環境のハイレベルのモデルを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
"command-name", respectively. And in this form, the Protocol might aptly be designated a "procedure call protocol (PCP)". 4b3
それぞれ「コマンド名。」 そして、このフォームでは、プロトコルは適切に「手順呼び出しプロトコル(PCP)」に指定されるかもしれません。 4b3
"The procedure call model would elevate the task of creating applications protocols to that of defining procedures and their calling sequences. It would also provide the foundation for a true distributed programming system (DPS) that encourages and facilitates the work of the applications programmer by gracefully extending the local programming environment, via the RTE, to embrace modules on other machines." This integration of local and network programming environments can even be carried as far as modifying compilers to provide minor variants of their normal procedure-calling constructs for addressing remote procedures (for which calls to the appropriate RTE primitives would be dropped out). 4b4
「手順呼び出しモデルは手順とそれらの呼出し手順を定義するものにアプリケーションプロトコルを作成するタスクを登用するでしょう。」 「また、他のマシンの上でモジュールを受け入れるためにRTEを通して優雅に地方のプログラミング環境を広げることによってアプリケーションプログラマの仕事を奨励して、容易にする正しい分配されたプログラミング・システム(DPS)の基礎を提供するでしょう。」 それらの正常な手順を呼ぶ構造物の小さい方の異形をリモート手順を扱うのに提供するようにコンパイラを変更するのと同じくらい遠くに地方とネットワークプログラミング環境のこの統合を運ぶことさえできます(どれが適切なRTE基関数に呼びかけるかは脱落されるでしょう、したがって)。 4b4
Finally, the Model is one that can be naturally extended in a variety of ways (for example, coroutine linkages and signals) to further enhance the distributed programming environment. 4b5
最終的に、Modelは自然にさらに分配されたプログラミング環境を高めるさまざまな方法(例えば、コルーチンリンケージと信号)で広げることができるものです。 4b5
Clarifying the Procedure Call Model 4c
手順呼び出しモデル4cをはっきりさせます。
Although in many ways it accurately portrays the class of network interactions with which this paper deals, the Model suggested above may in other respects tend to mislead the applications programmer. The Model must therefore be clarified: 4c1
様々な意味で、正確に、この紙の取引、上に示されたModelがそうするかもしれないネットワーク相互作用のクラスを描きますが、その他の点ではアプリケーションプログラマをミスリードする傾向があってください。 したがって、Modelをはっきりさせなければなりません: 4c1
(1) Local procedure calls are cheap; remote procedure calls are
not.
(1) 地方の手順呼び出しは安いです。 遠隔手続き呼び出しはそうではありません。
Local procedure calls are often effected by means of a
single machine instruction and are therefore relatively
inexpensive. Remote procedure calls, on the other hand, would
be effected by means of a primitive provided by the local RTE
and require an exchange of messages via IPC.
地方の手順呼び出しは、単一マシン指示によってしばしば作用して、したがって、比較的安価です。 他方では、遠隔手続き呼び出しは、地方のRTEによって提供された基関数によって作用して、IPCを通してメッセージの交換を必要とするでしょう。
Because of this cost differential, the applications
programmer must exercise discretion in his use of remote
resources, even though the mechanics of their use will have
been greatly simplified by the RTE. Like virtual memory, the
procedure call model offers great convenience, and therefore
power, in exchange for reasonable alertness to the
possibilities of abuse.
この費用デフ装置のために、アプリケーションプログラマは彼の遠隔資源の使用に思慮深さを訓練しなければなりません、彼らの使用の整備士がRTEによって大いに簡素化されてしまうでしょうが。 仮想記憶のように、手順呼び出しモデルは、かなりの便利を提供して、その結果権限を提供します、乱用の可能性への合理的な警戒と引き換えに。
(2) Conventional programs usually have a single locus of control;
distributed programs need not.
(2) 従来のプログラムには、通常、コントロールのただ一つの場所があります。 分配されたプログラムはそうする必要はありません。
-14-
-14-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
A High-Level Model of the Network Environment
NWG/RFC#707JEW14 1月の76 19: ネットワーク環境のハイレベルのモデルを共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
Conventional programs are usually implemented as a single
process with exactly one locus of control. A procedure call,
therefore, traditionally implies a transfer of control from
caller to callee. Distributed systems, on the other hand, are
implemented as two or more processes, each of which is capable
of independent execution. In this new environment, a remote
procedure call need not suspend the caller, which is capable
of continuing execution in parallel with the called procedure.
通常、従来のプログラムは単一のプロセスとしてまさにコントロールの1つの場所で実装されます。 したがって、手順呼び出しは訪問者から訪問される人までの移管を伝統的に含意します。 他方では、分散システムは2つ以上のプロセスとして実装されます。それは独立している実行がそれぞれできます。 この新しい環境で、遠隔手続き呼び出しは訪問者を停学処分にする必要はありません。(その訪問者は、呼ばれた手順と平行して実行を続けることができます)。
The RTE can therefore be expected to provide, for
convenience, two modes of remote procedure invocation: a
blocking mode that suspends the caller until the procedure
returns; and a non-blocking mode that releases the caller as
soon as the CALL message has been sent or queued. Most
conventional operating systems already provide such a mode
choice for I/O operations. For non-blocking calls, the RTE
must also, of course, either arrange to asynchronously notify
the program when the call is complete, or provide an
additional primitive by which the applications program can
periodically test for that condition.
したがって、RTEがリモート手順実施の2つのモードを便利に提供すると予想できます: 手順が戻るまで訪問者を停学処分にするブロッキングモード。 そして、CALLメッセージの次第訪問者を釈放する非ブロッキングモードを、送るか、または列に並ばせました。 ほとんどの従来のオペレーティングシステムが既に入出力操作のためのそのようなモード選択を提供します。 また、非ブロッキング呼び出しのために、RTEは、もちろん呼び出しが完全であるときに、プログラムに非同期に通知するか、またはアプリケーションプログラムがその状態がないかどうか定期的に検査されることができる追加基関数を提供するように手配しなければなりません。
Finally, the applications programmer must recognize that by no means all useful forms of network communication are effectively modeled as procedure calls. The lower level IPC facility that remains directly accessible to him must therefore be employed in those applications for which the procedure call model is inappropriate and RTE-provided primitives simply will not do. 4c2
最終的に、アプリケーションプログラマは、手順が呼ぶように事実上、決してネットワークコミュニケーションのすべての役に立つフォームがモデル化されるというわけではないと認めなければなりません。 したがって、手順呼び出しモデルが不適当でRTEによって提供された基関数が絶対に大丈夫でないということであるそれらのアプリケーションで彼には直接アクセスしやすいままで残っている下のレベルIPC施設を使わなければなりません。 4c2
-15-
-15-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Some Expectations
NWG/RFC#707JEW14 1月の76 19: いくつかの期待を共有するネットワークベースのリソースのためのハイレベルのフレームワークあたり51 34263NCC76
SOME EXPECTATIONS 5
いくつかの期待5
Both the Procedure Call Protocol and its associated Run-Time Environment have great potential for facilitating the work of the network programmer; only a small percentage of that potential has been discussed in the present paper. Upon the foundation provided by PCP can be erected higher level application-independent protocol layers that further enhance the distributed programming environment by providing even more powerful capabilities (see Appendix D). 5a
Procedure Callプロトコルと関連Run-時間Environmentの両方には、ネットワークプログラマの仕事を容易にするための素晴らしい潜在能力があります。 現在の新聞でその可能性のわずかな百分率だけについて議論しました。 PCPによって提供された基礎に、さらに強力な能力を提供することによって分配されたプログラミング環境をさらに高める建設されたより高い平らなアプリケーションから独立しているプロトコル層があることができます(Appendix Dを見てください)。 5a
As the importance of the RTE becomes fully evident, additional tasks will gradually be assigned to it, including perhaps those of: 5b
RTEの重要性が完全に明白になるとき、追加タスクは徐々にそれに割り当てられるでしょう、恐らく以下のものを含んでいて 5b
(1) Converting parameters between the format employed internally
by the applications program, and that imposed by the
Protocol. 5b1
(1) アプリケーションプログラムで内部的に使われた形式と、プロトコルによって課されたそれの間のパラメタを変換すること。 5b1
(2) Automatically selecting the most appropriate inter-process
transmission format on the basis of the two machines' word
sizes. 5b2
(2) 2台のマシンに基づいて自動的に最も適切な相互プロセストランスミッション形式を選択して、サイズを言い表してください。 5b2
(3) Automatically substituting for network IPC a more efficient
form of communication when both processes reside on the same
machine. 5b3
(3) 自動的に両方のプロセスが同じマシンの上に住んでいると、コミュニケーションの、より効率的なフォームをネットワークIPCに代入します。 5b3
The RTE will eventually offer the programmer a wide variety of application-independent, network-programming conveniences, and so, by means of the Protocol, become an increasingly powerful distributed-system-building tool. 5c
プロトコルによって、RTEは、結局さまざまなアプリケーションから独立していて、ネットワークをプログラムする利器をプログラマに提供するので、ますます強力な分配された制度設定ツールになるでしょう。 5c
-16-
-16-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Acknowledgments
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング承認のためのハイレベルのフレームワークあたり51 34263NCC76
ACKNOWLEDGMENTS 6
承認6
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 paper. The contributions of the following individuals are expressly acknowledged: Dick Watson, Jon Postel, Charles Irby, Ken Victor, Dave Maynard, and Larry Garlick of ARC; and Bob Thomas and Rick Schantz of Bolt, Beranek and Newman, Inc. 6a
SRIのAugmentation Researchセンター(ARC)と、より大きいアルパネット共同体の両方の中の多くの個人がこの紙で説明されたプロトコルとModelの開発に彼らの時間と考えを寄付しました。 以下の個人の貢献は明白に承諾されます: アークのディック・ワトソン、ジョン・ポステル、チャールズ・イルビー、ケンビクタ、デーヴ・メイナード、およびラリー・ガーリック。 そして、ボルト、Beranek、およびニューマンInc.6aのボブ・トーマスとリックSchantz
ARC has been working toward a high-level framework for network-based distributed systems for a number of years now [14]. The particular Protocol and Model described here result from research begun by ARC in July of 1974. This research included developing the Model; designing and documenting the Protocol required to support it [15]; and designing, documenting, and implementing a prototype run-time environment for a particular machine [16, 17], specifically a PDP-10 running the Tenex operating system developed by Bolt, Beranek and Newman, Inc [18]. 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 presented in the body of this paper and Appendices A through C as well as those alluded to in Appendix D. 6b
ARCは多年にわたり現在[14]、ネットワークベースの分散システムのためにハイレベルのフレームワークに向かって取り組んでいます。 特定のプロトコルとModelはここで1974年7月にARCによって始められた研究から結果について説明しました。 この研究は、Modelを開発するのを含んでいました。 プロトコルを設計して、記録するのがそれが[15]であるとサポートするのが必要です。 そして、特定のマシン[16、17]のためにプロトタイプランタイム環境を設計して、記録して、実装して、BoltとBeranekとニューマン(Inc[18])で明確にTenexオペレーティングシステムを動かすPDP-10は展開しました。 3つのデザイン繰り返しが12カ月の期間、およびTenexのために履行された結果として起こる仕様の間、行われました。 Tenex RTEはAppendix D.6bで暗示されたものと同様にCを通してこの紙とAppendices Aのボディーに提示された能力のスーパーセットを提供します。
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. 6c
ここで報告された仕事は国防総省のAdvanced Research Projects Agency、および空軍ローム航空開発センターによってサポートされました。 6c
-17-
-17-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Appendix A: Suggested Data Types
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング付録A:のためのハイレベルのフレームワークあたり51 34263NCC76 提案されたデータ型
APPENDIX A: SUGGESTED DATA TYPES 7
付録A: 提案されたデータ型7
The Protocol requires that every parameter or "data object" be represented by one of several primitive data types defined by the Model. The set of data types below is sufficient to conveniently model a large class of data objects, but since the need for additional data types (for example, floating-point numbers) will surely arise, the set must remain open-ended. Throughout the descriptions below, N is confined to the range [0, 2**15-1]: 7a
プロトコルは、あらゆるパラメタか「データ・オブジェクト」がModelによって定義された数人の基本データ型のひとりによって表されるのを必要とします。 追加データ型(例えば、浮動小数点の数)の必要性が確実に起こるので、以下のデータ型のセットが便利に多人数のクラスのデータ・オブジェクトをモデル化できるくらいセットは制限のないままで残らなければなりません。 以下での記述の間中、Nは範囲[0、2**15-1]に閉じ込められます: 7a
LIST: A list is an ordered sequence of N data objects called
"elements". A LIST may contain other LISTs as elements, and can
therefore be employed to construct arbitrarily complex composite
data objects. 7a1
以下を記載してください。 リストは「要素」と呼ばれるNデータ・オブジェクトの規則正しい系列です。 LISTは要素として他のLISTsを含むかもしれなくて、したがって、任意に複雑な合成データ・オブジェクトを組み立てるのに使うことができます。 7a1
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. 7a2
CHARSTR: 文字列は、N ASCII文字の規則正しい系列であり、便利にさまざまな原文の実体をモデル化します、短いユーザ名から全体のパラグラフのテキストまで。 7a2
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). 7a3
BITSTR: ストリングは、少し、Nビットの規則正しい系列であり、したがって、任意のバイナリ・データ(例えば、メモリの単語のコンテンツ)を表すための手段を提供します。 7a3
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. 7a4
整数: 整数は範囲[-2**31、2**31-1]と、便利に時間間隔を含む様々な種類に関する数値データが遠ざけるモデル、などに固定小数点数です。 7a4
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 or character within a string, or element within
a list. INDEXes have other uses as well, including the modeling
of handles or identifiers for open files, created processes, and
the like. Also, because of their restricted range, INDEXes are
more compact in transmission than INTEGERs (see Appendix B). 7a5
以下に索引をつけてください。 インデックスは範囲[1、2**15-1]の整数です。 その名前と値の範囲が示すように、ストリングの中に特定のビットかキャラクタに演説するか、またはリストの中で要素に演説するのにINDEXを使用できます。 INDEXesには、また、他の用途があります、ハンドルのモデルかオープン・ファイル、作成されたプロセス、および同様のもののための識別子を含んでいて。 また、それらの制限された範囲のために、INDEXesもINTEGERsよりトランスミッションがコンパクトです(Appendix Bを見てください)。 7a5
BOOLEAN: A boolean represents a single bit of information,
and has either the value true or false. 7a6
論理演算子: 論理演算子で、情報の1ビットを表して、値は本当であるか誤るようになります。 7a6
EMPTY: An empty is a valueless place holder within a LIST or
parameter list. 7a7
空になります: 空であるのは、LISTかパラメータ・リストの中の無価値な場所所有者です。 7a7
-18-
-18-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Appendix B: Suggested Transmission Formats
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング付録Bのためのハイレベルのフレームワークあたり51 34263NCC76: 提案されたトランスミッション形式
APPENDIX B: SUGGESTED TRANSMISSION FORMATS 8
付録B: 提案されたトランスミッション形式8
Parameters 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 RTE and could thus be made completely invisible to the applications program. 8a
プロトコルで1つのプロセスから別のものにそれらを送ることができる前に、標準のトランスミッション形式でパラメタをコード化しなければなりません。 効果的な戦略は、いくつかの書式を定義して、ランタイムのときに最も適切な1つを選択することです、形式交渉のためにメカニズムをプロトコルに追加して。 形式交渉をRTEの別の責任であるだろう、その結果、アプリケーションプログラムに完全に目に見えなくすることができました。 8a
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 RTE to automatically decode and internalize incoming parameters should it be desired to provide this service to the applications program. 8b
以下に示されているのは、2つのトランスミッション形式です。 1番目は36ビットのマシンの間の使用のための36ビットのバイナリフォーマットであり、秒は8ビットのバイナリーです、異なったマシンの間の使用のための「普遍的な」形式。 アプリケーションプログラムに対するこのサービスを提供することが望まれているならRTEが入って来るパラメタを自動的に解読して、内面化させるのを可能にするために各形式でタイプされて、データ・オブジェクトは完全にそうです。 8b
PCPB36, For Use Between 36-Bit Machines 8c
36ビットのマシン8cの間の使用のためのPCPB36
Bits 0-13 Unused (zero) 8c1
Bits 14-17 Data type 8c2
EMPTY =1 INTEGER=4 LIST=7
BOOLEAN=2 BITSTR =5
INDEX =3 CHARSTR=6
Bits 18-20 Unused (zero) 8c3
Bits 21-35 Value or length N 8c4
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 8c5
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
ビット0-13Unused(ゼロ)8c1 Bits14-17Dataは3のCHARSTR=6 Bits18-20Unused(ゼロ)8c3 Bits21-35Valueか未署名の14ゼロ・ビットの未使用(ゼロ)のブール+ 長さのNの8c4 EMPTYの1ビットの価値(TRUE=1/FALSE=0)の値のINTEGER(ゼロ)未使用のBITSTR未署名のビットカウントN INDEX5 2 1 8c2 EMPTY=INTEGER=4 LIST=7 BOOLEAN=BITSTR=INDEX=CHARSTRをタイプします; 未署名のキャラクタカウントN LISTの未署名の要素カウントN Bits36は語境界LIST要素データ・オブジェクトにそっと歩くCHARSTR ASCIIストリング+ゼロを語境界に水増しする8c5 EMPTYの未使用のブール(実在しない)未使用(実在しない)のINDEX未使用(実在しない)のINTEGER2の補数フルワード値のBITSTRビット列+ゼロを評価します。
-19-
-19-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Appendix B: Suggested Transmission Formats
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング付録Bのためのハイレベルのフレームワークあたり51 34263NCC76: 提案されたトランスミッション形式
PCPB8, For Use Between Dissimilar Machines 8d
異なったマシン8dの間の使用のためのPCPB8
Byte 0 Data type 8d1
EMPTY =1 INTEGER=4 LIST=7
BOOLEAN=2 BITSTR =5
INDEX =3 CHARSTR=6
Bytes 1- Value 8d2
EMPTY unused (nonexistent)
BOOLEAN 7 zero-bits + 1-bit value (TRUE=1/FALSE=0)
INDEX 2-byte unsigned value
INTEGER 4-byte 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タイプ8d1 EMPTY=INTEGER=4 LIST=7 BOOLEAN=BITSTR=INDEX=CHARSTR=6 Bytes1が2バイトの未署名のバイト境界のキャラクタカウントN+ASCIIストリングLISTの2バイトの要素カウントN+要素CHARSTRデータ・オブジェクトにそっと歩く未使用の8d2 EMPTYの4バイトの2バイトの(TRUE=1/FALSE=0)未署名の値のINTEGER2の補数INDEX価値のBITSTR2バイトの未署名のビット7ゼロ・ビットのブール+ (実在しない)の1ビットの価値のカウントN+ビット列+ゼロを評価します。
-20-
-20-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Appendix C: A Detailed Encoding of the Procedure Call Protocol
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング付録Cのためのハイレベルのフレームワークあたり51 34263NCC76: 手順呼び出しプロトコルの詳細なコード化
APPENDIX C: A DETAILED ENCODING OF THE PROCEDURE CALL PROTOCOL 9
付録C: 手順呼び出しプロトコル9の詳細なコード化
Although the data types and transmission formats detailed in the previous appendixes 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 commands and responses by which those parameters are transmitted. 9a
前の付属物で詳細なデータ型とトランスミッション形式は主として議論を表すための乗り物とリモート手順の結果として機能しますが、それらのパラメタが伝えられるコマンドと応答を表すのにただ同じくらい容易に同じくらい事実上それらを使うことができます。 9a
Taking this approach, one might model each of the two Protocol messages as a PCP data object, specifically a LIST whose first element is an INDEX message type. The following concise statement of the Protocol then results: 9b
このアプローチを取って、1つはPCPデータ・オブジェクト(明確に最初の要素がINDEXメッセージタイプであるLIST)としてそれぞれに関する2つのプロトコルメッセージをモデル化するかもしれません。 次に、プロトコルの以下の簡明な表明は結果として生じます: 9b
LIST (CALL, tid, procedure, arguments)
INDEX=1 INDEX/EMPTY CHARSTR LIST 9b1
LIST (RETURN, tid, outcome, results)
INDEX=2 INDEX BOOLEAN LIST 9b2
LIST(CALL、tid、手順、議論)INDEX=1 INDEX/EMPTY CHARSTR LIST 9b1 LIST(RETURN(tid、結果)は結果になる)INDEX=2 INDEX BOOLEAN LIST 9b2
The RESULTS of an unsuccessful procedure would be represented as follows: 9c
失敗の手順のRESULTSは以下の通り表されるでしょう: 9c
LIST (error, diagnostic)
INDEX CHARSTR 9c1
LIST(誤り、病気の特徴)INDEX CHARSTR 9c1
-21-
-21-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Appendix D: A Look at Some Possible Extensions to the Model
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング付録Dのためのハイレベルのフレームワークあたり51 34263NCC76: モデルへのいくつかの可能な拡大への一見
APPENDIX D: A LOOK AT SOME POSSIBLE EXTENSIONS TO THE MODEL 10
付録D: モデル10へのいくつかの可能な拡大への一見
The result of the distributed-system-building strategy proposed in the body of this paper and the preceeding appendices is depicted in Figure D-1. At the core of each process is the inter-process communication facility provided by the operating system, which effects the transmission of arbitrary binary data between distant processes. Surrounding this core are conventions regarding first the format in which a few, primitive types of data objects are encoded in binary for IPC, and then the formats of several composite data objects (that is, messages) whose transmission either invokes or acknowledges the previous invocation of a remote procedure. Immediately above lies an open-ended protocol layer in which an arbitrary number of enhancements to the distributed programming environment can be implemented. Encapsulating these various protocol layers is the installation-provided run-time environment, which delivers DPS services to the applications program according to machine- and possibly programming-language-dependent conventions. 10a
この紙とpreceeding付録のボディーで提案された分配された制度設定戦略の結果は図D-1に表現されます。 それぞれのコアでは、プロセスは遠方のプロセスの間の任意のバイナリ・データの送信に作用するオペレーティングシステムで提供されたプロセス間通信機能です。 このコアを囲んでいて、最初に、IPCのためにいくつか、プリミティブ型のデータ・オブジェクトがどれであるかでバイナリーでコード化された形式に関するコンベンション、および次に、どちらかがトランスミッションを呼び出すか、または承諾する数個の合成データ・オブジェクト(すなわち、メッセージ)の形式はリモート手順の前の実施ですか? すぐに、分配されたプログラミング環境への増進の特殊活字の数字を実装することができる制限のないプロトコル層は上に位置します。 これらが様々なプロトコル層であるとカプセル化するのは、インストールに提供されたランタイム環境です。(マシンとことによるとプログラミング言語扶養家族コンベンションに応じて、その環境はアプリケーションプログラムに対するサービスをDPSに提供します)。 10a
The Protocol proposed in the present paper recognizes only the most fundamental aspects of remote procedure calling. It permits the caller to identify the procedure to be called, supply the necessary arguments, determine the outcome of the procedure, and recover its results. In a second paper [19], the author proposes some extensions to this simple procedure call model, and attempts to identify other common forms of inter-process interaction whose standardization would enhance the distributed programming environment. Included among the topics discussed are: 10b
現在の新聞で提案されたプロトコルはリモート手順の呼ぶことの最も基本的な局面だけを認識します。 それは、訪問者が呼ばれるために手順を特定して、必要な議論を供給して、手順の結果を決定して、結果を回復することを許可します。 2番目の論文[19]では、作者は、この簡単な手順呼び出しモデルにいくつかの拡大を提案して、標準化が分配されたプログラミング環境を高める他の一般的なフォームの相互プロセス相互作用を特定するのを試みます。 含まれている、議論した話題は以下の通りです。 10b
(1) Coroutine linkages and other forms of communication between
the caller and callee. 10b1
(1) 訪問者と訪問される人とのコルーチンリンケージと他のフォームに関するコミュニケーション。 10b1
(2) Propagation of notices and requests up the thread of control
that results from nested procedure calls. 10b2
(2) 入れ子プロシージャから生じるコントロールのスレッドへの通知と要求の伝播は呼びます。 10b2
(3) Standard mechanisms for remotely reading or writing
system-global data objects within another program. 10b3
(3) 別のプログラムの中にシステムグローバルなデータ・オブジェクトを離れて読むか、または書くための標準のメカニズム。 10b3
(4) Access controls for collections of related procedures. 10b4
(4) アクセスは関連する手順の収集のために制御されます。 10b4
(5) A standard means for creating and initializing processes,
that is, for establishing contact with and logging into a
remote machine, identifying the program to be executed, and
so forth. This facility would permit arbitrarily complex
process hierarchies to be created. 10b5
(5) 規格は、プロセスを作成して、初期化するためにすなわち、リモートマシンに接触して、ログインするために実行されるべきプログラムを特定して、などを意味します。 この施設は、複雑なプロセス階層構造が作成されることを任意に許可するでしょう。 10b5
-22-
-22-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Appendix D: A Look at Some Possible Extensions to the Model
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング付録Dのためのハイレベルのフレームワークあたり51 34263NCC76: モデルへのいくつかの可能な拡大への一見
(6) A mechanism for introducing processes to one another, that
is, for superimposing more general communication paths upon
the process hierarchy. 10b6
(6) 導入のためのメカニズムはお互いに処理されます、すなわち、プロセス階層構造の、より一般的な通信路を重ねるために。 10b6
These and other extensions can all find a place in the open-ended protocol layer of Figure D-1. The particular extensions explored in [19] are offered not as dogma but rather as a means of suggesting the possibilities and stimulating further research. 10c
これらと他の拡張子はすべて、図D-1の制限のないプロトコル層の中で場所を見つけることができます。 教義として提供するのではなく、むしろ可能性とさらなる刺激的な研究を示す手段として[19]で調査された特定の拡大を提供します。 10c
-23-
-23-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
References
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング参照のためのハイレベルのフレームワークあたり51 34263NCC76
REFERENCES 11
参照11
1. Kahn, R. E., "Resource-Sharing Computer Communications
Networks," Proceedings of the IEEE, Vol. 60, No. 11, pp.
1397-1407, November 1972. 11a
1. カーン、R.E.、「リソース・シェアリングコンピュータ通信網」、IEEE、Vol.60、No.11、ページのProceedings 1397-1407と、1972年11月。 11a
2. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B.,
"Function-oriented Protocols for the ARPA Computer Network,"
AFIPS Proceedings, Spring Joint Computer Conference, Vol. 40,
pp. 271-279, 1972. 11b
2. クロッカー、S.D.、Heafner、J.F.、メトカルフェ、R.M.、ポステル、J.B.、「アルパコンピュータネットワークのための機能指向のプロトコル」、AFIPS Proceedings、春季計算機学会合同会議、Vol.40、ページ 271-279, 1972. 11b
3. Carr, C. S., Crocker, S. D., Cerf, V. G., "Host-Host
Communication Protocol in the ARPA Network," AFIPS Proceedings,
Spring Joint Computer Conference, Vol. 36, pp. 589-597, 1970. 11c
3. カー、C.S.、クロッカー、S.D.、サーフ、V.G.、「アーパネットのホスト兼ホスト通信プロトコル」、AFIPS Proceedings、春季計算機学会合同会議、Vol.36、ページ 589-597, 1970. 11c
4. Mc Kenzie, A. A., Host/Host Protocol for the ARPA Network, Bolt
Beranek and Newman Inc., Cambridge, Massachusetts, January 1972
(SRI-ARC Catalog Item 8246). 11d
4. mc Kenzie(A.A.)はアーパネットとボルトBeranekとニューマン株式会社(ケンブリッジ(マサチューセッツ)1972(様アークカタログ項目8246)年1月)のためにプロトコルをホスティングするか、またはホスティングします。 11d
5. Walden, D. C., "A System for Interprocess Communication in a
Resource Sharing Computer Network," Communications of the ACM,
Vol. 15, No. 4, pp. 221-230, April 1972. 11e
5. ウォルデン、D.C.、「リソース・シェアリングコンピュータネットワークのプロセス間通信のシステム」、ACM、Vol.15、No.4、ページのCommunications 221-230と、1972年4月。 11e
6. Cerf, V. G., Kahn, R. E., "A Protocol for Packet Network
Intercommunication," IEEE Transactions on Communications, Vol.
Com-22, No. 5, pp. 637-648, May 1974. 11f
6. サーフ、V.G.、カーン、R.E.、「パケット網相互通信のためのプロトコル」、Communications、Vol.Com-22、No.5、ページのIEEE Transactions 637-648と、1974年5月。 11f
7. Thomas, R. H., "A Resource-Sharing Executive for the ARPANET,"
AFIPS Proceedings, National Computer Conference, Vol. 42, pp.
155-163, 1973. 11g
7. トーマス、R.H.、「アルパネットのためのリソース・シェアリング幹部社員」、AFIPS Proceedings、Nationalコンピュータコンファレンス、Vol.42、ページ 155-163, 1973. 11g
8. TELNET Protocol Specification, Stanford Research Institute,
Menlo Park, California, August 1973 (SRI-ARC Catalog Item
18639). 11h
8. telnetプロトコル仕様、スタンフォード研究所、メンローパーク(カリフォルニア)1973(様アークカタログ項目18639)年8月。 11h
9. Engelbart, D. C., Watson, R. W., Norton, J. C., "The Augmented
Knowledge Workshop," AFIPS Proceedings, National Computer
Conference, Vol. 42, pp. 9-21, 1973. 11i
9. Engelbart、D.C.、ワトソン、R.W.、ノートン、J.C.、「増大している知識ワークショップ」、AFIPS Proceedings、Nationalコンピュータコンファレンス、Vol.42、ページ 9-21, 1973. 11i
10. Engelbart, D. C., English, W. K., "A Research Center for
Augmenting Human Intellect," AFIPS Proceedings, Fall Joint
Computer Conference, Vol. 33, pp. 395-410, 1968. 11j
10. Engelbart、D.C.、英語、W.K.、「人間の知力を増大させるためのリサーチセンター」、AFIPS Proceedings、フォール・ジョイント・コンピュータ協議会、Vol.33、ページ 395-410, 1968. 11j
11. Irby, C. H., Dornbush, C. F., Victor, K. E., Wallace, D. C., "A
Command Meta Language for NLS," Final Report, Contract
11. イルビー、C.H.、Dornbush、C.F.、ビクタ、K.E.、ウォレス、D.C.、「NLSのためのコマンドメタ言語」、最終報告書は契約します。
-24-
-24-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
References
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース・シェアリング参照のためのハイレベルのフレームワークあたり51 34263NCC76
RADC-TR-75-304, SRI Project 1868, Stanford Research Institute,
Menlo Park, California, December, 1975. 11k
RADC-TR-75-304、様のプロジェクト1868、スタンフォード研究所、メンローパーク(カリフォルニア)1975年12月。 11k
12. Neigus, N. J., File Transfer Protocol, ARPA Network Working
Group Request for Comments 542, Bolt Beranek and Newman Inc.,
Cambridge, Massachusetts, July 1973 (SRI-ARC Catalog Item
17759). 11l
12. Neigus、N.J.、ファイル転送プロトコル、コメント542を求めるアーパネットワーキンググループ要求はBeranekとニューマン株式会社(ケンブリッジ(マサチューセッツ)1973(様アークカタログ項目17759)年7月)をボルトで締めます。 11l
13. Bressler, R. D., Guida, R., Mc Kenzie, A. A., Remote Job Entry
Protocol, ARPA Network Working Group Request for Comments 360,
Dynamic Modeling Group, Massachusetts Institute of Technology,
Cambridge, Massachusetts, (undated) (SRI-ARC Catalog Item
12112). 11m
13. Bressler、R.D.、Guida、R.、mc Kenzie、A.A.、リモートジョブエントリプロトコル、コメント360を求めるアーパネットワーキンググループ要求、ダイナミックなモデルは分類されて、マサチューセッツ工科大学、ケンブリッジはマサチューセッツです、(日付のない。)です(様アークカタログ項目12112)。 11m
14. 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). 11n
14. ワトソン、R.W.、リソース・シェアリング、アーパネット作業部会を容易にするシステム設計に関するいくつかの考えが1973年11月20日(様アークカタログ項目20391)をコメント592、増大リサーチセンター、スタンフォード研究所、メンローパーク、カリフォルニアに要求します。 11n
15. White, J. E., DPS-10 Version 2.5 Implementer's Guide,
Augmentation Research Center, Stanford Research Institute, Menlo
Park, California, August 15, 1975 (SRI-ARC Catalog Item 26282). 11o
15. ホワイト、J.E.、2.5Implementerのガイド、増大リサーチセンター、スタンフォード研究所、メンローパーク、1975年8月15日の毎秒壊変数-10Versionカリフォルニア(様アークカタログ項目26282)。 11o
16. 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). 11p
16. ホワイト、J.E.、毎秒壊変数-10バージョン2.5プログラマーズガイド、増大リサーチセンター、スタンフォード研究所、メンローパーク、1975年8月13日のカリフォルニア(様アークカタログ項目26271)。 11p
17. 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). 11q
17. ホワイト、J.E.、毎秒壊変数-10バージョン2.5ソースコード、増大リサーチセンター、スタンフォード研究所、メンローパーク、1975年8月13日のカリフォルニア(様アークカタログ項目26267)。 11q
18. 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. 11r
18. Bobrow、D.G.、Burchfiel、J.D.、マーフィー、D.L.、トムリンスン、R.S.、「TENEX、PDP-10のための呼び出されたタイムシェアリングシステム」Communications、ACM、Vol.15、No.3、ページ 135-143と、1972年3月。 11r
19. White, J. E., "Elements of a Distributed Programming System,"
Submitted for publication in the Journal of Computer Languages,
1976. 11s
19. ホワイト、J.E.、「分配されたプログラミング・システムのElements」、コンピュータLanguages、1976年のJournalでの公表のためのSubmitted。 11年代
-25-
-25-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NCC 76 A High-Level Framework for Network-Based Resource Sharing
Figure List
NWG/RFC#707JEW14 1月の76 19: ネットワークベースのリソース共有のためのハイレベルのフレームワークあたりNCC76が計算する51 34263は記載します。
FIGURE LIST 12
図リスト12
Figure 1. Interfacing a remote terminal to a local time-sharing
system via the TELNET Protocol. 12a
図1。 TELNETプロトコルで現地時間の共有しているシステムに遠隔端末を接続します。 12a
Figure 2. Interfacing distant applications programs via their
run-time environments. 12b
図2。 彼らのランタイム環境でよそよそしいアプリケーションプログラムを連結します。 12b
Figure D-1. Software and protocol layers comprising a process
within the distributed programming system. 12c
図D-1。 分配されたプログラミング・システムの中にプロセスを含むソフトウェアとプロトコル層。 12c
-26-
-26-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NWG/RFC#707ユダヤ人14 1月の76 19: 51 34263
-27-
-27-
NWG/RFC# 707 JEW 14-JAN-76 19:51 34263
NWG/RFC#707ユダヤ人14 1月の76 19: 51 34263
A High-Level Framework for Network-Based Resource Sharing
ネットワークベースのリソース・シェアリングのためのハイレベルのフレームワーク
23-DEC-75
23 12月の75
James E. White
Augmentation Research Center
ジェームスE.ホワイト増大リサーチセンター
Stanford Research Institute
Menlo Park, California 94025
スタンフォード研究所メンローパーク、カリフォルニア 94025
(415) 326-6200 x2960
(415)326-6200x2960
This paper proposes a high-level, application-independent
protocol and software framework that would extend the local
programming environment to embrace modules in other computers
within a resource sharing computer network, and thereby
facilitate the construction of distributed systems and encourage
the sharing of resources.
この論文はリソース・シェアリングコンピュータネットワークの中で他のコンピュータでモジュールを受け入れて、その結果、分散システムの工事を容易にして、リソースの共有を奨励するために地方のプログラミング環境を広げるハイレベルの、そして、アプリケーションから独立しているプロトコルとソフトウェアフレームワークを提案します。
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 has been submitted for publication in the
Proceedings of the 1976 National Computer Conference.
1976年のNationalコンピュータコンファレンスのProceedingsでの公表のためにこの論文を提出しました。
一覧
スポンサーリンク
