Paper Discussion - Fall 2008 - CS 736

Remote procedure calls, a mechanism which persists to this day, were formally introduced by this paper. The goals of the author's implementation are to preserve the semantics of a local function call while executing the body of a function on a remote host. The execution of this illusion requires a name server with which to connect hosts to external services, a marshaling and unmarshaling mechanism with which to package program arguments and return values, and a transparent reliability mechanism to emulate the reliability of local memory access over the less-reliable network medium.

As we continue to employ remote procedure calls today, many of the most desirable properties from this paper have been exposed to us. The convenience of making a function call to execute code on a remote machine is compelling in any scenario where communication must have synchronous and explicit effects; it frees us from performing the marshaling of data ourselves (sometimes) and it lets us worry about program logic rather than network and process behavior. As a pure communication method, it employs a reliable messaging protocol to verify receipt of message and progress on the remote host. Again, the programmer is freed from dealing with these matters, "by hand," and the programmed system is naturally given an opportunity to recover from node failures through exceptions. For each of these reasons, one might say Remote Procedure Calls are a good idea.

There are, however, some clear shortcomings of the Remote Procedure Call mechanism. First, while the error-recovery features of the XEROX RPC are compelling, it seems clear that it is impossible to preserve the semantics of a local function call. Normal user-level function calls do not fail due to network errors, and they don't ever need to be tried a second time. Exposing these events to the user is a crack in the illusion created by RPC, and the recovery is more complex than a simple error returned from a function: for instance, the user must be made aware whether the call partially, totally, or not-at-all executed on the server before the failure. So, while the procedure call semantic seems awfully convenient, it introduces many more problems and worse still they are not evident to the programmer unless he knows he is making a remote call. A second problem is unavoidable: setting up the binding of an RPC client to a server is awkward today, and it's awkward in the system presented here. Having a name server is a hassle, and I worry that much of the convenience gained is ruined by the increase in code size from RPC, "setup."

In general, the approach taken here to RPC is very static-seeming to me. I wonder if much of the cost of error-prone "setup" could be alleviated if done in combination with some kind of automatic discovery protocol. Instead of the programmer declaring what machines to act upon explicitly, it would be determined from the network what would be the most logical target. Obviously, this does not scale to the internet, but for smaller private networks it is feasible. Automatic discovery also suggests an alternative to the broken "everything is a procedure" semantic, because a failure of a node could be handled transparently: if a call fails due to the destination disappearing, the framework could wait for the next available destination matching its requirements and never reveal a network error. There are several difficulties in doing this, but in general these extensions might fix the things that are broken with RPC as described by Xerox.

Summary:
This paper presents a remote procedure call system which allows robust and fast remote procedure calls across a network. It can obtain high performance inter-machine IPC, and provides good RPC Semantics with exactly once execution to provide robust against server, client and network failures. It Eases the implementation of distributed applications and can be used for high data rate communication without the flow and congestion control features. Five pieces are involved in the procedure call system, they are the user, the user-stub, the RPC communications package (RPC Runtime), the server-stub, and the server. And Implementations were created in a number of other languages, including C and Smalltalk.
The goal the paper was trying to deal with:
The problem the paper was trying to deal with is to make remote procedure calls across a network with a quick and simple interface to facilitate distributed computing. Another goal the paper is trying to do is to find a good semantics to make is very powerful so there is no need of layer mechanism above it. The paper also has aims to make RPC highly efficient and has secure end-to-end communication.

Contributions
1． One of the contributions of this paper was the idea that RPC semantics make a remote procedure call was abstracted to behave very similar to a local procedure call. This idea possibly originates from the decision that procedure calls as the paradigm for control and data transfers.
2． The authors propose using distributed database of RPC binding. This can make the RPC execute quite efficiently. Without the database, the callee’s address has to be hard-coded in the caller code which can add unnecessary difficulties.
3． Another contribution is that RPC provides a lookup service used to bind RPC callers and callees, which helps to provide a level of indirection between services/servers and port/machine identities on the Internet.
Flaws:
One of the flaws the paper may have is that procedure call level may be too low; message formats for internet protocols may encourage better separation between code and protocol. The second one is that it will be very hard to revise interfaces and may cause very bad code on server. Finally, it is language specific or not language flexible.

Techniques performance:
RPC (remote procedure call) is a mechanism for transfer of control and data, and subsequent resumption of control. The mechanism of RPC can be stated as follows: (1) Caller invokes a remote procedure and gets suspended. (2) Parameters are passed across the network to the Callee. (3) Callee executes the procedure and produce results. (4) Results are passed back to the caller and caller resumes execution. And the authors wanted their implementation of this concept to be relatively transparent to the programmer, so that an RPC call would look and feel semantically like a local procedure call. Binding is a main technique used in RPC, it has naming and location where naming is to specify machine a caller wants to bind to and location to Determining machine address of the callee and specifying the procedure of the callee to be invoked. Some other techniques like transport protocol, exceptions and process optimizations are also discussed in this paper.

