rfc684.txt

RFC 的详细文档！

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.

     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



     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.

       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.

       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.

       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



    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.

       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.

       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.

       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.

       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



    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.

       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?

       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.

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



level.