RFC684 日本語訳

Network Working Group
RFC #684
NIC #32252
April 15,1975

ネットワークワーキンググループRFC#684NIC#32252 1975年4月15日

    A Commentary on Procedure Calling as a Network Protocol

ネットワーク・プロトコルとしての手順の呼ぶことの論評

                        Richard Schantz

リチャードSchantz

                           BBN-TENEX

BBN-TENEX

Preface_______

序文_______

This RFC is being issued as a first step in an attempt to  stimulate
a dialog on some issues in designing a distributed computing system.
In particular, it considers the approach taken in a design set forth
in  RFC #674, commonly known as the "Procedure Call Protocol" (PCP).
In the present document, the concentration is on what we believe  to
be the shortcomings of such a design approach.

いくつかで対話を刺激する試みにおける第一歩が設計で分散コンピューティングシステムを支給するとき、このRFCは発行されています。 特に、それは、デザインで取られたアプローチが「手順呼び出しプロトコル」(PCP)として一般的に知られているRFC#674で旅に出たと考えます。 現在のドキュメントには、集中が私たちがそのような設計手法の短所であると信じていることにあります。

Note at the outset that this is not the first time we are  providing
a critical commentary on PCP.  During the earlier PCP design stages,
we met with the PCP designers for  a  brief  period,  and  suggested
several  changes,  many  of  which became part of PCP Version 2.  We
hasten to add, however, that the nature of  those  suggestions  stem
from  an entirely different point of view than those presented here.
Our original suggestions, and also some subsequent ones, were mainly
addressing  details  of implementation.  In this note the concern is
more with the concepts underlying the PCP design than with  the  PCP
implementation.

1回目でないことの間の着手のときに、私たちがPCPの批判的な論評を提供していることに注意してください。 以前のPCP設計段階の間、私たちは、簡潔な期間、PCPデザイナーに会って、数回の変化を勧めました。その多くがPCPバージョン2の一部になりました。 しかしながら、ここに提示されたものよりそれらの提案の本質が完全に異なった観点によると取り急ぎ言い足します。 私たちのオリジナルの提案、およびいくつかのその後のものも実現の詳細を主に記述していました。 この注意には、PCP実現より概念がPCPデザインの基礎となっていて、関心があります。

This note is being  distributed  because  we  feel  that  it  raises
certain  issues  which  have not been adequately addressed yet.  The
PCP designers are to  be  congratulated  for  providing  a  detailed
written  description  of  their  ideas,  thereby  creating a natural
starting  point  for  a  discussion  of  distributed  system  design
concepts.  It is the intent of this note to stimulate an interaction
among individuals involved with distributed computing,  which  could
perhaps  result in systems whose designs don't preclude their use in
projects  other  than  the  one  for  which  they  were   originally
conceived.

私たちが、それが適切にまだ記述されていないある問題を提起すると感じるので、この注意は分配されています。 PCPデザイナーは彼らの考えの詳細な書面による明細を提供するために祝われることになっています、その結果、分散システム設計思想の議論のための本来の出発点を作成します。 恐らく、デザインがそれらが元々発想されたもの以外のプロジェクトにおける彼らの使用を排除しないシステムをもたらすことができた分散コンピューティングにかかわる個人の中で相互作用を刺激するのは、この注意の意図です。

The ideas  expressed  in  this  RFC  have  benefited  from  numerous
discussions with Bob Thomas, BBN-TENEX, who shares the point of view
taken.

          A COMMENTARY on PROCEDURE CALLING         Page   2

このRFCに表された考えはボブ・トーマス、取られた観点を共有するBBN-TENEXとの頻繁な議論の利益を得ました。 手順呼ぶ2ページにおける論評

Introduction____________

序論____________

     While the Procedure Call Protocol (PCP) and its use within  the
National  Software  Works (NSW) context attacks many of the problems
associated with integrating independent computing systems to  handle
a  distributed  computation,  it  is  our  feeling  that  its design
contains flaws which should prevent its widespread use, and  in  our
view,  limit  its overall utility.  We are not voicing our objection
to the use of PCP, in its current  definition,  as  the  base  level
implementation  vehicle for the NSW project.  It is already too late
for any such objection, and PCP may, in fact, be very effective  for
the  NSW  implementation,  since they are proceeding in parallel and
have probably influenced each other.   Rather,  we  are  voicing  an
objection  to  the  "PCP philosophy", in the hope of preventing this
type of protocol from becoming the  de-facto  network  standard  for
distributed  computation,  and in the hope of influencing the future
direction of this and similar efforts.