In this paper, the authors present an RPC (remote procedure call) package that they have built for the Cedar programming environment. They describe their goals, the basic design decisions that they’ve made , the components of the system and then present some experimental results.

Procedure calls were a well-known and understood mechanism for transfer of control and data within a program running on a single computer. In previous work, it has been proposed that the same mechanism could be extended to provide for transfer of control and data across a network. The authors implement in their environment an RPC package and address some issues that the designers of an RPC facility face. Their primary goal was to make distributed computation easy and efficient and simultaneously provide secure communication.

The main contribution of the paper is that the local procedure call abstraction is maintained for RPC. This makes it easy for the programmers to use RPCs. Another contribution of the paper is the detailed description of the components of the system. More specifically, when making a remote call, five pieces of program are involved: the user, the user-stub, the RPC communications package, the server stub and the server. The programmer needs only to write the user and server code. The other components are generated automatically by the system. This facilitates even more the programmer. Binding is used so that the caller determines the machine address of the callee. Finally, the authors describe a packet-level transport protocol which is used to securely transfer data between the caller and the callee procedures.

One of the flaws of the system is that significant delays in communication can be caused when multiple packets need to be sent. This can happen because we only send one packet at a time and then wait to receive acknowledgment of the packet. In this case the performance of the system can be reduced.

As far as it concerns the performance techniques, an idle process pool is maintained in order to avoid delays that can occur by the creation of new processes. Moreover, a simple small packet-based protocol is used to transfer data between the caller and the callee. Although, this protocol is very efficient when all the arguments fit in a single packet, it can be a major source of delay when transferring a large amount of data in one direction. In general, throughout the paper we can see that there is a tradeoff between efficiency and simplicity.

Summary
This paper describes the Remote Procedure Call package developed at Xerox PARC. In particular, it discusses the structure and semantics of the RPC mechanism developed, facility for binding caller and callee, the protocol implemented for transfer of data and control between caller and callee.

Problem attempted
The primary objective of developing this RPC package was to make developing distributed applications much easier than what it was then. Besides, increasing the efficiency of RPC significantly and ability to provide secure communication with RPC were other aims.

Contributions

1. The RPC mechanism developed can be understood as constituting five important components associated with a remote call, namely : user, user-stub, RPCRuntime package, server-stub and server.

2. The RPC mechanism implemented has followed the semantics of local procedure calls as close as possible. The user makes a normal local to user-stub. The user-stub is responsible for preparing one or more packets containing target procedure specification and the arguments and using the RPCRuntime to reliably transmit these packet(s) to callee.

3. A distributed database (Grapevine) is used to locate an exporter of an interface. Any exporter who desires to export an interface will get itself listed in Grapevine by a call to ExportInterface in RPCRuntimee. After this, the connect-site of the instance exported will have the network-address of the exporting machine. Besides, the exporting machine maintains a unique identifier for every "export".

4. The paper makes to make the common case simple and fast by implementing a special transport protocol for RPC. Calls whose arguments fit in a single packet can just take the result of call as sufficient acknowledgement instead of waiting for explicit acknowledgement. Calls that require more than one packet to be sent wait for explicit acks and use probes to make sure the communication link and the host are up.

5. Since remote procedure calls are actually process creation and process swaps, they could cost significantly more than procedue calls. In order to minimize this, a machine maintains a stock of idle processes to serve incoming packets. This avoids cost of processs creation in handling a call

Flaws

I am not able to identify any flaw in this paper as compared to what has been stated as the aim of this paper.

Tredeoffs

The paper makes a trade-off between keeping the RPC implementation as simple as possible (closely resembling local procedure calls ) and making design decisions that could potentially optimize but make programming difficult. This is a very common theme in many trade-offs where simplicity is always favored unless it is absolutely inevitable to make the implementation complicated. ( For example we saw similar trade-ofs in thread management paper, where the thread management routines are kept as simple as possible )

Implementing Remote Procedure Calls

Summary
The authors are describing their experience designing a Remote Procedure call (RPC) package in Mesa ( a high level language ) with the intention of making the communication part of distributed application development easy from the aspects of programability and efficiency.

Description of the problem being solved

The authors want to create a working implementation of an RPC package ( rather than a paper design ) for better communication between distributed programs in Cedar project that suits a set of requirements like : a) ease of programability and quick adoption [ achieved by mimicking the local procedure call sematics for RPC also ] b) very efficient for RPC purposes [ achieved by a host of optimization like idle process pools for reducing process creation, custom protocol for low connection overhead etc ].

Contributions of the paper

1) Load Balancing : Use of Grapevine distributed database to hold the information of which procedures are exported by which instances results in their RPC solution having Load balancing across multiple instances exporting the same procedure.

2) Resilient to Server restarts : Techniques like passing an identifier from the RPCRuntime on the server to the client to identify exported interfaces makes the RPC call fail if the server was restarted in between two RPC calls or is no longer exporting the interface. The design is pretty resilient to temporary failures.

3) Security: Secure communication during RPC is very important and they have duely provided authentication and encrypted communication using Grapevine. They claim that previous RPC designs and implementations did not address security.

