Commentary on procedure calling as a network protocol (RFC0684)
Original Publication Date: 1975-Apr-15
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
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.
Network Working Group
A Commentary on Procedure Calling as a Network Protocol
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
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
The ideas expressed in this RFC have benefited from numerous
discussions with Bob Thomas, BBN-TENEX, who shares the point of view
A COMMENTARY on PROCEDURE CALLING Page 2
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 influenci...