Procedure Callプロトコル(PCP)とNational Software Works(NSW)文脈の中のその使用が分散型計算方式を扱うために独立しているコンピューティング・システムを統合すると関連している問題の多くを攻撃している間、それは私たちが、デザインが普及使用、および私たちの視点、限界におけるその総合的なユーティリティを防ぐべきである欠点を含むと感じることです。 私たちはPCPの使用への異論を声に出していません、現在の定義で、NSWプロジェクトのための基準面実現手段として。 既にどんなそのような異論にも遅過ぎます、そして、NSW実現には、事実上、PCPは非常に効果的であるかもしれません、彼らが平行で続いていて、たぶん互いに影響を及ぼしたので。 むしろ、私たちは「PCP哲学」への異論を声に出しています、分散型計算方式、これと同様の努力の今後の指示に影響を及ぼすことおよびを希望してこのタイプのプロトコルがデファクトネットワーク規格になるのを防ぐことを希望して。

     Some of the objectionable aspects of PCP, it can be argued, are
differences  of  individual  preference, and philosophers have often
indicated that you cannot argue about  tastes.   We  have  tried  to
avoid  such  arguments in this document.  Rather, we consider PCP in
light  of  our  experience  in   developing   distributed   systems.
Considered  in  this  way,  we  feel  that  PCP  and  its underlying
philosophy have flaws which  make  it  inappropriate  as  a  general
purpose protocol and virtual programming system for the construction
of distributed software systems.  It is  our  opinion  that  PCP  is
probably  complete  in  the  sense that one can probably do anything
that is required using its primitives.  A key  issue  then,  is  not
whether this function or that function can be supported.  Rather, to
us an important question is how easy it is to do  the  things  which
experience has indicated are important to distributed computing.  In
addition, a programming discipline dedicated to network applications
should  pay  particular  attention  to  coercing its users away from
actions which systems programming in general and network programming
in particular have shown to be pitfalls in system implementation.

PCPの好ましくない局面のいくつかがそれを主張できる個々の好みの違いです、そして、哲学者はしばしばあなたが味について議論できないのを示しました。 私たちは本書ではそのような議論を避けようとしました。 むしろ、私たちは展開している分散システムの私たちの経験の観点からPCPを考えます。このように考えられて、PCPとその基本的な哲学には分配されたソフトウェア・システムそれの工事の汎用のプロトコルと仮想のプログラミング・システムがPCPがたぶん1つが何かたぶん基関数を使用することで必要であることができるという意味で完全であるという私たちの意見であるのでそれを不適当にする欠点があると感じます。 そして主要な問題はこの機能かその機能をサポートできるかどうかということではありません。 むしろ、私たちにとって、重要な質問はどの経験が分散コンピューティングに重要であることが示されたことをするのがどれくらい簡単であるかということです。 さらに、ネットワーク応用に捧げられたプログラミング規律は一般に、システム・プログラミングと特にネットワーク・プログラミングがシステムの実現における落とし穴になるように示した動作からユーザを強制することに関する特別の注意を支払うべきです。

A Point of View_ _____ __ ____

観点______ __ ____

     At the outset, we fully support the aspects of the  PCP  design
effort  that  have  gone  into  systematizing  the  interaction  and
agreements between distributed  elements  to  support  inter-machine
computing.   This  includes  the  definition of the various types of
replies, the  standardization  of  the  data  structure  format  for
inter-machine  exchange,  and  the process creation primitives which
extend the machine boundaries.  Such notions are basic and  must  be
part  of any distributed system definition.  Our main concern is not
with these efforts.

          A COMMENTARY on PROCEDURE CALLING         Page   3

最初に、私たちは相互マシンコンピューティングを支持するために分散要素の間の相互作用と協定を体系化するために入ったPCPデザインの努力の局面を完全に支持します。 これは様々なタイプの回答の定義、相互マシン交換のためのデータ構造形式の標準化、およびマシン境界を広げる過程創造基関数を含んでいます。 そのような概念は、基本的であり、どんな分散システム定義の一部であるに違いありません。 私たちの主な関心事がこれらの努力と共にありません。 手順呼ぶ3ページにおける論評

     Rather, we take exception to PCP's underlying premise: that the
procedure  calling  discipline  is  the  starting point for building
multi-computer systems.  This premise leads to a model which  has  a
central  point  for the entire algorithm control, rather than a more
natural (in network situations) distributed control accomplished  by
cooperating   independent   entities   interacting   through  common
communication paths.  While the procedure call may be an appropriate
basis  for  certain  applications,  we  believe  that it can neither
directly  nor  accurately  model  the   interactions   and   control
structures that occur in many distributed multi-computer systems.