4) Optimizations : They have numerous optimizations to make their RPC package very efficient. For eg. they maintain idle process pools in the server so that when a RPC call comes, they can optimize on the costs of creating a new process to handle the call.

Flaws in the paper

1) Lack of asynchronous RPC for exploting parallelism: They have not provided very good support for parallel RPC within the RPC package citing simplicity as the reason and rely on the Parallellism provided by Mesa for achieving parallel RPC calls. A caller has to block for the results of a RPC call before making another RPC call. So, to explot parallelism , the programers have to create multiple processes in Mesa and then make multiple RPC calls. Providing a optional asynchronous RPC mechanism might have helped.

2) Custom communication protocol inefficient for regular data transfers without non-trivial optimization which require extra programming effort. The authors claim they will look into this in future.

3) The paper does not explicitly mention any mechanisms for removal of dead exported interfaces from the Grapevine database. For example, a callee when figures out that the callee instance is no longer exporting the interface, it can clean up the Grapevine database so that other caller do not go to the same dead exported interface.

Techniques used to achieve performance

1) Piggy backing : Use of subsequent packets for implicit acknowledgement of previous packets.

2) Minimize costs of establishing, maintaining and terminating connections by using a custom communication protocol

3) Reducing number of process swaps using idle process pools.

Tradeoffs made

1) Removing generality from the RPC implementation in favor of improved efficiency : Their custom communication protocol does not handle regular bulk data transfers. Their RPC mechanism does not provide asynchonous RPC calls.

2) Tradeoff between space and time for the optimization of idle process pools. They maintain idle process pools which are resource overheads in order to speeden up the RPC call handling by avoiding process creation costs.

Another part of OS where this technique could be applied

1) Idle resource pools is a widely used tradeoff. It is used in many thread libraries, Web servers and other service handlers. It can be applied in any place where resource creation is costly and the benefits of maintaining idle resources outweigh the costs.

2) Moving from a general solution to a specific solution is also a widely used tradeoff. Optimizing for common and popular cases is the usual trend. This has been used in Exokernel by providing specific libOSes over a minimalistic OS instead of generic libOS that handles everybody's needs.

In Implementing Remote Procedure Calls, Birrell, et al. outline the design decisions involved in creating their own RPC library for the Mesa language. Thier considerations included efficient network communication, program structure, and data protection.

The Problem

A need exists for some applications to perform remote computations on demand. In most cases, such procedures should be able to receive arguments from the caller and send their results back to the caller. A variety of protocols existed in 1984 to accomplish tasks such as this; however, they were difficult to use.

Contributions

The primary contribution was the creation of a new programming model where users write applications that invoke procedures identified by a service name on their network. These procedure definitions were defined in stubs that become part of the client and server applications. The procedure calls were blocking, and did not timeout.

A nameserver was used to translate a service name into an IP address. This allowed for easy migration of services in an attempt to perform load balancing or redundancy. No changes were required to the client code to support such migration.

End-to-end communication allowed the client and securely and conveniently encrypt all their message traffic.

Many RPC optimization opportunities exist; however, a seminal one was discussed involving piggybacking useful information across calls, reducing net message traffic. PUP, a protocol similar to TCP, was initially used to implement this RPC implementation, but provided too many guarantees that damaged the efficiency of the protocol.

Flaws

If process X sends a RPC to process Y, it does not accomplish work while that message is in flight or being processed remotely (though this not the case if X is multi-threaded). As a result, some applications are slowed by this wait for an acknowledgement.

Performance Tradeoffs Made

Clearly, simple blocking exchange application logic was favored over complex polling and notification-based logic. This reduction in complexity can come at the expense of reduced concurrency. Also, each RPC experiences the overhead of accomplishing a name lookup. Though this can be speedily addressed with caching techniques, new consistency issues arise.

Other Applications

RPC's are not limited to just executing code across a network. They can also involve requesting a computation on a local piece of hardware using a different interconnect, such as one might request their GPU render data over a system bus.

Implementing Remote Procedure Calls

This paper explains a package implemented to provide the facility of remote procedure calls to computers across a network. This facility is developed for the Cedar programming environment and the Xerox computer network. The MESA programming language is used. They used the concept of stubs to implement the RPC package; five components take part in the communication: the user, the user-stub, the RPCRuntime communication mechanisms, the server-stub and the server. The paper explains in detail the binding mechanisms and the transport protocol.

The purpose of this research is to make distributed computation easy. They pretend to have future distributed application developers have to implement just the procedures and not have to worry about the communication protocols. For this purpose they want to make RPC as fast as possible and make the semantics of the RPC package as powerful as possible.

They contribute to making RPC a secure communication, because no distributed system has included security as a feature of the communication so far. This RPC package allows encryption. It provides a simple confirmed communication protocol that does not need of a handshaking mechanism, so the connection establishment can be done faster. Some of the ideas for the communication mechanism are still used nowadays.

