rfc684.txt

RFC 的详细文档！






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



    A Commentary on Procedure Calling as a Network Protocol

                        Richard Schantz

                           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.

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.

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.

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



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.

     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.


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



     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.

     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.

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


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.

     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



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