むしろ、私たちはPCPの基本的な前提に反対します: 規律と呼ぶ手順がビルマルチコンピュータ・システムこの前提のための出発点であることは協力することによって実行されたより当然(ネットワーク状況における)の分散制御よりむしろ全体のアルゴリズムコントロールのために一般的な通信路を通って相互作用する独立している実体を主要なポイント持っているモデルにつながります。 手順呼び出しはあるアプリケーションの適切な基礎であるかもしれませんが、私たちは、それがどちらも直接、正確に多くの分配されたマルチコンピュータ・システムに現れる相互作用と制御構造をモデル化できると信じています。

     Much of what follows may seem to be a pedagogic  argument,  and
PCP supporters may take the position of "who cares what you call it,
its doing the same thing".  Our reply is that it is  very  important
to achieve a clear and concise model of distributed computation, and
while the PCP  model  does  not  require  "poor  implementation"  of
distributed  systems, neither does it make "good implementation" any
easier, nor does it prohibit ill-advised programming  practices.   A
model  stressing the dynamic interconnection of somewhat independent
computing  entities,  we  feel,  adheres  more  to  the  notions  of
defensive  programming,  which  we  have  found to be fundamental to
building usable multi-machine implementations.

どんな尾行の多くが教育学の議論になるように見えるかもしれないか、そして、PCP支持者が立場を取るかもしれない、「だれ、いわゆるそれについて気にかけて、同じことをするか、」 私たちの回答はPCPモデルが分散システムの「不十分な実現」を必要としませんが、それが分散型計算方式の明確で簡潔なモデルを達成するために非常に重要であるということです、そして、どちらも、「良い実現」を少しもより簡単にしません、そして、それはあさはかなプログラミング練習を禁止しません。 私たちは、いくらか独立しているコンピューティング実体のダイナミックなインタコネクトを強調するモデルが私たちが使用可能なマルチマシン実現を組み込むのに基本的になるように見つけた防衛的なプログラミングの概念をより多く固く守ると感じます。

     The rest of this RFC discusses what we feel to be some  of  the
shortcomings of a procedure call protocol.

このRFCの残りは私たちが手順呼び出しプロトコルの短所のいくつかになるように感じるものについて議論します。

Limitations of Procedure Calling Across Machines___________ __ _________ _______ ______ ________

マシンの向こう側の手順の呼ぶことの制限___________ __ _________ _______ ______ ________

     First and foremost, it is our contention that procedure calling
should  not  be  the  basis for multi-machine interactions.  We feel
that a request and reply protocol along  with  suitably  manipulated
communication paths between processes forms a model better suited to
the situation  in  which  the  network  places  us.   In  a  network
environment  one has autonomous computing entities which have agreed
on their cooperation, rather than a master process forcing execution
of a certain body of code to fulfill its computing needs.  In such a
configuration, actions required of a process are  best  accommodated
indirectly (by request) rather than directly (by procedure call), in
order to maintain the integrity of the constituent processes.

まず第一に、それは手順の呼ぶのがマルチマシン相互作用の基礎であるべきでないという私たちの主張です。 私たちは、過程の間の適当に操られた通信路に伴う要求と回答プロトコルがネットワークが私たちを任命する状況に合うほうがよいモデルを形成すると感じます。 ネットワークでは、環境1はコードのあるボディーの実行がコンピューティングニーズをやむを得ず実現させるマスターの過程よりむしろ彼らの協力に同意した自治のコンピューティング実体を持っています。 直接である(手順呼び出しで)というよりむしろ間接的(要求で)に過程について必要である動作をそのような構成では、設備するのが最も良い、構成している過程の保全を維持するために。

     Procedure calling is most  often  a  very  primitive  operation
whose   implementation   often   requires   only  a  single  machine
instruction.  In addition, it is usually true that procedure calling
is  usually  not  within  the  domain of the operating system.  [The
Multics intersegment procedure  calling  mechanism  may  present  an
exception  to  this,  until  linkage is complete.  In the remote PCP
case, however, linkage  can  never  be  complete  in  the  sense  of
supporting  a  fast transfer of control between modules].  Processes
and communication paths between processes, however,  are  undeniably
operating   system   constructs.   In  an  environment  where  local
procedure calling was "cheap", it would be ill-advised to  blur  the

          A COMMENTARY on PROCEDURE CALLING         Page   4