The use of a database to store the network addresses of the service providers does not seem like a very feasible solution for big networks. It does not seem to make sense to optimize the communication protocols for calls that have small data transfer and not worry about optimizing calls that perform transfers of large amounts of data. Having to wait for an ack to start transmitting the next package is not a very efficient mechanism. The decision of trying to make RPC as close as local procedure calls may not be the most suitable for some situations, not having a time out for the response may avoid the caller to be idle waiting for a response when it could ask a service from a different server. The performance section is simplistic because only two systems performing RPC are used for the measurements.

One of the important design decisions that determines the protocols is that RPC semantics should be as similar as local procedure calls, this makes the programming of RPC easier to the developer, but not as optimized as it could be. An important tradeoff that they make for complicated calls are simplicity versus performance; they argue that in order to send the next package, the previous package needs to be ack; this simplifies the buffers and control mechanisms in both caller and callee but decreases performance by making the communication slower. One of the mechanism that is constantly used for improving performance is using the response from the callee as an ack for the caller.

Summary:
This paper presents RPC (remote procedure calls), and its implementation in a high-level programming language (Mesa). The overall structure of RPC package is kept along similar lines of that of local procedure calls. Ideas such as distributed naming and binding form the basis of their efficient implementation.

Problem:
The paper presents an implementation of RPC facility, the design decisions and options explored during the implementation. The primary aim for this RPC project is to provide easier distributed computation, make it more efficient relative to network capacity while keeping intact the local procedure call semantics and secure communication.

Contributions:
RPC is/was one of the most popular paradigm for implementing a distibuting system. The authors have built one of the first comprehensive RPC package. There are four major contributions of their design. First, they propose clean and simple semantics for RPC similar to local procedure calls. These semantics are precise in the presence of machine and communication failures. Second, the inclusion of the semantics of address-containing arguments in the absence of a shared address space in their RPC package.

Third, the idea of binding, the way the caller determines the name and location of the callee and suitable protocols for communication providing appropriate mechanism for reliable and efficient communication. Finally, they also use the federal data encryption standard for secure communication.

Flaws:
The authors use PUP family of transport protocols. Why didn't they use TCP? They also suggest that a customized protocol for RPC may result in a substantial gain. Why cannot RPC be moulded instead of customized the transport protocol, to achieve similar gains?
There is no upper bound on how long the RPC clients may need to wait for results to match the local procedure call semantics. However, a deadlock server can easily result in thousands of clients blocking indefinitiely for their design.
The minimum average RTT for their network is 120us. In their results in Table 1, the difference between minimum and median elapsed times for 12,000 calls is at the most 30us. This shows that the network delay alone can bias these results to a large extent.
Further, for their evaluation (Table 1) remote calls were made between just two Dorados. This shows there is no mutual RPC traffic which may produce some sort of intererence (not the conventional network interference).
Further, it is well known that network links have delay asymmetry (each direction of the link can have different network delay). How it impacts their results is not studied?

Techniques Used:
RPC, binding, PUP transport protocols, procedure calls, environments, absence of shared address space.

Tradeoff:
One major tradeoff made is between the powerful semantics of local procedure calls and the efficiency of the RPC package many-a-times. Not providing timeouts for results is one of this trade-off.

Alternative uses:
RPC has found uses in a lot of other places, such as XML-rpc, CORBA rpc and Facebook's thrift protocol for scalable cross-language service development.

Summary
The paper describes Remote Procedure Calls as implemented in the Cedar Project. The idea is to develop a distributed computing analogue of a procedure call in programming. The call allows invocation of a handler on a remote machine, which does the required computation on the remote machine and returns the result to the calling machine.

Problems being addressed
The authors opine that mechanisms extant at those times constrained the use of distributed computing because they were difficult to use. Instead they wanted to develop a communication mechanism which was as easy to use as a local procedure call. They also wanted this mechanism to have powerful semantics, yet without loss of efficiency. And ensuring the security of the communication was another goal.

Contributions
- The user-stub, the RPCRuntime and the server-stub together form an abstraction which conceals the distributed nature of RPC, allowing it to closely ressemble local procedure calls.
- The use of Grapevine to maintain the database of available servers, allows the user programs to bind late, and even flexibly choose from a pool of servers implementing the routine based on parameters like proximity.
- The paper also describes using server side process pools to improve performance by avoiding overheads of process creation and process deletion.
- The use of Grapevine as an authentication service, and the possibility to use encrypted communication allows a greater extent of security.

Flaws
- The use of one-packet-at-a-time sort of a strategy works well with procedures with a small set of parameters, but does not scale well with larger parameters (like images etc).
- The lack of a timeout mechanism does seem to be an insufficiency. The authors argument that this is anologous to a local procedure call doesn't hold because here we're executing over a network. (However, if the user so deems, he can set up a timeout himself, outside of the mechanism provided.)

Technique used
The key technique I see here is a sort of proxying where the user-stub acts as a proxy for the remote procedure. The program invokes the user-stub, who in-turn connects to the remote server-stub and invokes the procedure. This makes the interface closely ressemble local procedure calls.
Tradeoff
The tradeoff here is one of fine grained control vs. ease of use. While exposing the 'remoteness' to the user application will allow the user application to do stuff like timeouts, etc, hiding it allows for uniformness with local procedure calls and hence ease of use.
Another place where a similar technique is used
A VPN is another place where such a proxying technique is used. Here, a tun/tap interface acts as a proxy network interface. All traffic through the tun/tap interface is encrypted and tunnelled over to the tun/tap at the other end so that from the exterior, you have the impression that both parties are on the same network.

