On Remote Procedure Call * Patricia Gomes Soares t Distributed Computing and Communications (DCC) Lab . Computer Science Dept ., Columbia Universit y New York City, NY 1002 7 Abstract makes resources available to a wider commu- nity. Both data and processes) can be repli- The Remote Procedure Call (RPC) paradigm i s cated thereby achieving greater performance reviewed. The concept is described, along with through parallelism, increased reliability and the backbone structure of the mechanisms tha t availability, and higher fault tolerance. The re- support it . An overview of works in support- mote accessibility of specialized units provid e ing these mechanisms is discussed. Extensions better performance for applications with spe- to the paradigm that have been proposed t o cific requirements. enlarge its suitability, are studied . The main Initially, only operating-system-level prim- contributions of this paper are a standard vie w itives supported interprocess communication . and classification of RPC mechanisms accord- Unfortunately, the details of communicatio n ing to different perspectives, and a snapshot o f were not transparent to application program- the paradigm in use today and of goals for the mers. To transmit complex data structures, i t future of RPC . was necessary to explicitly convert them int o or from byte streams . The programmer neede d to be aware of heterogeneity at the machin e 1 Introductio n level, as well as at the language level, betwee n the sending and the receiving processes. No Over time, operating-system support as well compile-time support was offered by the lan- as language-level support have been designed guages, and debugging became an extremel y to ease the development of distributed applica- difficult task. A higher level of abstraction was tions . A distributed application is a set of re- needed to model interprocess communication . lated programs that execute concurrently or in A variety of language-level constructors an d parallel, on the same or distinct autonomou s operators were then proposed to address thi s processing nodes of a distributed system, inter- problem. They improved readability, portabil- changing information. ity, and supported static type checking of dis- The decentralized configuration provided b y tributed applications . A major achievemen t a distributed system brought many benefits . in this area was the Remote Procedure Call The interconnection of these processing units (RPC) . *The IBM contact for this paper is Jan Pachl, Centr e The procedure mechanism, which is provide d for Advanced Studies, IBM Canada Ltd ., Dept. B2/894, by most imperative nondistributed languages , 895 Don Mills Road, North York, Ontario, M3C 1W3 . was initially proposed to support code mod- This work was partly supported by Brazilian Re- search Council (CNPq) under Grant 204543/89 .4. IA running program unit is a process . 215 ularization, and to be an abstraction facility. tinct approaches . In Section 8, extensions and RPC extends this mechanism to a distributed software support added to the RPC paradigm environment, whereby a process can call a pro- are discussed. Finally, Section 9 describes mea- cedure that belongs to another process . Inter- surements that can be used to evaluate the per- process communication is then given the syn- formance of RPC systems . tax and semantics of a well-accepted strongly typed language abstraction . Significant result s have been achieved in the effort to better ac- 2 General Concepts commodate in the model problems related not only with interprocess communication issues , Before exploring the concept of RPC, the un- but also with distributed environment configu- derlying environment is described here. The rations. major environment requirements that RPC is Computing systems continue evolving at aimed to support are introduced . Other ap- an astonishing speed, and parameters change proachs that address these features are sur- quickly. A high-speed network is capable of veyed. continuously broadcasting a database, thu s A distributed computing system consists of providing for an almost zero access time t o a collection of autonomous processing nodes data. An operating system today plays the role interconnected through a communication net - of a decentralized manager that searches for fa- work. An autonomous processing node com- cilities to provide applications with necessar y prises one or more processors, one or mor e resources . Users are close to a declarative en- levels of memory, and any number of exter- vironment where they specify what their needs nal devices [8, 47] . No homogeneity is as- are, and the distributed system is supposed t o sumed among the nodes, neither in the proces- select, based on the instantaneous configura- sor, memory, nor device levels . Autonomous tion of the system, how to provide it . nodes cooperate by sending messages over the network. The communication network may be Much demand is placed on mechanisms that local area (short haul), wide area (long haul) , isolate architectural dependent characteristic s or any combination local ones and wide ones from the user . The RPC is an abstraction connected by gateways . Neither the network which can make these dependencies transpar- nor any node need be reliable . In general, it is ent to the user . A system supporting RPCs assumed that the communication delay is long may provide for location transparency, where enough to make the access to nonlocal data sig - the user is unaware of where the call is exe- nificantly more expensive than the access to 10- cuted. cal primary memory. It is arguable, though, as The RPC constitutes, also, a sound basi s to whether or not the nonlocal access is not sig- for moving existing applications to the dis- nificantly more expensive than the local acces s tributed system environment . It supports soft- when secondary storage is involved [59] . ware reusability, which can be one of the most A distributed program consists of multiple important medicines in attacking the softwar e program units that may execute concurrently crisis [69] . on the nodes of a distributed system, and inter- In this paper, the whole RPC concept is ex- act by exchanging messages2 . A running pro- plored, and surveyed . In Section 2, the un- gram unit is a process . The distributed pro- derlying architecture is described, and in Sec- gramming consists of implementing distributed tion 2.1 the concept of RPC is introduced . Sec- applications . The distributed languages consist tion 3 presents the major challenges in support - of programming languages that support the de- ing the paradigm. The standard design of an velopment of distributed applications . There RPC system is described in Section 4, as well are three important features that distribute d as its major components, their function, and how they interact . Sections 5, 6, and 7 sur- 2 1n shared memory distributed systems, progra m vey each of those major components, analyzin g units can also interact through shared memory. Thes e systems will not be considered in this paper, and some the problems they are supposed to deal with , assumptions and assertions made may not be valid fo r and describing several systems and their dis- those environments . 216 languages must deal with that are not presen t of only a subset of the nodes in an applica- in sequential languages [8] : tion's execution, partial failure, leaves still the opportunity for the detection and recovery of • Multiple program units the failure, avoiding the application's failure. • Communication among the program unit s Considerable increase in reliability can also b e achieved by simply replicating the functions o r • Partial failure . data of the application on several nodes . A distributed language must provide sup - Distributed languages differ in modeling pro- port for the specification of a program compris- gram units, communication and synchroniza- ing multiple program units. The programme r tion, and recoverability . Some languages model should also be able to perform process man- program units as objects and are distributed agement . That is, to specify the location i n object-based. An extensive survey of dis- which each program unit is to be executed ; the tributed object-based programming systems i s mode of instantiation, heavy weighted or light described in [16] . Others model the program weighted; and when the instantiation should units as processes units and are named process- start. The operating system allocates a com- oriented (Hermes [75], and NIL [76]) . Yet oth- plete address space for the execution of heav y ers model program units into tasks, as well as weighted processes . The address space con- processes (Ada [20]), where a task is a less ex- tains the code portion of the process, the dat a pensive instantiation of program units than the portion with the program data, the heap for other two methods. dynamic allocation of memory, and the stack , Many languages model communication as which contains the return address linkage for the sending and reception of messages, re- each function call and also the data elements ferred to as message-based languages, simulat- required by a function . The creation of a light- ing datagram mailing (CSP [35], NIL [74]) . A weighted process causes the operating system process P willing to communicate with a pro- to accommodate the process into the addres s cess Q, sends a message to Q and can continue space of another one . Both processes have th e executing . Process Q, on the other hand, de- same code and data portions and share a com- cides when it is willing to receive messages and mon heap and stack spaces . Process manage- then checks its mail box. Process Q can, if nec- ment can be used to minimize the executio n essary, send messages back to P in response to time of a distributed program, where the par- its message. P and Q are peer processes, that allel units cooperate rather than compete.