Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
Network Working GroupRFC #684NIC #32252April 15,1975A Commentary on Procedure Calling as a Network Protocol Richard Schantz BBN-TENEXPreface_______This RFC is being issued as a first step in an attempt to stimulatea dialog on some issues in designing a distributed computing system.In particular, it considers the approach taken in a design set forthin RFC #674, commonly known as the "Procedure Call Protocol" (PCP).In the present document, the concentration is on what we believe tobe the shortcomings of such a design approach.Note at the outset that this is not the first time we are providinga critical commentary on PCP. During the earlier PCP design stages,we met with the PCP designers for a brief period, and suggestedseveral changes, many of which became part of PCP Version 2. Wehasten to add, however, that the nature of those suggestions stemfrom an entirely different point of view than those presented here.Our original suggestions, and also some subsequent ones, were mainlyaddressing details of implementation. In this note the concern ismore with the concepts underlying the PCP design than with the PCPimplementation.This note is being distributed because we feel that it raisescertain issues which have not been adequately addressed yet. ThePCP designers are to be congratulated for providing a detailedwritten description of their ideas, thereby creating a naturalstarting point for a discussion of distributed system designconcepts. It is the intent of this note to stimulate an interactionamong individuals involved with distributed computing, which couldperhaps result in systems whose designs don't preclude their use inprojects other than the one for which they were originallyconceived.The ideas expressed in this RFC have benefited from numerousdiscussions with Bob Thomas, BBN-TENEX, who shares the point of viewtaken.
A COMMENTARY on PROCEDURE CALLING Page 2Introduction____________ While the Procedure Call Protocol (PCP) and its use within theNational Software Works (NSW) context attacks many of the problemsassociated with integrating independent computing systems to handlea distributed computation, it is our feeling that its designcontains flaws which should prevent its widespread use, and in ourview, limit its overall utility. We are not voicing our objectionto the use of PCP, in its current definition, as the base levelimplementation vehicle for the NSW project. It is already too latefor any such objection, and PCP may, in fact, be very effective forthe NSW implementation, since they are proceeding in parallel andhave probably influenced each other. Rather, we are voicing anobjection to the "PCP philosophy", in the hope of preventing thistype of protocol from becoming the de-facto network standard fordistributed computation, and in the hope of influencing the futuredirection of this and similar efforts. Some of the objectionable aspects of PCP, it can be argued, aredifferences of individual preference, and philosophers have oftenindicated that you cannot argue about tastes. We have tried toavoid such arguments in this document. Rather, we consider PCP inlight of our experience in developing distributed systems.Considered in this way, we feel that PCP and its underlyingphilosophy have flaws which make it inappropriate as a generalpurpose protocol and virtual programming system for the constructionof distributed software systems. It is our opinion that PCP isprobably complete in the sense that one can probably do anythingthat is required using its primitives. A key issue then, is notwhether this function or that function can be supported. Rather, tous an important question is how easy it is to do the things whichexperience has indicated are important to distributed computing. Inaddition, a programming discipline dedicated to network applicationsshould pay particular attention to coercing its users away fromactions which systems programming in general and network programmingin particular have shown to be pitfalls in system implementation.A Point of View_ _____ __ ____ At the outset, we fully support the aspects of the PCP designeffort that have gone into systematizing the interaction andagreements between distributed elements to support inter-machinecomputing. This includes the definition of the various types ofreplies, the standardization of the data structure format forinter-machine exchange, and the process creation primitives whichextend the machine boundaries. Such notions are basic and must bepart of any distributed system definition. Our main concern is notwith these efforts.
A COMMENTARY on PROCEDURE CALLING Page 3 Rather, we take exception to PCP's underlying premise: that theprocedure calling discipline is the starting point for buildingmulti-computer systems. This premise leads to a model which has acentral point for the entire algorithm control, rather than a morenatural (in network situations) distributed control accomplished bycooperating independent entities interacting through commoncommunication paths. While the procedure call may be an appropriatebasis for certain applications, we believe that it can neitherdirectly nor accurately model the interactions and controlstructures that occur in many distributed multi-computer systems. Much of what follows may seem to be a pedagogic argument, andPCP supporters may take the position of "who cares what you call it,its doing the same thing". Our reply is that it is very importantto achieve a clear and concise model of distributed computation, andwhile the PCP model does not require "poor implementation" ofdistributed systems, neither does it make "good implementation" anyeasier, nor does it prohibit ill-advised programming practices. Amodel stressing the dynamic interconnection of somewhat independentcomputing entities, we feel, adheres more to the notions ofdefensive programming, which we have found to be fundamental tobuilding usable multi-machine implementations. The rest of this RFC discusses what we feel to be some of theshortcomings of a procedure call protocol.Limitations of Procedure Calling Across Machines___________ __ _________ _______ ______ ________ First and foremost, it is our contention that procedure callingshould not be the basis for multi-machine interactions. We feelthat a request and reply protocol along with suitably manipulatedcommunication paths between processes forms a model better suited tothe situation in which the network places us. In a networkenvironment one has autonomous computing entities which have agreedon their cooperation, rather than a master process forcing executionof a certain body of code to fulfill its computing needs. In such aconfiguration, actions required of a process are best accommodatedindirectly (by request) rather than directly (by procedure call), inorder to maintain the integrity of the constituent processes. Procedure calling is most often a very primitive operationwhose implementation often requires only a single machineinstruction. In addition, it is usually true that procedure callingis usually not within the domain of the operating system. [TheMultics intersegment procedure calling mechanism may present anexception to this, until linkage is complete. In the remote PCPcase, however, linkage can never be complete in the sense ofsupporting a fast transfer of control between modules]. Processesand communication paths between processes, however, are undeniablyoperating system constructs. In an environment where localprocedure calling was "cheap", it would be ill-advised to blur the
A COMMENTARY on PROCEDURE CALLING Page 4distinction between a local (inexpensive in time and effort) and aremote procedure call, which obviously requires a great deal ofeffort by the "PCP system", if not by the PCP user. It also seemsto be the case that the cost of blurring the local/remotedistinction at the procedure call level will be found in the morefrequent use of a less efficient local procedure calling mechanism.Interprocess communication, on the other hand, (at least with regardto stream or message oriented channels and not just interruptsignals) is generally regarded as having a significant costassociated with it. Message sending is always an interprocessaction, and requires system intervention always. There is not assubstantial a difference between the IPC of local processes and theIPC of remote processes, as between local and remote procedurecalling. PCP is suggestive of a model in which processes exist thatspan machine boundaries to provide inter-machine subroutine calling.Yet the PCP documentation has not advocated the notion of a processthat spans machine boundaries, and rightfully so since such acreation would cause innumerable problems. Since procedure callingis more suitable as an intra-process notion, it seems to be a betteridea to take the interprocess communication framework and extend itto have a uniform interpretation locally and remotely, rather thanto extend the procedure calling model. It is also our contentionthat a model which relies on procedure calling for its basis doesnot take into account the special nature of the network environment,and that such an environment can be more suitably handled in amessage passing model. Furthermore, we feel that programming as awhole, even purely local computing, will benefit from paying moreattention to such areas as reliability and robustness, which havebeen brought to the forefront through experience with an oftentimesunreliable network and collection of hosts. An IPC model, byemphasizing the connections between disjoint processes, seems toreinforce the idea that distributed computing is accomplished byjoining separate entities, and that defensive programming and errorhandling techniques are appropriate. Since PCP is, we think, fordistributed system builders, and not for the end user (e.g. anRSEXEC user), avoiding the network, interconnection issues, andrelative costs, may be counter-productive if the goal is to achieveusable network systems. In a similar vein, the entire notion of inter-machine procedurecalling underlies a model which in effect has extended the addressspace of a single process. That is, there is a single locus ofalgorithm control (although perhaps not a single locus ofexecution). While this model may well serve the needs of a "local"computation where the parts are strongly bound together, ourexperience in building working distributed systems has shown theutility of a model which has multiple loci of control and execution.In such a model, it is through agreements on the method and type ofinformation interchange and synchronization, that a computation iscarried out, rather than at the singular direction of a centralentity. In a model that has distributed control and execution, wefeel a process will be in a better position to naturally cope withthe many vagaries that necessarily arise in a network environment.
A COMMENTARY on PROCEDURE CALLING Page 5 The unmistakable trend in systems programming is towardinviolable (protected) process structures with externalsynchronization as a means of coping with complex debugging tasksand the difficulty of making system changes. This trend is bettersupported, we feel, by a message passing rather than a proceduralmodel of computation. Furthermore, we feel that network programmingtechniques should be applied to local computation, not the other wayaround.Some Particulars____ ___________ In the following list, we try to be more specific with respectto particular situations where we think the PCP concept may be weakas the basis for a network programming system. For some of theseexamples to be meaningful, the reader should be fairly familiar withthe PCP documents issued asRFC 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 appropriatebasis for distributed multi-computer systems because it can neitherdirectly nor accurately model the network environment. The PCPvirtual programming system may be inadequate for implementing manydistributed systems because the complexities and possibilitiesunique to the network environment are not provided for at this basic
A COMMENTARY on PROCEDURE CALLING Page 8level.
[8]ページ先頭