Summary: The paper describes an RPC implementation based on a custom RPC-targeted transport protocol and a distributed database for name-binding. RPC behave as regular calls, but are intercepted by caller/callee stubs automatically generated from interface specification and redirected to/by RPCRuntime. The implementation is optimized for frequent calls with little information exchange.

Problem: The main problem they target is the lack of experience with a full scale implementation of an RPC. In particular, defining an efficiently implementing: binding and caller-callee transfer protocols, as well as RPC integration in existing programming systems. Other merely stated goals (but little or not really addressed in the paper): defining semantics for 'address containing arguments', security enforcement.

Contributions: They provide an example of RPC implementation that actually works (at least for distributed programming research purposes), is optimized for the (perceived) common case. I am not sure what was exactly was new in those days, but I liked the idea of normal interfaces intercepted by stubs, which integrates nicely with existing programming style. Also automatic generation of such stubs is interesting.

Performance techniques: The most notable performance technique is the customization of the transport level protocol with little state (specially when idle) and no setup overhead. This is optimized for low server load and low latency in the case of small, frequent calls and relay on ACKs. In particular, there are implicit ACKs for the common case when all 'goes well' (Ex. a return or a new call). Timeouts are selected so that they don't happen in the expected case. Probes are send at increasing intervals and yet detect a communication failure in a time comparable with the computation. In the common case of 'small' procedures, one packet suffices to hold the arguments/result. They use a pool of idle-server processes to handlle requests.
In an RPC invocation one could only use the "type" allowing greater flexibility in instance selection (maybe based on proximity). Interface identifiers are exported once (possibly an expensive operation) at startup, and used many times later (faster).

Tradeoffs: A very fast binding, but more prone to failure, is a direct specification of the network address. Unavoidable: the programmer has to handle communication failures. Lack of state means that in case of failure, the user has little knowledge on the reason. Also, the user has little knowledge of the progress made by the server on behalf of its call. Their communication protocol requires a privileged status.

Weaknesses/Flaws: Not really mentioned what happens to 'address containing arguments', particularly how this is handled by the automatic stub generation (or, maybe this is what Lupine rejects?). Support for a limited set of languages. It is unclear how much their protocol was tailored for the characteristics of those days networks (speed and error rate). Also, it is not clear that they selected well what they consider the common case: many small procedure calls. After all, 'small' calls may be better suited to be handled locally and in fact 'long' calls may be better suited to be handled remotely (Ex. asking for files and getting 'long' results).

Summary:
Paper talks about IPC paradigm Remote Procedure Call (RPC) in which program on distributed machine can communicate with each other over network.

Problem:
Communication mechanisms at that time were not very easy to develop distributed program. Due to that powerful computers and powerful network was not utilized properly. So paper propose new RPC paradigm to make distributed computation easy.

Work Summary/ Contribution:

1. Major contribution of this paper is procedure based RPC. Using remotes procedures in programming language are as easy as using local procedure.
2. Paper describe building block of RPC architecture, which are : User/server Program, User/Server Stud , RPCRuntime and grapevine database based rpc binding.
3. User/Server Studs do packing/unpacking of data, which will be transferred by underline RPCRuntime to correct computer/process on network. User stud pack data when it call RPC and unpack data when it get result from server. Server Stud unpacks data when procedure on server is called and it pack data when it needs to deliver the result.
4. RPCRuntime is Communication protocol, which ensures that packet is delivered to correct machine. Retransmission is done by this layer without the interaction with user program . This package also ensures that multiple packet delivery to server doesn’t result in multiple procedure call in server.
5. Distributed Database Grapvine is used to publish the RPC. Once RPC is published on distributed database another computer on network can use this information to perform the binding. Grapvine replicate its data over the network so this is fault tolerant as well.
6. RPC provide very flexible binding mechanism. User stud need not specify the instance of remote procedure, it can be bound to any server implementing that procedure or if user want it can bind to particular machine at compile time, which is most restrictive binding.
7. Server can pass Mesa type exception back to client. RPCRuntime will raise exception in appropriate client process.

Field where this can be used:
This particular paper introduce to so many new concept which are currently being used as different name , such that –
1. Webservice: RPC made it easy to provide service on web. To me it seems RPC is the building block of webservice architecture in which communication is done in XML format.
2. Publishing/replicating RPC information over distributed database can be used to publish/replicate domain name ( DNS ).
3. As optimization RPCRuntime send ACK of previous packet with next packet, which reduce the number of packet to transmit. This is similar to technique calle piggybacking in current systems.
Flaws:
1. Not handling time out one of the drawback.
2. Using RPC paradigms its not sure how parallel execution of work can be performed as RPC is a blocking call.
3. Reason of exception is not known to user program due to which debugging of program might be issue. He doesn’t know if it is due to communication failure or server has crashed.
Tradeoffs:
1. Binding technique is simple to use but it take away the control from user. Now user can’t specify at runtime to which particular instance to use.
2. As caller is blocked on procedure call and no asynchronous call is available so this stop caller to do something useful and come back for result. I feel here to provide local procedure behavior, possibility of parallel execution is traded off.