手順の呼ぶのはたいてい実現がしばしば単一マシン指示だけを必要とする非常に原始の操作です。 さらに、通常、通常オペレーティングシステムのいずれのドメインの中にも手順の呼ぶことがないのは、本当です。 [リンケージが完全になるまで、Multics intersegment手順呼ぶメカニズムはこれへの例外を提示するかもしれません。 しかしながら、リモートPCP場合では、リンケージはモジュールの間のコントロールの速い転送を支持するという意味で完全であるはずがありません。]. しかしながら、過程の間の過程と通信路は明白にオペレーティングシステム構造物です。 地方の手順の呼ぶのが「安かった」環境で、PROCEDURE CALLING4ページでA COMMENTARYをぼかすのはあさはかでしょう。

distinction  between  a local (inexpensive in time and effort) and a
remote procedure call, which obviously  requires  a  great  deal  of
effort  by  the "PCP system", if not by the PCP user.  It also seems
to  be  the  case  that  the  cost  of  blurring  the   local/remote
distinction  at  the  procedure call level will be found in the more
frequent use of a less efficient local procedure calling  mechanism.
Interprocess communication, on the other hand, (at least with regard
to stream or  message  oriented  channels  and  not  just  interrupt
signals)   is  generally  regarded  as  having  a  significant  cost
associated with it.   Message  sending  is  always  an  interprocess
action,  and  requires  system intervention always.  There is not as
substantial a difference between the IPC of local processes and  the
IPC  of  remote  processes,  as  between  local and remote procedure
calling.  PCP is suggestive of a model in which processes exist that
span machine boundaries to provide inter-machine subroutine calling.
Yet the PCP documentation has not advocated the notion of a  process
that  spans  machine  boundaries,  and  rightfully  so  since such a
creation would cause innumerable problems.  Since procedure  calling
is more suitable as an intra-process notion, it seems to be a better
idea to take the interprocess communication framework and extend  it
to  have  a uniform interpretation locally and remotely, rather than
to extend the procedure calling model.  It is  also  our  contention
that  a  model  which relies on procedure calling for its basis does
not take into account the special nature of the network environment,
and  that  such  an  environment  can  be more suitably handled in a
message passing model.  Furthermore, we feel that programming  as  a
whole,  even  purely  local computing, will benefit from paying more
attention to such areas as reliability and  robustness,  which  have
been  brought to the forefront through experience with an oftentimes
unreliable network and  collection  of  hosts.   An  IPC  model,  by
emphasizing  the  connections  between  disjoint processes, seems to
reinforce the idea that distributed  computing  is  accomplished  by
joining  separate entities, and that defensive programming and error
handling techniques are appropriate.  Since PCP is,  we  think,  for
distributed  system  builders,  and  not  for  the end user (e.g. an
RSEXEC user), avoiding  the  network,  interconnection  issues,  and
relative  costs, may be counter-productive if the goal is to achieve
usable network systems.

ローカル(時間と努力で安価な)と遠隔手続き呼び出しの区別。(明らかに、それは、「PCPシステム」、またはPCPユーザによる大きな努力を必要とします)。 また、それは手順呼び出しレベルで地方の、または、リモートな区別をぼかす費用がそれほど効率的でないローカルの手順呼ぶメカニズムの、より頻繁な使用で見つけられるケースであるように思えます。 それに関連している多大な費用を持っているとき、他方では、一般に、プロセス間通信は見なされます(割り込み信号だけではなく、少なくとも流れかメッセージ指向のチャンネルに関して)。 メッセージ送信は、いつもインタプロセス動作であり、いつもシステム介入を必要とします。 ローカルの過程のIPCとリモート過程のIPCの間には、同じくらい実質的な違いがありません、地方の、そして、リモートな手順の呼ぶように。 PCPは相互マシンサブルーチンの呼ぶことを提供するためにマシン境界にかかる過程が存在するモデルが思わせ振りです。 しかし、PCPドキュメンテーションは、マシン境界にかかる過程について概念を支持して、そのようなもの以来創造が無数の問題を引き起こすように、正しく支持していませんでした。手順の呼ぶのが手順の呼んでいるモデルを広げるよりイントラ過程概念として適当であるので、同一解釈を局所的に、そして離れて持つためにプロセス間通信枠組みを取って、それを広げるのが、より良い考えであるようにむしろ思えます。 また、それは基礎を求める手順を当てにするモデルがネットワーク環境の特別な本質を考慮に入れないで、メッセージ・パッシングモデルで、より適当にそのような環境は扱うことができるという私たちの主張です。 その上、私たちは、全体でプログラミング(純粋にローカルのコンピューティングさえ)が最先端にもたらされた信頼性のような領域により多く注意を向けて、丈夫さからホストのしばしば頼り無いネットワークと収集の経験で利益を得ると感じます。 ばらばらになることの過程の間の関係を強調することによって、IPCモデルは、分散コンピューティングが別々の実体を接合することによって達成されて、防衛的なプログラミングとエラー処理のテクニックが適切であるという考えを補強するように思えます。 以来、私たちは、エンドユーザ(例えば、RSEXECユーザ)のために思うのではなく、分散システム建築業者のためにPCPがネットワークを避けることであると思って、インタコネクト問題、および相対的なコストは目標が使用可能なネットワーク・システムを達成することであるならカウンタ生産的であるかもしれません。

     In a similar vein, the entire notion of inter-machine procedure
