Browse Prior Art Database

Commentary on procedure calling as a network protocol (RFC0684) Disclosure Number: IPCOM000003732D
Original Publication Date: 1975-Apr-15
Included in the Prior Art Database: 2000-Sep-13
Document File: 7 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Schantz: AUTHOR


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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 13% of the total text.

Network Working Group

RFC #684

NIC #32252

April 15,1975

A Commentary on Procedure Calling as a Network Protocol

Richard Schantz



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




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, an...