Birrell and Nelson argue that remote procedure calls are a useful distributed
system implementation technique. In this paper, they present the design decisions that they made during the development of an RPC facility, describe the general architecture of such a system and show some experimental results on the performance of their implementation.

The major contribution of the paper is the detailed presentation of a remote procedure call mechanism. Each remote procedure has a predefined interface and the user calls a remote procedure as he would call a local one. A local stub, which is automatically generated by the interface description, processes the input parameters, creates a network packet and sends it over the network. A remote stub, which is also automatically generated, processes the packet extracting the parameters and calls the target procedure locally. The same procedure is applied for encapsulating the return value in a packet to be sent to the caller. Two problems associated with remote procedure calls are locating the remote computer and specifying which procedure will be called. The first problem is addressed by a dynamic binding scheme. For the second one, they rely on the Grapevine distributed service, which is used as a reliable and fault-tolerant naming and location service.

Being a seminal paper in remote procedure call implementation, the paper fails to address some of the complexity that arises when using RPCs in real-world programs. In my opinion, the biggest flaw is that RPC fails to capture operations which involve an internal state, as those cannot be communicated as function parameters. Although functional programming purists will argue that this is a good design choice, it often proves very limiting for making complex programs work. Moreover, passing pointer arguments to functions is not supported, neither discussed at all in this paper.

The biggest benefit for user applications is that remote procedure calls allow transparent communication in distributed applications. Also RPCs encourage loose coupling of distributed system components, with all the benefits this brings (like scalability and easier maintainability). Additionally, the automatically generated stubs might serve other purposes than encapsulating data into messages: they can, for example, handle translation across different languages, similar to what CORBA object brokers do. On the negative side, remote procedures might generate exceptions in code segments that appear to be calling local functions only, so programmers must essentially not only handle the return value, but also the absence of it.

Summary
This paper describes a remote procedure call facility for Cedar that mimics local procedure call usage in the same environment.

Problem
How do you make distributed computing efficient, while providing a convenient, familiar, and secure mechanism that makes it easy to get distributed computing "right."

Contributions
They provide a remote procedure call facility that has the same semantics as a local procedure call. In particular, this involved a design choice that remote procedure calls should not time out so as to behave like local procedure calls. While this seems a peculiar and limiting choice, maintaining consistency in semantics for procedure calls allows for an ease in using remote procedure calls and adapting code using local procedure calls to use distributed computing. As the primary goal was to make distributed computation easy, the authors were willing to make this tradeoff.

A distinction is made between a remote procedure call interface and a particular exporter of that interface. The Grapevine database is used to locate an exporter. As well, there is a stub generator that uses the interface to create the user and server stubs that take care of the detailed communication code.

As well, the authors implemented their own packet protocol (tradeoffs discussed later), and attempted to use encryption to guarantee security, something that while possible had not been widely implemented according to the authors.

Flaws
There are a number of unsubstantiated claims throughout the paper. (e.g. “Using them would probably have provided an extra factor of two in our performance.”)

Techniques
The major technique used to improve performance was for the designers to use their own packet protocol instead of some other already existent, but unspecialized, protocol. This allowed the designers to specifically emphasize minimizing the time before getting results from a call. Essentially, the designers chose to trade the better throughput of existing protocols for better latency.

Throughout the paper, it is also noticed that there is a tradeoff between performance and between simplicity and convenience for the implementers of the remote procedure call facility. Specifically, this motivated the decision to use remote procedure calls as opposed to other communication methods that are more appropriate under certain circumstances as well as the decision not to implement certain performance optimizations listed by the authors.

Although the authors try to mimic the usage of local procedure calls, these techniques for creating an easy, familiar way to do distributed computation ought to apply to other local communication methods such as message passing as well.

Summary
This paper proposes a mechanism for remote execution of procedures on machines connected through network. The RPC package is developed to achieve it, and the paper discusses structure of RPC mechanism, binding clients, the protocol used and exception handling in RPC.

Problem trying to solve
They are trying to create a clean and simple semantics for calling remote procedures, handling network and machine failures in remote calls, semantics for addressing machine addresses, efficient protocol for remote communication and data integrity and security. Simplicity while keeping performance is desirable.

Contributions
This was one of the first few RPC implementations. The semantics of remote procedure calls are made similar to procedure calls on a single machine. No separate timeout mechanism is implemented, which is considered a necessary feature for all communications. The server maintains a list of pre-created idle server processes willing to handle incoming packets. This reduces a lot of call overhead as no processes are created at run-time. Grapevine is used, which provides authentication and encryption and provides for very easy host lookups.