calling  underlies  a model which in effect has extended the address
space of a single process.  That is, there  is  a  single  locus  of
algorithm   control   (although   perhaps  not  a  single  locus  of
execution).  While this model may well serve the needs of a  "local"
computation  where  the  parts  are  strongly  bound  together,  our
experience in building working distributed  systems  has  shown  the
utility of a model which has multiple loci of control and execution.
In such a model, it is through agreements on the method and type  of
information  interchange  and synchronization, that a computation is
carried out, rather than at the  singular  direction  of  a  central
entity.   In  a model that has distributed control and execution, we
feel a process will be in a better position to naturally  cope  with
the many vagaries that necessarily arise in a network environment.

          A COMMENTARY on PROCEDURE CALLING         Page   5

似たような仕方で、相互マシン手順の呼ぶことの全体の概念は事実上、ただ一つの過程のアドレス空間を広げたモデルの基礎となります。 すなわち、アルゴリズムコントロールのただ一つの場所があります(恐らく実行のただ一つの場所ではありませんが)。 部品が強く一緒に縛られるところでこのモデルはたぶん「地方」の計算の必要性に役立つでしょうが、働く分散システムを築き上げる私たちの経験は、どれにコントロールと実行の複数の座があるかをモデルに関するユーティリティに示しました。 そのようなモデルには、中央の実体のまれな指示に基づきというよりむしろ計算が行われるという方法、情報の種類置き換え、および同期の協定でそれがあります。 分散制御と実行を持っているモデルでは、私たちは、過程が自然に必ずネットワーク環境で起こる多くの気まぐれに対処するより良い立場にあると感じます。 手順呼ぶ5ページにおける論評

     The  unmistakable  trend  in  systems  programming  is   toward
inviolable    (protected)    process    structures   with   external
synchronization as a means of coping with  complex  debugging  tasks
and  the  difficulty of making system changes.  This trend is better
supported, we feel, by a message passing rather  than  a  procedural
model of computation.  Furthermore, we feel that network programming
techniques should be applied to local computation, not the other way
around.

システム・プログラミングにおける紛れもない傾向は複雑なデバッグタスクに対処する手段とシステム変更を作るという困難として外部同期がある不可侵(保護される)の過程構造に向かっています。 私たちは、この傾向が支持されるほうがよいと計算の手続き上のモデルよりむしろメッセージ・パッシングで感じます。 その上、私たちは、ネットワークプログラミング技術が逆ではなく、地方の計算に適用されるべきであると感じます。

Some Particulars____ ___________

いくつかの子細____ ___________

     In the following list, we try to be more specific with  respect
to  particular situations where we think the PCP concept may be weak
as the basis for a network programming system.  For  some  of  these
examples to be meaningful, the reader should be fairly familiar with
the PCP documents issued as RFC 674.

以下のリストでは、私たちは私たちがPCP概念がネットワークプログラミング・システムの基礎として弱いかもしれないと思うところでは、特定の状況に関して、より特有になろうとします。 これらの例のいくつかが重要であるように、読者はRFC674として発行するPCPドキュメントにかなり詳しいはずです。

       1.  Recovery  from  component  malfunction  may  be  very
    difficult  to  handle  by  a process that is not the central
    control (i.e.  a  process  which  is  being  manipulated  by
    having  its  procedures  executed).   Is the situation where
    there is network trouble, for example, to be  modeled  by  a
    forced procedure call to some error recovery routine?  It is
    precisely such situations where distributed  control  serves
    as  a  better  model.   Consider  the  act of introducing an
    inferior to another acquaintance and then supplying the  new
    handle  as a parameter of a subsequent procedure call in the
    inferior.  The inferior's blind  use  of  the  parameter  to
    interact with the other process illustrates the manipulative
    aspects of a superior.  The inferior never really  is  aware
    of  a new communication path to a new process.  The inferior
    environment (as maintained by the  PCP  "system")  has  been
    changed  by the superior, with no active notification of the
    inferior.  Certainly this makes user  coded  error  recovery
    somewhat awkward.

1. コンポーネント不調からの回復は集中管理(すなわち、手順を実行させることによって操られている過程)でない工程で扱うのが非常に難しいかもしれません。 状況が例えば無理矢理の手順呼び出しで何らかのエラー回復ルーチンにモデル化されるためにネットワーク問題があるところにありますか? それは、より良いモデルのように正確に分散制御が役立つ状況です。 目下のその後の手順呼び出しのパラメタとして別の知人に目下を紹介して、次に、新しいハンドルを提供する行為を考えてください。 もう片方の過程で相互作用させるパラメタの目下の盲目の使用は上司の巧みに扱っている局面を例証します。 目下は本当に新しい通信路をニュープロセスに決して意識していません。 劣った環境(PCP「システム」によって維持されるように)は上司によって変えられました、目下のどんな活発な通知でも、そうしません。 確かに、これで、ユーザのコード化されたエラー回復はいくらか無器用になります。

       2.  Such process manipulation may at  times  violate  the
    principles  of  modular programming.  In this vein, it seems
    beneficial to be able to debug separately the  pieces  of  a
    computation  and then worry only about their synchronization
    to achieve a totally  debugged  system.   With  PCP  in  its
    fullest sense, the danger of error propagation seems greater
    because of the power of a process to cause execution  of  an
    arbitrary  procedure  and  to  read/write remote data stores
    without the active participation of the remote process.

2. そのような過程操作は時には、モジュラプログラミングの原則に違反するかもしれません。 この調子で、完全にデバッグされたシステムを達成するのが別々に計算の断片をデバッグして、次に、彼らの同期だけを心配できるように有益に思えます。 最もふくよかな意味におけるPCPと共に、誤り伝播という危険はリモート過程の積極的な参加なしで遠く離れたデータ・ストアを任意の手順の実行を引き起こして、読むか、または書く過程のパワーのために、よりすばらしく見えます。

       3.  Can we assume a proper initialization sequence if our
    procedures   are  called  remotely?   Must  every  procedure
    contain the code to check  for  the  propriety  and  correct
    sequencing of the call? A model in which each remote process
    is  an  active  computing  element  seems  better  able   to

          A COMMENTARY on PROCEDURE CALLING         Page   6

3. 私たちの手順が離れて呼ばれるなら、私たちは、適切な初期化が系列であると思うことができますか? あらゆる手順が礼節がないかどうかチェックして、呼び出しの配列を修正するコードを含まなければなりませんか? それぞれのリモート過程が活性コンピューティング要素であるモデルはPROCEDURE CALLING6ページでA COMMENTARYによりよくできるように思えます。

    conveniently apply protective standards to the code and data
    it encompasses.

好都合なことにそれが包含するコードとデータに保護的な規格を適用してください。

       4.  PCP doesn't model long term parallel  activity  in  a
    convenient   fashion,  as  is  required  to  handle  various
    asynchronous producer/consumer process  relationships.   The
    synchronization  is  geared  more  to  a one-to-one call and
    return, rather than to the asynchronous nature and  multiple
    returns  for  a single request, as exhibited by many network
    services.  In addition, low priority, preemptable background
    tasks  are  hard  (impossible?) to model in a procedure call
    environment.

4. PCPは、様々な非同期なプロデューサー/消費者プロセス関係を扱うためにそのままな便利なファッションで必要な状態で長期並行活動をモデル化しません。 同期は1〜1つの呼び出しとただ一つの要求のための非同期的性質と複数のリターンにというよりむしろリターンにさらに連動します、多くのネットワーク・サービスで示されるように。 追加、低い優先度では、先取り可能バックグラウンドタスクは手順呼び出し環境でモデル化しにくいです(不可能な?)。

       5.  Communication  paths  are  not  treated  as  abstract
    objects  which are independent from the actual entities they
    connect, and hence they cannot be utilized  in  some  useful
    ways (e.g. to carry non PCP messages).  Also with respect to
    treating communication paths as objects, there is no concept
    of  passing  a  communication  path  to  an  inferior (or an
    acquaintance), without having to create a  new  "connection"
    (whether  or  not  this turns out to be a physical channel).
    The ability to pass communication paths is often  useful  in
    subcontracting  requests  to inferior processes.  To do this
    within PCP requires the cooperation of the  calling  process
    (i.e. to  use  the new connection handle), which again seems
    to  violate  the  concepts  of  modular  programming.    The
    alternative  approach  in  PCP is to have the superior relay
    the subsequent communications to its created  inferior,  but
    the  effort involved would probably prohibit the use of this
    technique for subcontracting.