Flaws
RPC was a very new usage at that time and there wasn’t much done in the field. The paper presents a good design but they conducted the experiments between two machines, which doesn’t seem enough to prove results. They use 10-15% network load setup with encryption off and did not measure anything on a long-haul setup. Waiting for acknowledgements adds extra overhead. This would act as a huge bottleneck in a loaded network.

Performance
An idle process pool is maintained to service requests and reduce teardown delays. An idle server might be holding up resources through those dummy processes, when only few connections are established. The sender/receiver use a way to send ACK to each/other, this reduces the need to maintain extra state information at client and server end but acknowledging each message can adds tremendous load on network.
This technique can be used in all distributed computing applications.

Summary
The paper presents an environment that makes remote procedure calls as simple and almost as efficient as local procedure calls. It hides all the complexities of networking, security, reliability from the user in the RPC RunTime and Grapevine servers.

Problem
Distributed computing in that era was a very difficult task and would involve building everything from top to bottom. As a result, it needed a lot of expertise for anyone to build a distributed computing network of computers(which was getting more common these days Ethernet and Arpanet). Also, unless this option was nearly as efficient and secure as using local procedure calls, people will try to avoid it.

Contributions
- Using the Grapevine server for obtaining the physical addresses of the instance of a server type, allowed them to dynamically change the machines running the servers. This level of indirection also helped in load balancing across multiple servers running the same type.
- Using the process pools on the server side, allowed them to implement the remote procedure call with just four process switches as compared to local procedures with two switches.
- The user stub and RPC Runtime environment simplifies the programming complexity. RPC calls look just like a normal procedure call and allow the server and client code to be compiled independently of each other.
- Since each RPC call is mostly independent of each other and involves a call and return, the network protocol avoids making any handshakes and maintaining complex state information.

Flaws
- They rely on the Mesa language features to handle timeouts. For a different language, such as C, timeouts would need to be set in the environment explicitly.
- They assume one activity per process which would require forking a new process everytime you need a non-blocking call to a server. A thread library would reduce the overhead but the unique identifier will then need to be the thread id.
- Huge/Many arguments that don't fit in one packet, have an unnecessary overhead of sending multiple acknowledgments. Maybe maintaining a sliding window would be an acceptable complexity for the sake of efficiency if the number of packets are large enough.

Technique
- They use a level of indirection in the Grapevine servers to hide the physical addresses and allow late binding to the server addresses.
- They use piggybacking of acknowledgements for previous results on next requests reducing the network usage to the bare minimum in the best case.
- There is a trade off in the generality of the system and sometimes efficiency for the sake of simplicity. Many useful features such as timeouts and efficient bulk data transfer are not a part of the environment.
- RPC technqiues are now the de facto standard for any distributed computing system.

Summary: The authors of this paper present a transport layer protocol for communication across networks built out of remote procedure calls. They implement security, reliability and efficient address-to-host mappings to help make this protocol useful for large-scale systems.
Problem to Solve: The authors are trying to develop an efficient communication protocol that allows for easy large-scale distributed computations. They also wanted to introduce security as mechanism that could be implemented in an end-to-end approach. These problems arose as computers became more affordable and researchers wanted to perform parallel computing as well as communicate between hosts securely.
Contributions: First, they introduce remote procedures as building block for developing a transport layer communication protocol. Although other protocols existed at this time, this was one of the first geared towards larger-scale efficient distributed communication, specifically for the Cedar project. Another important contribution is the introduction a encryption based end-to-end communication. This mechanism helped prevent eavesdropping as networks grew and started to transfer more sensitive data. This protocol involving RPC also introduced the notion of acknowledgments, leading to reliability control in network communication. Another contribution they make is the introduction of a mechanism to ensure that the receiver is receiving from the sender it is expecting and vise versa. It allows senders and receivers to differentiate between multiple connections they may have open at once as well as packets which have been received multiple times.
Flaws: During the performance evaluation of the system, the measurements they take are between two Dorado machines, while the links are under 5-10% utilization. Even considering the time of writing this paper 5-10% utilization seems rather low and testing between a single pair of nodes is introduces biases in the results. The performance between two nodes could very greatly depending on the topology and this effect is never really mentioned.
What tradeoff is made? One tradeoff that is made is that they use the Grapevice distributed database to look up callees. Although this allowed quick lookup, it seemed to be more feasible for a small number of computers (a local group) instead of large group (computers across multiple location). This is mainly because of the space/memory requirements grew non-linear. Another tradeoff is made during the main protocol, when the next data packet can't be sent until the previous one has been acknowledged. Since connection speeds at this time were much slower a lot of bandwidth would be wasted waiting for this acknowledgment. A positive performance tradeoff is made though by not requiring the protocol to have a connection tear down mechanism. Since communication resources were more limited during this time period, the lack of the 2-3 messages to tear down the connection saves these resources

Summary

This paper discusses the implementation of a remote procedure call (RPC) structure that creates a clean and easy interface by resembling a local procedure call, with high efficiency by designing the protocol, and a system for binding connections and security.

Problem to Solve

The primary problem this paper is trying to solve is that developing distributed systems was very difficult and typically only performed by communication experts.