5. それらが接続する実在物から独立している抽象的なオブジェクトとして通信路を扱いません、そして、したがって、いくつかの役に立つ方法(例えば非PCPメッセージを伝える)でそれらを利用できません。 また、オブジェクトとして通信路を扱うことに関して、目下(または、知人)に通信路を渡す概念が全くありません、新しい「接続」を作成する必要はなくて(これが物理的なチャンネルであると判明するか否かに関係なく)。 通信路を通り過ぎる能力は劣ったプロセスに要求を下請けする際にしばしば役に立ちます。 PCPの中でこれをするのは呼び出しプロセス(すなわち、新しい接続ハンドルを使用する)の協力を必要とします。(再び、呼び出しプロセスはモジュラプログラミングの概念に違反するように思えます)。 PCPの代替的アプローチが上司に作成された目下にその後のコミュニケーションをリレーさせることですが、かかわった取り組みはたぶんこのテクニックの下請けする使用を禁止するでしょう。

       6.  PCP seems too complicated to be used for the type  of
    processing  which  requires  periodic but short (i.e.  a few
    words  exchanged)  interactions.    An   example   of   such
    interactions  is  the  way the TIP uses the TENEX accounting
    servers (see RFC #672).  Furthermore, PCP is  probably  much
    too  complex  for  implementation  on a small host.  In that
    regard, there does not seem to be a definition of what might
    constitute a minimum implementation for a host/process which
    did/could not handle all of what has been developed.

6. PCPは周期的な、しかし、短い(交換されたすなわちいくつかの単語)相互作用を必要とする処理のタイプに使用できないくらい複雑に見えます。 そのような相互作用に関する例はTIPがTENEX会計サーバを使用する(RFC#672を見てください)方法です。 その上、実装には、PCPはたぶん小さいホストに非常に複雑過ぎます。 そのことについては、/をしたホスト/プロセスが開発されたことに関するすべてを扱うことができなかったので何が最小の実装を構成するかもしれないかに関する定義はあるように思えません。

       7.  In the PCP model, it may become awkward  or  resource
    consuming  for  a service program to do such things as queue
    operations for execution at a later time (persistence) or at
    a  more opportune time (priority servicing mechanism).  Such
    implementations may require dummy returns  and  modification
    of   the   controlling   fork  concept,  or  maintenance  of
    processing forks over long periods of inactivity.

7. PCPモデルでは、サービス・プログラムが後で(固執)か、より好都合な時(優先権整備点検メカニズム)に実行のための操作を列に並ばせるようなことをするのは無器用であるかリソース消費になるかもしれません。 そのような実装は長期の不活発に関して制御フォーク概念のダミーのリターンと変更、または処理フォークのメインテナンスを必要とするかもしれません。

       8.  It is not  always  true  that  a  process  connecting
    (splicing)  to  a  service  should  be able to influence the
    service process environment in any direct way.   How  can  a
    service process in PCP prevent a malicious user fom splicing

          A COMMENTARY on PROCEDURE CALLING         Page   7

8. サービスに接続する(継ぎます)プロセスがどんなダイレクト方法でもサービス過程環境に影響を及ぼすはずであることができるのは、いつも本当であるというわけではありません。 PCPのサービス過程は、悪意あるユーザーfomがPROCEDURE CALLING7ページにA COMMENTARYを継ぐのをどうしたら防ぐことができますか?

    to it and then introducing it  to  an  arbitrary  number  of
    processes,  thereby  overflowing  the  table  space  in that
    process.  All of that could  have  been  done  without  ever
    executing  a  single instruction of user written code.  This
    difficulty is a consequence of the PCP notion of having  one
    process  manipulate  the  environment of another without its
    active participation in such actions.

処理して、その結果、それでテーブルスペースからそれと次に、プロセスの特殊活字の数字にそれを紹介するのにはみ出してください。 ユーザの書かれたコードのただ一つの指示を実行しないで、そのすべてをしたかもしれません。 この困難は1つのプロセスにそのような動作への積極的な参加なしで別のものの環境を操らせるというPCP概念の結果です。

       9.   Doesn't  the  fact  that  the  network  PCP  process
    implementation  is so much neater than the TENEX PCP process
    implementation (since  TENEX  doesn't  have  a  general  IPC
    facility)  suggest  that  message  passing and communication
    facilities supported by the "system" provides a sound  basis
    for  multi-process  implementations,  and  that perhaps such
    facilities  should   be   primitively   available   to   the
    distributed system builders who will use PCP?

9. したがって、ネットワークPCPプロセス実装がTENEX PCPプロセス実現よりはるかにきちんとしているという(TENEXには一般的なIPC施設がないので)事実は施設が「システム」でサポートしたメッセージ・パッシングとコミュニケーションがマルチプロセス実現に健全な基礎を提供して、PCPを使用する分散システムビルダーには、恐らく、そのような施設が本来利用可能であるべきであると示唆しませんか?

       10.   There  is  a  question  of  whether   PCP   is   an
    implementation virtual machine (language), or an application
    virtual machine (language).  That is, is PCP intended to  be
    used   to   implement   systems   which  manage  distributed
    resources, or as an end  product  which  makes  the  network
    resources  themselves  easier  to  use  for  the  every day,
    ordinary  programmer  (e.g.   makes   the   network   itself
    transparent  to  users).   One  gets  the  feeling  that the
    designers had both goals, and that neither one is completely
    satisfied.   If  the  former  goal is taken, we believe that
    most of the  complexities  (e.g.   network  trouble,  broken
    connections,   etc.)   and  possibilities  (e.g.   redundant
    implementation,  broadcast   request,   etc.)   of   network
    implementations  are  not  provided for adequately.  In this
    view,  the  NSW  framework  (Works  manager,  FE)   is   the
    distributed  system  that  utilizes  the  PCP implementation
    language.  We do not see how the use of PCP in this  context
    provides   for   either  an  extra-reliable  system  through
    component redundancy,  or  a  persistent  system  which  can
    tolerate  temporary malfunctions.  If one subscribes to this
    view, then it doesn't seem right that the objects  that  run
    under the created system (i.e.  the tools that run under the
    PCP implemented Front End, Works Manager, and  TBH  monitor)
    should  also  be  aware of or use PCP.  If one considers the
    latter goal, that PCP implements a  virtual  machine  to  be
    presented   to   all   programmers  for  making  distributed
    resources easy to use, then it is clear that  PCP  with  its
    manifest  concern  for  object location does not provide for
    the desireable properties of network transparency.

10. PCPが実装仮想計算機であるかどうかに関する質問(言語)、またはアプリケーション仮想計算機(言語)があります。 すなわち、分配されたリソースを管理する道具システム、または、ネットワーク資源自体を毎日、普通にプログラマを使用するのが(例えば、ネットワーク自体をユーザにとって透明にします)より簡単にする最終生産物としてPCPが使用されることを意図しますか? 1つはデザイナーには両方の目標があって、どちらも完全に満足するというわけではないという感じを得ます。 前の目標を取るなら、私たちは、複雑さ(例えば、ネットワーク問題、失意の接続など)の大部分とネットワーク実装の可能性(例えば、余分な実装、放送要求など)が適切に備えられないと信じています。 この視点では、NSWフレームワーク(工場長、FE)はPCP実装言語を利用する分散システムです。 私たちはPCPの使用がコンポーネント冗長、または一時的な不調を許容できる永続的なシステムを通してどうこのような関係においては付加的な高信頼のシステムに備えるかを見ません。 人がこの視点に加入するなら、それはそれをまさしく思えません。またシステム(すなわち、Front Endと、Worksマネージャと、TBHモニターであると実装されたPCPで実行されるツール)も意識しているべきである作成で実行されるか、またはPCPを使用するオブジェクト。 人が後者の目標を考えるなら、そのPCPは分配されたリソースを使用するのを簡単にするようにすべてのプログラマに提示される仮想計算機を実装して、次に、オブジェクト位置に関する明白な心配があるPCPがネットワーク透明の「望-可能」の特性に備えないのは、明確です。

Our conclusion is that procedure  calling  is  not  the  appropriate
basis  for distributed multi-computer systems because it can neither
directly nor accurately model  the  network  environment.   The  PCP
virtual  programming  system may be inadequate for implementing many
distributed  systems  because  the  complexities  and  possibilities
unique to the network environment are not provided for at this basic

          A COMMENTARY on PROCEDURE CALLING         Page   8

私たちの結論はどちらも直接、正確にネットワーク環境をモデル化できるので手順の呼ぶのが分配されたマルチコンピュータ・システムの適切な基礎でないということです。 PCPの仮想のプログラミング・システムはネットワーク環境にユニークな複雑さと可能性がPROCEDURE CALLING8ページにこの基本的なA COMMENTARYに備えられないので多くの分散システムを実装するのに不十分であるかもしれません。

level.


レベル。