With the powerful computers and networks in existence, distributed systems development needed a cleaner way to be done. At the same time, the paper also looked into making RPC highly efficient and having the ability to protect the data being transmitted.

Contributions
- Ability to make remote procedure calls easier to program by being similar to a local procedure call.
- Development of independent RPC protocol for fast and efficient RPC calls when only single packets are needed.
- Use of a database (grapevine) for binding interfaces and security handshaking

Flaws

This paper has a major aim of providing secure communications, however the results were never run with secure communications.

If multiple machines depend on one machine on the network for executing a specific procedure call and the server code runs into a dead lock, all of the machines will wait forever until the server code starts running again. Although this is the behavior of local procedure calls, having a large group of workstations wait forever may not be appropriate for tasks such as network file accesses, voting machines and ATM machines.

Techniques

Techniques to achieve performance in this paper include bypassing the software stack under certain circumstances, implementing a lightweight custom RPC protocol, using a grapevine database. For user simplicity, the layering of user-stub and RPCRuntime separates the procedure call from the packing and network handling. The main trade-off is simplifying the programming interface for a more complex one-purpose system. In simplifying the RPC calls for the user, additional layers were added that made assumptions that RPC calls require the data transmitted to be small, and adds in the need for separate grapevine servers. In addition the use of a shared address space was removed from the design. In addition, the handling of timeout cases is limited.
The technique of a simplified RPC protocol could be adapted to communicate between internal processes as well as external processes to create a standard interface to processes, devices and other remote machines.

Introduction:
This paper describes a framework which implements remote procedure calls, developed as part of the Cedar project at Xerox. The authors describe the motivations, design, implementation and performance evaluations of the RPC system.

What were they trying to solve:
Developing programs which communicated over the network was a difficult task. There was a lack of high-level mechanisms which programmers could use to write distributed applications, and often had to resort to writing low-level networking code to communicate. Also, connections between communications had to be hardcoded, since there was no way for applications to dynamically discover and connect to the desired process at runtime. Security was also an important feature missing in earlier implementations.

Contributions:
A simple interface to call procedures remotely, virtual identical from the programmer's point of view to a local procedure call.
Decoupling the specific application's requirements and semantics from the low-level communication protocols, by the use of stubs and the RPC runtime.
Dynamic discovery of server location using the Grapevine distributed database.
Both static and dynamic binding possible.
A packet-oriented network protocol optimized for RPCs, instead of connection-oriented heavyweight protocols.
Process-pooling at the server to decrease response time.
Full End-to-End encryption using DES.

Flaws:
While making remote procedure calls look the same as local calls makes the programmer's job easier, it also makes it harder for the programmer to handle failures. When a remote call fails, there might be a number of reasons for the failure, some of which the user might wish to handle. Also, the programmer might need more control on things such as a timeout period after which the communication is broken, which can't be done in this system without killing the process.
The single-packet window for acknowledgments is too pessimistic and doesn't scale well for larger workloads.

Techniques used to improve performance
Performance is improved by not using a heavy connection oriented protocol for communication, instead by having a small packet-oriented protocol.
Tradeoffs:
One tradeoff seen here is simplicity vs control. A RPC mechanism which appears as a local call is simple, but hides control from the programmer.
another part of the OS where the technique could be applied:
Some operating systems use RPC-like communication even within the system: e.g. COM subsystem in Windows.

Summary
In “Implementing Remote Procedure Calls,” Andrew Birrell and Bruce Nelson describe the implementation of an RPC mechanism in the Cedar programming environment at Xerox PARC.

Problem
Communication between processes on remote systems can be difficult and inefficient due to the necessity of moving data across a network. Invoking a local procedure is easy—the code corresponding to that procedure can simply be called directly—but trying to run a procedure on a remote system necessarily involves locating that procedure on the correct remote system, passing parameters or other necessary data to that system, running the procedure there, and transporting the result back to the original system. Since this involves considerably more work than a local invocation, programmers will be more reluctant to use remote procedures.

Contributions
• Maintaining the local procedure call abstraction for RPC—practically no difference is needed in making remote calls (once the initialization is completed), so it would be easy for programmers to make use of this method.
• Realizing the importance of security when data was transmitted over networks and providing facilities for securely transmitting such data.

Flaws
• Sending only one packet at a time (waiting for an acknowledgement between each packet) can cause significant delays in communication when multiple packets are required for each RPC. This is a surprising approach since emphasis is placed on efficiency.
• Using time as the basis on which conversation identifiers are based; in the implementation presented this can cause issues if the time synchronization has the possibility of being off by a second or more.

Performance Techniques
One way this implementation attempted to achieve good performance was by making use of single, in-order packet transmission with implicit acknowledgements. A lot of communication could be done with a single packet, so only allowing a single packet to be transmitted at a time did not usually have adverse effects while simplifying and speeding up the communication system due to there being no need to handle things like out-of-order packet reception or maintaining extensive buffers for the incoming channel. However, in the cases that needed multiple packets, only one packet could be in the round-trip pipe at any time. This could cause significant performance loss if many packets needed to be transmitted (compared with being able to send many packets at once).