CS 736 Reviews - Spring 2015

I apologize for turning in this late. I had to prospect CS577 exams last night and could not set aside time to read the paper. Here is the belated review.

1. Summary
The authors described the design and implementation of remote procedure calls (RPC) for Cedar programming environments. This paper emphasizes on the binding and call semantics of RPC package.

2. Problem
The practical implementation of RPC is rare compared to many theoretical design models. This paper is trying to design and implement an RPC package that facilitates distributed computation with simplicity and efficiency, and provides secure encrypted communication.

3. Contributions
The principle of designing RPC is that its semantics should be as similar to that of local procedure calls as possible.
The caller machine has the user process, user stub and RPCRuntime, while the callee machine server process, server stub and RPCRuntime. RPCRuntime is responsible for package transmissions in the internetwork. User and server stub are automatically generated interface modules by Lupine to import. The user process makes an RPC just as local procedure calls, but invokes user stub to pack the information into a call packet, RPCRuntime sends it to RPCRuntime callee machine. The server stub gets the packet from RPCRuntime, unpacks it and sends it to server process. The result is sent back to caller in the same way.
Binding connects a client to a server. The interface imported or exported consists of a type and an instance. Instance is a specific implementation of a type of service. Grapevine distributed database stores types as groups and instances as individuals, both are keyed by an RName string. Groups contains member-list to individuals and individuals has connect-site(network address) to server machines.
The binding begins when the server exports the type and instances of services to the Grapevine database, which updates the network address if needed. Callee RPCRuntime also keeps a copy of services type and instances provided. The caller imports by providing the type and instance via RPCRuntime, look up the Grapevine and obtain the machine address. Caller sends a packet to confirm the service provided in callee machine, and is successfully bound if affirmed, otherwise binding fails.
RPC call is designed to have the same semantics as local procedure calls with an aim to minimize elapsed time. A simple call goes as follows. The caller machines sends a call packet containing a call identifier, data and arguments. The callee receives the packet, computes the result and returns a result packet. Retransmission is assumed until acknowledgement is received or result packet is received. The call identifier has an activity (machine number + process) and a monotonic sequence number to ensure sequential communications and remove duplicates. The idle connection is implicitly terminated.
Complicated calls require explicit acknowledgements from callee. Also, it sends probe packets with increasing intervals which requests an acknowledgement to indicate callee is working. Crashing and restarting of service can be detected but deadlocking and looping cannot. If arguments are too large to fit in one packet, multiple packets are sent and the last automatically requests an explicit acknowledgement.
Exception packets may be generated and returned by callee in place of a result packet. The conversation resumes if caller’s catcher handles the exception, otherwise callee will be notified and the activity is unwound. RPC only allows predefined exceptions in the interface to guarantee security. Communication failure is sent as a special call failed exception.
To reduce the cost of RPC, idle server processes handle the incoming packets if destination process is busy. Server processes could return a result packet containing the server process identifier, and take over the conversation with user process.
Other optimizations include specializing RPC packets to bypass software hierarchies.

4. Evaluation
This paper presents transmission latency for various arguments, data size and exceptions. It does not compare to other RPC mechanisms but claimed to achieve the best performance at that time. From their data, I could not draw the conclusion because I didn’t know how RPC performed at that time. But Nelson’s thesis might be helpful and that’s why they omitted evaluations against other RPC mechanisms.
This paper only describes binding and RPC semantics. Other topics such as security and encryption are describes elsewhere.

5. Confusion
I’m still confused about how server processes help handle incoming packets. In one paragraph it seems to indicate server process will dispatch packets to destination process after it’s idle. The follow paragraph, however, says it take the conversation away from destination process.

Summary:
The paper discusses the package providing Remote procedure call facility, it's design and facilities for bindings client and transport level communication. It is specifically developed for cedar programming environment, communicating over Xerox internetwork. At the end of paper, some evaluation is shown in terms of RPC call latencies for different number of function arguments to show the package's performance.

Problem:
The existing implementations of RPC lacked in a few areas specific to the development environment. They are:
-The precise semantics of a call in presence of machine or communication failure
-Semantics of address arguments in absence of shared address space
-Integration of remote call with existing programming model
-Data integrity and security in open communication network
-protocol for transfer of data between caller and callee

Solution:
The approaches taken in paper to address above problems are based on the principle that the semantics of RPC should be as close as possible to those of the local procedure calls. They are:
-No time-out mechanism, instead abort an activity as part of parallel processing mechanism
-Grapevine distributed database used to avoid early binding of calls to the end machine. This database provides 3 copies redundancy.
-encryption-based security: unique identifier to allow calls for procedures done through RPC
-use of stubs: user side stub puts the specifications of target procedure and arguments into packets and RPCRuntime transmits them reliably to the server side stubs. Lupine generates the user-stub and server-stub automatically, which simplifies the usage of RPC
-Use of periodic probe in case the acknowledgement for the procedure call is not received, that is increased in wait duration over time. This is used to identify if there is a communication failure

Evaluation:
The evaluation only shows the time taken for different number of arguments and array size, but no comparison with existing RPC implementations or alternate RPC design implementations is done.

Confusions/Learnings:
The paper is trying to solve the distributed computation problem, and was quite ahead of its time addressing easy integration and security. It is a good read. One narrow design approach was fitting the arguments in a single call and expecting the results to also fit in single return call.

Summary:

This paper describes how stubs at either end of the RPC communication link (i.e. The user and server) can help make RPC calls as easy as a local procedure call. One of the authors had proposed a similar structure for his PhD thesis and this paper describes the implementation for Xerox's Cedar system.

Problem:

The main issue this paper tries to solve is the complexity involved in RPCs and how these could be abstracted away to present the user with a simpler interface. They wanted to promote the development and use of distributed applications.

Contributions:

One of the bigger contributions of this paper is an RPC implementation that used stubs to generate the actual remote procedure call. This helped abstract away some of the networking involved in completing a RPC. In addition, this paper also provides a template for an RPC structure that uses stubs.

The other possible contributions of this paper are the protocol that they implemented and how it allowed them to reduce the amount of communication needed for an RPC. For instance, they were able to do away with an acknowledgement for short calls which the result would be received within the time frame of an acknowledgement. They use this concept of implicit acknowledgements to reduce communication overhead.

In a somewhat contrary way, their underlying hardware (which allowed parallel execution) allowed them to implement a pool of server processes that would handle RPC calls. This enabled them to reduce the overhead of process creation despite the fact that process creation was considered inexpensive.

Other interesting aspects include bypassing the software communication stack and encrypting their communication line.

Evaluation:

They provide some latency numbers for RPCs with an increasing number of arguments and hence number of packets transmitted. They get progressively slower since their implementation of RPC needed acknowledgements for each transmission in a complex call. Their results show this trend.

Confusion:

This paper is a little confusing in terms of protocol timelines. Most of the concepts explained seem so familiar but how many of these contributions are from this implementation?

1.Summary
This paper discusses the implementation of Remote Procedure Calls (RPC) mechanism, the challenges the designers faced and the decisions they took to make RPC efficient and secure. Achieving distributed computation among many clients and a server with binding mechanism, RPC procedure semantics, call mechanism and the transport level communication protocol is discussed, with many alternatives that they did not pursue. Most of the paper is focussed on their design principles and they provide some RPC performance results compare to local calls.

2.Problem
The main problem the authors have tried to address is achieving simple and efficient way of distributed computation. They believed it can be achieved using RPC facility which existed during the Cedar project development. But, that RPC facility lacked precise semantics, suitable transfer protocols, secure binding/connection mechanism and exception/communication failure handling. All these issues have been addressed making RPC facility more general, fast and efficient.

3.Contributions
Several ideas and design decisions have been presented throughout the paper, which in itself are contributions. An RPC structure has been presented which involves an RPC runtime package, Lupine program to generate user and server stubs and an exporter/importer interface for procedures. RPC facility still maintaining the same local procedure semantics for communication is the biggest contribution of this paper. An unique binding mechanism with naming and remote machine identification is explained. Grapevine which maintains a database for secure connections between interface name’s instance and type along with specific access controls make RPC fast enough and secure. A RPC packet transport level communication which involves packet transmission with activity (unique identifier and sequence number), for simple and complicated call is presented. Self-handling of call failures, packet loss, exception handling and retransmission is very simple compared to other transmission protocols. All in all, the paper discusses each issue in detail and gives a design principle which makes RPC, the best possible solution for distributed computing.

4.Evaluation
The paper does not present any detailed evaluation, referring back to Nelson’s thesis for detailed results and analysis. Small measurement analysis of RPC package between two Dorado machines is mentioned which compares performance results with local calls for 12000 calls on each procedure with varying number of arguments. The measured latency time in microseconds for RPC varies from 1059 to 3374, for the same procedures called locally ranging from 9 to 196. The transmission overhead ranges from 131 to 284 us which is less compared to execution time.

5.Confusion
I did not understand the concept of conversation identifier and sequence number (why both?) A discussion on advantages/disadvantages of simple and complicated calls in class would be helpful.

Summary :
This article talks about the implementation of Remote Procedure Calls on Cedar systems running on the Dorados platform laying special emphasis on simplicity and efficacy of calls from the user perspective, transport level details, use of processes and a little bit of security

Problem :
To enable communication between processes running on different systems on a network through remote procedure calls while making such a mechanism both simple, efficient and secure for the programmers. It addresses the semantics of a call in the presence of communication and machine failures, dealing with address-containing arguments in the absence of shared-memory, binding and a suitable protocol for transfer of data between the caller and the callee.

Contributions :

1. They wanted to make the RPC communication very efficient while maintaining the power of the semantics of the package
2. The possibility of existence of a shared-memory system was discarded
3. The user, the user-stub and an instance of the RPCRuntime execute in the caller machine and the server, the server-stub and another instance of RPCRuntime execute in the callee machine
4. The RPCRuntime is responsible for retransmissions, acknowledgements, packet routing and encryption
5. The user-stub and the server-stub are automatically generated by a program called Lupine
6. The issue of binding is addresses using the concept on RNames in the context of Grapevine which is a distributed database containing binding related information. Further, the entries are divided into individuals and groups. Individuals correspond to instances of a particular type and they contain the connect-site (network address of the callee) while groups correspond to a type of instances.
7. The access control features of Grapevine assure the caller that the information that it finds for the callee is genuine
8. They conclude that developing a new communication protocol for this should make communication much faster and a performance gain of a factor of ten might be possible
9. Exception handling is handled in a way that is handled by the Mesa programming language by sending a exception packet instead of a result packet
10. The issue of security has been dealt with nee-to-end encryption of data. Grapevine is used as an authentication service. These techniques prevent eavesdropping, modification, replay attacks and creation of bogus calls.

Evaluation :
The measurement of performance has been made between two Dorados communicating over an Ethernet. The minimum and median of various scenarios haven been published. These include multiple arguments to very long arguments. The transmission delays have been noted. These figures have been compared with local procedure call timings.

1. Summary

They create an dedicated RPC protocol, intended to be both fast and simple to use. To achieve ease of use, they use auto-generated user side and server side stubs to translate local calls into remote calls. And to achieve performance, they implement a custom packet based protocol, optimized for RPC rather than data transfer.

2. Problem

While previous RPC systems exist, many of them suffer from certain issues in relation to their difficulty of use, and their performance. These issues have made it hard to write distributed systems, and this paper aims to present a protocol which is both easy to use and efficient.

3. Contributions

By implementing a custom network protocol they can often use fewer packets than a connection based protocol would use. They save packets in two ways, first is to make connections implicit, there is no special session setup protocol. Instead the receipt of a request from a new client implicitly creates a session, and after some time without any messages, the session can be removed from the server. Second is to make some acks implicit. In particular, each packet has an field indicating whether an ack is requested. And this field is only set if there is either more data to be sent, or if the packet is being sent as a retransmission. In the case where server finishes the request and sends the reply packet before the retransmission timeout, no further ack is required, and the receipt of the reply packet acts as an implicit ack of the last packet. Similarly, for the last reply packet, if the client makes another request within the retransmission timeout, no ack would be necessary, instead the next call request would serve as an ack for the reply. In the case of frequent small calls, this would result in half as many packets being sent.

The other major contribution is to make RPC calls look and act like local calls. The first step toward this is to use a generated user and server stubs, so that the RPC call from a programmers perspective literally is a local call, except not to the actual function but rather to a stub, which translates the call into network activity. Similarly on the server side, the RPC function is an actual function, and there is simply a server-stub that translates network activity into procedure calls. In this manner, the programmer is largely freed from worrying about the fact that the call is actually remote.

4. Evaluation

While they are attempting to make a RPC system that is faster than existing systems, they do not compare the system with other RPC systems, although they do refer us to Nelson's thesis, which contains a detailed description of the performance of other RPC systems. They do however compare the system with local calls, showing that on average the call takes 100 times longer, clearly not achieving a speed that is comparable to a local call. Although this is for a call that does not conduct any processing, and so the differential may be less significant for interesting functions.

The question of ease of use is hard to evaluate, but they do offer anecdotal evidence for its ease of use. They further note that they are still early in the process of learning to use the system, so it may not be clear even to the authors to what extent this is usable in real systems. But certainly the performance hit demonstrated is a serious consideration, despite their efforts to minimize it. On the other hand, the fact that they were easily able to test remote vs local calls demonstrates to some extent the success of their effort to implement stubs that transparently translated local calls into remote calls.

5. Confusion

What is the transmission column in their table, it is not clear what this means. They claim that it is the total packet transmission time. Based on this description I would have expected in the no args/result case the transmission time would have been close to the total elapsed time, which it quite clearly isn't. Nor could the difference between it be because of processing time for the call itself since that should be reflected in the time the local version of the call takes.

Summary
The paper introduces a remote procedure call facility for the Cedar project. It can transfer control and data across a communication network, while keeping clean and simple semantics. This paper includes a discussion of some issues, and describes the overall structure, the binding mechanism and the transport level communication protocol.

Problem
The RPC facilities had design issues including: the precise semantics of a call in the presence of machine and communication failures; the semantics of address-containing arguments in the absence of a shared address space; integration of remote calls into programming systems; binding; suitable protocols for transfer of data and control between caller and callee; and how to provide data integrity and security in an open communication network.

Contribution
1. Stubs and RPCRuntime make programming easier by relieving programmer from detailed communication-related code.
2. The naming of an interface includes the type and the instance. The system uses the Grapevine database to locate an exporter from the interface name. Importing an interface has no effect on the data structures in the exporting machine. Use of the unique identifier scheme means that bindings are implicitly broken if the exporter crashes and restarts. This scheme allows calls to be made only on procedures that have been explicitly exported through the RPC mechanism, improving security.
3. They designed a packet-level transportation protocol. Acks are used when it's multi-packet or the results have not returned by the callee for a long interval.

Evaluation
The measurements were made for remote calls between two Dorados connected by an Ethernet. They present elapsed time for the RPC calls and compare it with time for local calls.

Confusions
Java also provides RPC package. I wonder what's the similarity/difference between the RPC implementation in java and the mechanism used in this paper.

Summary: This paper introduces the design decision of the remote procedure call system for use in Cedar environment. The issues are: 1. Binding (identify the address and identity of callee). 2. Suitable protocol for transferring data and control. 3. Data security when running in open network. 4. Integrating RPC into existing programming systems.

Problem: Distributed computing can achieve the performance of supercomputer by collection of comodity computers. The key to distributed computing is the underlying distributed communication protocol. This protocol should be easy to use (as programming on local computers), efficient, and secure.

Contributions: The contribution is mainly on addressing.
1. They use stub and runtime to pack/unpack and transmit the data package so that RPC is just like a local call.
The structure is client - client stub - runtime - network - runtime - server stub - server. The programmer only cares the client side.

2. The identification of machines are done by a distributed database called Grapevine. By Grapevine, the programmer does not need to remember the address of each machine, only need to remember the name of each machine in Grapevine. It is much more convenient.

3. This paper has its own packet-level transport protocol to achieve better performance for RPC. This protocol is simplified for transmission efficiency. ACKs are only necessary when the data has more than one packages.

4. End-to-end encryption of data, They use the DES encryption algorithm.

Evaluation:
They benchmarked the RPC transmitting speed under different number of arguments and return values. They compare this speed with the local calls. It is about 100-150 times slower than local calls.

Confusion: I still do not understand why RPC is much more efficient, some comparison between different RPC protocols may be necessary.

Summary :
The paper talks about remote procedure calls, their implementation for use in the Cedar environment, the transport layer protocol for communication, the optimizations in the RPC mechanisms and the performance evaluation of the RPC calls for various workloads.

Problem :
To enable processes on different machines to communicate in a distributed environment using RPC, the main design considerations include :
Efficient semantics of the procedure call
Binding the caller to the callee
Protocol to transfer data between the caller and the callee and vice versa
Security in the communication
These issues are addressed in the implementation of RPC.

Contributions :

1. Easy programming for the user as the user can concentrate mainly on the user and the server programs and the stubs on the user and server side are automatically generated by the lupine program from the designed interface.
2. The server exports the interface of a specific type and instance and these details are stored in the grapevine distributed, replicated database. The RPCRuntime on the exporter machine stores details about interface and dispatcher procedure indexed by an unique identifier.
3. The client binds to the required interface by obtaining the details from grapevine based on type and locates a nearest instance exporting that interface. Once the connection is established, the calls can be made.
4. Access control policies on grapevine provide a means to restrict which users can export the interfaces.
5. Simple calls fit all arguments in a single packet and are more frequent. The receipt of the call packet creates the connection and no two way handshake mechanism is used. Complicated calls having large arguments use multiple packets with ACK for each packet. Duplicate elimination done by using call specific sequence numbers.
6. Probes the server with probe interval decreasing gradually over time thus being able to detect any server/communication failure faster.
7. Maintains a pool of idle server processes that can serve requests to avoid overhead of process creation. The calling process on subsequent calls uses the process identifier that it learns from the response of the first call.
8. Use grapevine as the authentication service and provides end-to-end encryption of the request and response.

Evaluation :
The RPC implementation has been evaluated for a couple of messages of different sizes and the minimum time taken for the entire RPC call from the invocation until the response has been recorded. However, the evaluation is limited and does not compare the performance of the system with one without including some of the optimizations in place.

Confusion :

The ACK mechanism for complicated calls in which every packet but the last requires an ACK is not that clear. Do they exist other RPC implementations that use TCP as the transport layer protocol and how do they perform ?

Summary

This paper presents the idea and implementation of RPCs as an analogous paradigm to local procedure calls but for transfer of control and data between programs running across a network. It describes the design choices made about the semantics of a call, binding of calls to procedures, transport-level communication protocol and the various optimizations made for efficiency purposes.

Problem / Goals

The primary purpose to develop RPC is to make distributed computation easy, such that the underlying complexities of distributed communication are hidden from the designer of a distributed system. It provides programmer ease because they can write the programs in high-level language in almost the same way as they write programs for local execution. The authors also wanted to make the RPC communication highly efficient and secure.

Contributions

The paper provided a detail description of the design of a RPC system. The main aim guiding the structure of the design was to provide semantics of remote procedure calls as close as possible to those of local procedure calls. The five pieces of program when running over RPC are described: user, user-stub, RPC runtime, server-stub and the server. Auto-generation of the user-stub and server-stub by Lupine makes the task of the programmer very easy. The programmer only needs to design the interface and write user and server code and the rest is handled by the RPC system.

Two aspects of Binding are discussed: Naming and Location. An importer of an interface uses a 'type' and 'instance' of the interface to bind to an exporter of that interface. The grapevine distributed database provides a way to locate the exporter of the interface. It also acts as a middle layer that decouples the importer from the exporter.

They developed a transport protocol that maintains very limited connection state and is very efficient for the request-response nature of the RPC communication.

Evaluation

The authors measured performance by varying number and varying array sizes for arguments and results and presented the comparison to the latency in a same but strictly local procedure call. The tests were performed for remote calls between two Dorados connected by an Ethernet. They could have also evaluated the time-taken for name-resolution of an interface.

Confusion

How are the Mesa language exceptions handled, both in local and remote execution?

1. summary
In this paper "Implementing Remote Procedure Calls", the structure and design of the RPC protocol implemented in the Cedar project is presented. They address the following issues when designing a RPC facility.
- Binding (how caller determine the location and identity of callee)
- Suitable protocol for transferring data and control
- Security when transmitting in open network
- Integrating RPC into existing programming systems
2. Problem
The main purpose of this project is to make distributed computing easier. During the time when the paper was written, the existing communication frameworks constrained the development of distributed systems. Substantial work was needed to build programs communicating over the network. So they wanted to build this RPC project which will provide communication between programs with almost as much ease as local procedure calls.
3. Contributions
The major contribution is the design of RPC system. The general structure is as follows, when a remote call is made, [user->user_stub->RPCRuntime] -Network- [RPCRuntime->server_Stub->server]. User and server stub is responsible for marshalling and unmarshalling the parameters respectively. RPCRuntime is responsible for reliably transferring the packets in the network. When writing a distributed program, user only needs to write a interface which client imports and the server exports, Lupine creates the user stub and server stub from the interface for the user.
This paper focuses on Binding and Packet level transport protocol of the RPC system in detail.
Binding-
- Name of the interface = type + instance
Locating a Exporter-
- Grapevine DB is used as a lookup table. It holds two types of record (individual and group)
- individual - {interface instance, network Add}
- Group - {Interface Type, List(instances)}
When a interface is exported, the instance is registered in the Grapevine DB with the machine address of the exporting machine. When a call is made this table is looked up to locate the Exporting machine.
Packet level Transport Protocol-
- Call ID = {machine number, process id, seq number}
- each activity(machine #, process id) can have only one outstanding request at a time.
- Sequence number is used to identify duplicates. A table containing the latest seq # for each activity is maintained.
- For single packet calls or very short calls no ACK is needed explicitly(call and result serves this purpose).
- For complicated calls packets are ACKed. If ACK is lost the RPCRuntime of the packet's origin retransmits the packet.
Security-
- Encryption based security is provided but implementation details are presented in a following paper.
4. Evaluation
Experiment results, showing the time taken for RPC calls between 2 machines are shown. No comparison between other RPC like systems is presented, but they re compared against local procedure calls.
5. Confusion
Out of curiosity, Did this Packet level transport protocol lead to the development of TCP and UDP ?

Summary
This paper describes key concepts and an outline of the Remote Procedure Call (RPC), which enables a user or a program to invoke another procedure on different computer using via network communication with simple interface. The paper also provides explanations of their design decisions, such as opting for "clean and simple semantics", considerations for efficient communication over a network, program structuring conducive to RPC, and provisions for data protection.
Problem
The main purpose behind making this RPC package was to make distributed programming easier. The authors hoped that by providing easy communication as a local procedure call, programmers would start experimenting more with distributed systems. Another goal the paper was 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.
Contributions
The authors propose a RPC which is as close as possible to local procedure call by providing simple, powerful API and efficient and speedy communication mechanism and architecture. Getting rid of time-out mechanism is one of an example for making the API simple instead of making a fancy interface customized for network. These simple interface also encourages programmers writing a program for a distributed computing environment. The authors propose using Grapevine 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 constraints. The paper also presented a number of implementation details and a network protocol used to increase performance of RPCs. The transport protocol is highly tuned for small packet transmissions, ex. ACKing every packet. An idle process pool is used on the server in order to avoid process creation and teardown delays. Subsequent requests are directed towards the same process using the process identifier. Allowing one less ack in the common case.
Evaluation
The author measured the average performance of the RPC calls over 12000 iterations and compared it with the time taken for the local call. But surprisingly they did not provide the data for the optimizations they discussed. The authors could have evaluated the performance of RPC for various other optimizations like Latency vs number of server idle process, latency vs network traffic etc.
Confusion
The paper says "probe packet issued after a delay slightly more than approximate round trip time". How would it calculate the round-trip time ? will it measure average round-trip time before every RPC call?

1. summary
This paper introduced its design and implementation of the overall structure and semantics of the mechanism - remote procedure call. Particularly, the paper described the mechanism of binding RPC clients and an innovative transport level protocol designed for RPC use. Some desired features are mentioned in this paper, such as exception handling, efficiency and security. A performance measurement presented in this paper proved their RPC implementation is fairly efficient in most cases.

2. Problem

• The major problem discussed in this paper is that the present communication mechanism makes it hard for researchers to build distributed systems. With an easier-to-use communication mechanism, researchers and developers might be more motivated to build and experiment with distributed applications.


• A secondary problem is the efficiency of RPC communication. The tension between powerful semantics and efficiency always exists. However, expensive communication scares application designers of using distributed systems.


• Another problem is security in an open network for RPC. Data protection becomes more and more important. Yet previous distributed systems hardly provides secure end-to-end communication, and it was never applied to RPC.

• The paper introduced the concept of an interface module, exporting an interface and importing an interface. The major components in the system are the stub and RPCRuntime in both callers and callees. RPCRuntime takes care of the network communication part, and the stub is responsible for packing arguments and unpacking results. This design is intended to make it easy for programmers to build applications.


• The paper also described its binding mechanism in detail. Naming and location issues are specifically addressed. An interface name consists of the type and the instance. And location information is stored in Grapevine database.


• This paper designed its own packet-level transport protocol to achieve better performance for RPC. The protocol they designed is like a light-weight TCP with no explicit connection setup and teardown process nor packet ACKs when call duration and intervals are less than the transmission interval. The paper argues that there is no bulk data transfering for RPC, thus performing expensive handshaking and storing a large amount of state information is not worth the effort, instead, we want to minimize the elapsed real-time between a call and getting return values.

5. Confusion
Didn’t quite understand binding part. There’re too many terms making it very confusing.

1. Summary
The paper introduces the concept of remote procedure call, the process of invoking a procedure call on a remote machine. It then proceeds to describe the design and implementation of the remote procedure call package in Cedar programming environment.

2. Problem
To design an efficient remote procedure call framework, which is easy to use for creating distributed applications and is as close as possible to local procedure calls semantically.

3. Contributions
To achieve its goals, the remote procedure call package includes a code generation piece that lets programmers specify interfaces for procedures (name and types of arguments and results), and generate stub code to serialize/deserialize the procedure request/response and handle the communication between the client and server. To solve the problem of binding clients to servers, the remote procedure call package includes methods to register and query exported interfaces. It is uses a distributed database to store the list of interfaces and their implementors. It uses a custom packet communication protocol designed for the workload of remote procedure calls instead of the standard one. The protocol minimizes the time taken in initiating the call and getting results by avoiding a connection setup (2-way handshake) during every call. The protocol also tries to minimizes the load on the server by using minimal state.

4. Evaluation
The authors evaluated the system by measuring the latency of remote procedure calls of various configurations between two machines in a network, and comparing this time with the time to transmit and time to execute the procedure locally. They also measured the peek data transfer rate while using multiple remote procedure calls in parallel, and noted that it is same as the rate achieved by their optimized byte stream implementation.

5. Confusion
The discussion on authentication is unclear in the binding section.

Summary:

This paper discusses in detail the implementation of Remote Procedure Calls (RPC). The authors describe the design decisions that affected their implementation, the mechanism of binding and the transport protocol designed at packet level to achieve the RPC semantics. They also talk about the security and the performance of the implementation of RPC.

The primary objective was to make distributed computing easier. The challenge lay in designing the RPC structure such that it is simple to use and augment the programming model already present. Also communication had to be efficient as any delay would result in unwanted overhead. Another major problem was to make the communication secure. There exists significant challenge in binding the caller to the machine which provides the service in terms of location and naming. Also, how does one handle complicated and large arguments and how to modify the network to get the maximum efficiency and minimum overhead?

Though RPC faces the same challenges as message passing, RPC has an advantage of simplicity as the computation is performed like a normal procedure call. Since the stubs are automatically generated by the Lupine program and RPC Runtime take care of communication and binding, there is not much over head for the users thereby reducing usage complexity. Using the Grapevine’s database the exporter of a service is identified easily by mapping the RName to the machine’s network address or to a list of RNames that map to all the exporters. The dispatcher handles the export of an interface independent of the procedure in the server thereby reducing the complexity in exporting a procedure to remote clients. The RPCRuntime at caller side binds directly to the exporter using network address thereby avoiding communication with Grapevine. Access control to Grapevine’s database provides security a new exporter cannot update it with its own interface. By using a special packet level transport protocol, the needs are tailored to the semantics of the RPC. Since frequent communication would take and no bulk data is involved, the transport protocol is designed to minimize the time taken to send and receive packets. For simple calls, the result serves as acknowledgement and a very little state information is maintained and shared state connection is used. For complicated calls, explicit ack is requested using probe packets using which the caller can identify a crash of callee. Exception packets can be communicated to the caller which is similar to a local procedure. By maintaining a list of idle processes to handle a procedure call, the overhead for process creation is avoided. End to end encryption of calls and results improves security.

The authors measured the performance of their implementation on a light load network but did not compare with other similar mechanisms. They only compare it with local calls which are faster as expected. The paper discusses more about the design decisions and wide evaluation is not done. Since it is tested in a closed network, the actual result could vary in other networks. Also the cost of exporting or importing is not measured.

How does corruption of data during transmission tackled? Also, what happens when the procedure wants to access some global data in caller or make changes to it?

Summary: This paper introduces the implementation details of of remote procedure calls (RPC). RPC is a language that enables a program making calls to procedures located on other machines in the network.

Problem:
1. Distributed systems have many advantages. However building a distributed system is not easy because programmers need to handle communications over a network. Because of the unpredictable nature of network communications and the fact that no simple and easy to use communication mechanisms existed at that time, many people refrained from building distributed systems.

2. Existing network protocols were not efficient enough for the purpose of RPC.

3. Security: none existing protocols provided encryption.

Contribution:
1. Making RPC transparent to programmers. Making a RPC call in Mesa is just the same way as making a local call. The semantics of RPC is also similar to the semantics of making a local call. For example, making a RPC call does not impose any timeouts; in case of network failure an exception of Mesa language will be thrown.

2. Naming mechanisms. They used Grapevine's naming services to provide naming mechanisms in RPC. One does not need to know the address of the remote machine to make an RPC call; instead providing its name is sufficient. This adds much more flexibility.

3. Packet-level transport protocol. The authors designed a specialized protocol for RPC which can achieve an up to 10 times performance gain over PUP. This was the most complicated part of this paper and I did not fully understand this part yet.

4. End-to-end encryption support. The encryption algorithm they used is DES.

Evaluation:
They measured the performance of RPC against the performance of local calls with different message size. They showed that making an RPC call is 10-100 times slower than making a local call, depending on the number of arguments and whether an exception is raised or not.

Confusions:
1. What is PUP?
2. TCP protocol originated before this work was done. Why didn't the authors choose to use TCP to implement RPC?

Summary:
This paper presents the implementation of Remote procedure calls (RPC) designed for enabling easy communication between programs in a distributed network through normal procedure calls. It uses a user-stub to replace the procedure being called on the user-side and a server-stub to emulate the caller on the server-side. The paper also discusses the semantics of the RPC and also presents a description of the packet-level transport protocol used to transfer data from the user to the server.

Problem:
At the time of authorship of this paper, the construction of communicating programs was considered a major burden. Inspite of having all the resources available to build powerful programs, the lack of communication mechanisms across a network served as a major obstacle in the development of distributed applications. To overcome this problem, the idea of RPC was conceived.

Contributions:
The authors use a modular approach in implementing RPC. There is a caller that makes the call and a callee that services the call. There are 5 core pieces of code : user, user stub, RPC runtime, server stub and server. The stubs and the runtime help in making the RPC appear like a local procedure call. A program called Lupine takes care of generating the stubs. Only the user and server code needs to be taken care of by the programmer.
Grapevine offers reliability using redundancy. Grapevine is distributed database that maintains a record of servers that export an interface among other peripheral data. Grapevine also offers security in terms of authentication service to prevent eavesdropping.
Another contribution is that the authors minimize their costs of maintaining connections by not expecting ACK packets at all times.

Evaluation:
The paper does not provide a lot of results in the form of evaluation. It would have been nice to see some comparison against other non- RPC mechanisms.

Confusions:
How are deadlocks resolved?

1. Summary
The authors describe a mechanism for making function calls that are executed on a remote machine, with the result being returned to the local machine. They cover some of the implementation details, as RPC has not apparently been implemented at full scale yet.
2. Problem
The authors were looking to make distributed computation easier. Communication mechanisms such as message passing were already in existence, but were not sufficiently easy to use and required "communication experts" to develop distributed systems. RPC looked to simplify the design of distributed applications and lower the barrier to entry.
3. Contributions
Remote procedure calls should mimic local procedure calls as much as possible. No timeouts, and all packet routing/retransmission is handled by the separate RPCRuntime. The programmer only needs to write user and server code and call them like normal functions.
They provide facilities that take care of the task of finding nodes that are capable of running procedures and verifying that they are who they say they are. This all happens without the user of RPC needing to write large amounts of networking boilerplate.
Also developed was a new packet level transport protocol that avoided overhead by not sending ACKs at all times, only when sending large message sizes or during waits of longer than the transmission interval.
Exceptions are handled by the use of special exception packets which are returned to the RPCRuntime and raise exceptions for the local process.
4. Evaluation
The authors provide some simple benchmarks of their RPC implementation using differing numbers of arguments and return values, and compare the data transmission speed achieved to raw byte streams over the same network.
They did not measure the time used to export or import and interface, which although it might be a one time procedure in many programs seems like something that would be useful to quantify.
5. Confusion
The use of Grapevine to provide security and prevent MITM attacks confused me. I'm not sure how the use of a secure protocol when interacting with Grapevine prevents fake clients or servers being registered.

1. Summary
The paper describes how procedure calls were implemented for a distributed system of machines since the called procedure will be in a totally different, non-shared address space. Thus the authors describe how they pack the arguments from the caller and securely call the correct callee across the network.

2. Problem
At the time of writing the paper, there wasn’t a common agreed protocol for communication between distributed systems. Different programming languages used different formats and this hindered the scientists to exploit the full advantage of working with distributed networks. Thus the authors present a protocol for remote procedure calls with their language Mesa. They prefer procedure calls to message passing although they state that one has no significant advantage over the other.

3. Contributions
a) On invocation of a procedure, the caller packs its arguments into a client stub and sends it over the network to the callee which receives it as the server stub and unpacks it to get the original arguments.
b) Binding to the correct callee is achieved by specifying the name of the callee as type and instance. The Grapevine distributed database is used to search for an available server and bind it to the calling client.
c) Simple calls consist of just one packet transmission from the transmitter and thereby receiving an ack from the receiver. In case of complex calls, more than one packet is needed to be sent to the receiver to transmit all the data (arguments).
d) Since the receiver sends an ack only to notify that it has received the packet and no further data is sent from the receiver until the end of the call, deadlocks can be significantly bad.
e) The waiting and receiving are done by running processes on the client and the server respectively. These processes are pushed to an idle state in case of completion as forking a new process is time consuming.

4. Evaluation
Evaluation was done on Dorados machines with the Cedar programming environment. Since there was no benchmark data to compare against, the data that is presented is just analysed to show a contrast between RPC and local calls that do not involve an RPC package. It is seen that doing an RPC is about 100-150 times slower than a local call.

5. Confusions
The ImportInterface and ExportInterface were particularly confusing as to what their actual purpose is.
What is the unit of time for their results? Seconds?

1. Summary
This paper introduces the implementation, performance of Remote Procedure Calls(RPC) and related transport protocols, based on previous work done by others.

2. Problems
The paper tries to design a system with novel aspects to solve the issues such as the precise semantics of a call during machine and communication failures; the semantics of address-containing arguments in the absence of a shared address space; integration; binding; suitable protocol design and data integrity and security. This paper also points out that reliability and efficiency problems exists in the practical use of RPC.

3. Contributions
1. Similar structure used as stubs.
2.A binding mechanism that interfaces are specified by type and instances. Taking advantages of Grapevine’s database. Bindings are implicitly. Importing an interface has no effect on the data structure in the exporting machine. Make good use of Grapevine’s access control.
3.New protocol introduced to achieve efficient communication. Simpler mechanism in transmitting a single packet buffer; use probe packet to detect and react to communication failures; emulates Mesa mechanism to handle exceptions; creating processes carefully to avoid unnecessary cost of resource. Other optimization includes treating RPC packets as a special case and receive them by the way of bypassing layers; encryption-based mechanism is provided for security protection

4. Evaluation
There is a section particularly for evaluation in the paper. The measure, as the author declared, is accurate to within ten percent. However, the network was just lightly loaded, which maybe a flaw in the evaluation. As to the result, other protocols perform better than RPC when transferring large amounts of data. Nevertheless, interleaving parallel remote calls also achieve good data rate on Ethernet. Other aspects such as the cost of exporting or importing an interface have not been measure because they are dominated by the time used for talking to Grapevine server.

5. Confusions
Isn’t it very similar to a remote desktop? Is a remote desktop more compatible on different machines and OSes?

Summary:
The paper describes design decisions and implementation of a package providing remote procedure call, which allows remotely calling procedures on distributed systems. The idea was to use the semantics for passing arguments and data similar to a local procedure call and also minimize the latency in doing so.

Problem:
How to make RPC transparent to the programmer and highly efficient at the same time ? What happens during machine failure? Another challenge discussed in the paper is ensuring data security and implementing RPC when there is no shared address space. Overall, the paper discusses making RPC efficient and similar to local procedure calls.

Contribution:
Structure of RPC: The primary idea in the paper is the structure of RPC communication. The authors describe the contents of the structure, which consist of user, user and server stubs and RPC runtime. Each of these components interact with each other to achieve low latency RPC communication using packet data transfer. It does not involve any network programming from the user.

Binding: The authors describe binding as important to understanding which server at which location (i.e. name and location) needs to be called by the client. The process of resolving this is done by using a grapevine database and import and export calls by the client and server respectively. When the server calls export, and instance of type is added to the database. The client can access this using import which gives the IP address of the server exporting that function. The grapevine database is maintained as a distributed database.

Simple and Complicated call protocols: The authors evaluate the semantics of data transfer and latency and bandwidth and come up with ideas on how to best implement RPC. To avoid high latency with TCP, the authors propose stateless server protocol. In simple calls, all arguments fit in a single buffer and an acknowledgement is not required since it would impact performance. If it gets the result, the client assumes the call was successful and similarly, if it gets another call, the server assumes that the result reached the client. Complicated calls consist of long arguments where all packets except the last one are sent with request for acknowledgement.

Evaluation:
The authors provide some evaluation results for certain arguments implemented using two systems but do not compare them with other types of mechanisms such as message passing. Explicit results for concluding to avoid using TCP are not shown. The authors mention that they interleaved parallel remote calls from multiple clients, which might be a cause for the speed up achieved.

Confusions:
This question came up at our discussion: for a distributed computation consisting of large data, how is the communication latency hidden or avoided? How effective will be TCP in this case?

1. Summary

This paper introduces the concept of Remote Procedure Calls (RPCs) and discusses in detail the implementation of an RPC mechanism in the Cedar environment.

2. Problem

Distributed computing was being held back by the difficulty of building mechanisms for communication between programs. Hence, by providing an easy communication mechanism that mimics procedure calls (which are well-understood), it was hoped that developers would be inclined to build more distributed applications. There was also a need to make this mechanism highly efficient in terms of latency and at the same time provide maximal functionality. Finally, it was also important that this mode of communication was secure and protected the data transferred.

3. Contributions

The major contribution of the paper is to present some novel ideas used in the implementation of the RPC mechanism.

Structure
--------
- There are 5 main components - user, user-stub, RPC communications package, server-stub, and the server. The user is the process making a remote call. The user stud is responsible for specifying the target procedure and arguments in one or more packets. The RPC transmits the packets. The server stub unpacks these and makes the corresponding procedure call in the server.
- A program called Lupine is responsible for auto-generating the server and user stub from an interface module (list of procedure names, together with the types of their arguments)

Binding / Naming
--------
- There are two parts to the name of an interface: the type and the instance.
- A Grapevine database (distributed database) contains entries mapping interface types and instances. For each instance, there is a connect-site(network address)
-

Transport
--------
- A custom transport protocol was built for RPC with emphasis on minimizing the elapsed real-time between initiating a call and getting results. Existing protocols are built for bulk data transfer and so incur high overhead in the setup phase. However, this is untrue for RPC.
- Packets are tagged with a caller identifier which allows the caller to ensure the packet is current and the callee to eliminate duplicate packets.
- Acknowledgements have to be sent for all communication between the caller and the callee to account for lost packets. If no ack is received, the sender keeps sending the packets.
- The caller periodically sends a probe packet to the callee while waiting for the result packet. If there is no response from the callee,
it is assumed the callee has crashed or if there is some serious communication failure. There is no timeout in the connection. Hence, we do not have any way to be notified if the callee is stuck in a loop or deadlocked. This is so as to mimic the operation of a procedure call.
- The process on the server machine may send exception packets in lieu of a result packet. An exception is then raised in the caller machine.
- Each packet contains a process identifier for source / destination. This can be used by a caller to transmit a packet to the same process on the destination that handled the previous call.

Security
--------
- Facilities are provided for encryption based security.

4. Evaluation

The authors note that the RPC communication implemented through the custom transport protocol can derive a performance gain "of a factor of ten" over existing transport protocols. They also provide some timings for RPC communication over a range of data and argument sizes. However, they do not include any comparison between RPC and any other form of interprocess communication between 2 process on different networks. So it is difficult to gauge the efficiency of their implementation.

5. Confusion

I did not understand much about the part about bindings. What exactly is a binding, what components are binded together and what is the binding needed for?

Summary
In this paper, the authors describe in depth the design and implementation of remote procedure call (RPC) package developed for Cedar programming environment. RPC conveniently provides a way to transfer and control data across a communication network. Design decisions for developing this paradigm have been discussed. The authors focussed on designing an efficient procedure that will allow secure distributed communication, while keeping the semantics simple and easy to use.

Problem
The paper identified already existing problems posed by RPC methods. Distributed computation was cumbersome and not straight forward to implement. Other issues included semantics of arguments passed in the remote call, locating the identity of the callee, suitable transfer protocols between caller and callee and few more. The authors make an attempt to address most of these challenges in this paper.
Contribution –RPC made it easy to invoke a program. The user-stub interface is same as the actual procedure call interface such that the stubs could be plugged into existing programs without modifications. Lupine program packages the arguments, sends them to remote system and also synchronizes the client process. This helps to keep the semantics simple and hidden from the end user. The paper describes the specialized network protocol that was designed for RPC communication. Latency is reduced as the communication does not require a two way ACK. The Grapevine distributed database attains reliability using redundancy. It keeps track of interfaces being exported by systems on the network. It was also used to balance the load between servers exporting the same interface. A secure connection was made possible using Grapevine as an authentication service which provided encryption to call and result packets.

Evaluation
Time measurements for RPC communication between two hosts connected via Ethernet are done by varying the size of arguments and results. Time measured is the time taken between invoke and return of the RPC call. Similar findings are done for a local procedural call. For this paper, latency and throughput could have been measured more rigorously for the sake of conclusion.

Confusion
There is no existence of the timeout concept in RPC. What is the consequence of this feature? If we don’t have a timeout, what can go wrong in worst case scenario?

Remote Procedure Calls -

Summary:

The paper implements remote procedure calls (RPC) as a way of communication and data transfer across a network. They provide the semantics of a call in RPC handling machine and communication failures, semantics of passing arguments, determining the location of the procedure and binding, and finally, provide suitable protocols for transfer of data between the caller and callee.

Problem:

Just like multiple programs on a single computer may communicate with another passing arguments and get back desired results, the program, one wants to communicate with may be available on a different machine and hence a fast mechanism needs to be provided so that one could use a service provided across a network.

Contributions:

The paper implements RPC as a paradigm to make remote calls into a procedure claiming the fact that programmers are used to developing programs making procedure calls locally and the same can be extended remotely too thereby making distributed computation easy.

To make a procedure available remotely, the procedure is first exported providing the network address to communicate to or provide the type and instance that a client can communicate to. A server-stub is provided on the server side, which marshals and unmarshals packets depending on whether it is being sent or received respectively. Similarly, a client-stub performs similar operations on client side.

Instead of using available network protocols to communicate, they develop their own protocol where no explicit ack is used for simple calls. The result response from server is considered as an ack. In case of complicated calls, where the arguments are large, an explicit ack is requested to make sure all packets have been received. Sequence numbers are used to uniquely identify packets thereby avoiding duplication. Each client is identified uniquely by a call identifier and the server maintains the sequence number for each call identifier. They also reduce the number of process switches by running idle server processes and using an interrupt handler in case a particular packet is received.

Evaluation:

The paper clearly evaluated all the problems that one might face when making RPCs and provided optimization which makes sense in most scenarios. The performance metrics support their claim that these optimization provide a certain improvement in remote communication avoiding certain unnecessary cost in connection establishment and unnecessary acks.

Confusion:

1. Not much is explained about ptr like data structure and how they are handled. What would be the best way to handle ptr like procedures?
2. How is the authorization done between client and server? They don't use the password mechanism. What kind of ACL is maintained?

Summary:
This paper talks about the design (and optimizations there-in) of a remote procedure call mechanism for the Cedar system.

Problems/Motivation:
The authors feel that making procedure calls the basic mechanism for communication in distributed applications will appear to be a natural extension for developers used to building local applications and the ease and efficiency of this approach will lead to more distributed applications being developed.

Contributions:
Important ideas regarding the design of RPC, that are presented in the paper are:
- Automatically generated stubs on client and server side for packing and unpacking arguments and a RPC runtime which handles communication protocol level details, allowing programmers to focus on the actual application.
- A communication protocol that avoids acknowledgements ( unless specifically requested) and maintains minimal state ( just sequence numbers to avoid re-processing duplicate calls) so as to efficiently serve a lot of clients.
- A binding mechanism that uses an installation of the distributed grapevine system to dynamically bind the location of an instance of an interface's implementation.
- A pool of server processes among which an interrupt handler multiplexes calls so as to avoid the time spent for creating processes on demand.
- An exception handling mechanism that is similar to Mesa semantics in that exceptions thrown on server can be handled on the client and the control can (possibly) return back to the server (transparently to the application) once that is done.

Evaluation:
The authors present the basic details about the time taken for various types of procedure calls (actual transmission time, minimum/ maximum time for RPC, local execution time etc.) . But they do not compare their design and implementation against any existing system ( including other paradigms such as message passing) to actually determine the effectiveness of their approach.

Confusions/Clarification:
In your opinion between message passing mechanisms and RPC , which has been more successful in modern distributed applications and for what reasons?

Summary:
The paper presents the idea of extending local procedure calls to communicate over a network i.e. remotely. It discusses the RPCruntime package developed, naming and binding mechanism used to [...], transport protocol used for faster and efficient communication, various design designs optimizations such as implicit acknowlegements, minimizing cost for connections.

Problem:
Authors note that distributed computation is not easy, communication is difficult. The author aims to develop remote communication protocol which is easy, simple, efficient, secure and resembles local procedure calls in semantics.

Contributions:
1. Development of remote procedure call runtime package with semantics similar to local procedure calls, development of stibs to auto generate code, library to facilitate remote communication.
2. Binding mechanism (interface type and instance) and grapevine to keep track of exported procedures.
3. RPC specific transport protocol optimized to minimize communication cost by eliminating ACK packet for simple calls; lower processes setup cost (at both ends) by maintaining a pool of idle processes at server.
4. Divide larger calls into muliple smaller calls eliminating the need of large buffer on both ends for arguments and results.
5. Encryption based security to prevent eavesdropping, replay attacks, modification and creation attempts. Existing remote communication protocols did not consider security aspect while communicating.

Evaluation:
The paper provides a limited evaluation of RPC mechanism. Measurements have been provided for varying number of arguments and result sizes and latencies have been cmpared with local procedure calls.

Confusions:
- Could not understand the conversion identifier concept for secure calls.
- How is it antcipated that a call would be simple or complicated? Can a procedure call be simple at one time or complicated later based on arguments passed?
- In use of processes sections, it is mentioned that caller process can use a previous destination identifier for the callee process on the server. Isnt it too optimistic, what if the process has been killed (as it was one of the excess processes) or the server is deadlock.

Summary:
This paper presents design and implementation of efficient RPC package developed for communications in Xerox research inter-work. The author discusses binding mechanism and transport level communication protocol in detail.

Problem:
Construction of communicating program for distributed environment was difficult task as semantics of existing RPC were complex. Implementation of existing RPC mechanism were not efficient as they involve expensive process creation and swapping time. No security was enforced in previous implementation which resulted in even passing passwords over network as plain text.

Contribution:
1. Major contribution of this paper is making semantics of RPC as close as possible to those of local procedure call which made programmer's life easy.
2. Lupine was responsible for generating stubs which took care of packing and unpacking of arguments. RPC run-time was responsible for packet-level communication. Thus only job of programmer was to generate interface module and write user and server code which was similar to writing code on single machine.
3. Grapevine database was used for name resolution also provided authentication for RPC. It controlled who can export interfaces and who can access it.
4. New transport protocol was introduced which removed need of sending ack packets in simple calls, results acted as ack.
5. Communication was made efficient by removing cost of process initialization. When server process has completed its task it is reverted to idle state instead of dying. Number of process switches involved in RPC were reduced thereby saving process swap cost.
6. Full end-to-end encryption was provided for RPC calls and results which made communication secure.
7. Implementation of RPC provide exception propagation back to the client. Execution continued depending on exception handled in client code.

Evaluation:
There is little evaluation presented in this paper. Performance comparison with existing RPC implementation would have helped. It shows minimum time required for different number of arguments and compares it with time required for local procedure.

Confusions:
I am not sure what make call complicated? If number of packets used for arguments are more than one, we call call complicated or is it something different?

Summary:
This paper discusses the structure and design rationale of Remote Procedure Calls (RPC) implemented for the Cedar programming environment between a network of hosts in the Xerox research internetwork. Mechanisms for binding and locating hosts for an RPC along with the implementation of a lightweight transport protocol are discussed in detail.

Problem:
The primary motivation of the authors’ work in this paper was to make distributed computing easier from a programming perspective, by emulating procedure calls across remote hosts. The idea of RPCs had been formulated before this so the aim was to make them efficient so they would be in a reasonable order of the network transmission time. Secondly they wanted to keep the RPC semantics as close to a regular procedure call as possible so programmers would not have to incorporate additional complexity to achieve the same functionality.

Contributions:
A distributed database from which clients could locate the required interfaces reduced the load on the servers who were implementing or exporting those interfaces. By allowing group and individual entry types in the database, there is the flexibility of either letting the RPCRuntime locate the closest exporter of the interface or having the client specify the exact exporter via an instance for that interface. The unique identifier scheme allows for server crashes to be easily resolved without informing the clients explicitly. Compared to standard bulk transport protocols the RPC packet transport protocol is optimized by its requirements to be lightweight. Only minimal state needs to be maintained when the client server connection is idle and no heartbeat messages are required to keep the connection alive in the idle state. Tearing down a connection is much simpler as well as the server only needs to discard the client state without explicit communication. All of this leads to reduced traffic. Other optimizations like using the resulting packet and reusing the previous server process id for acknowledgements of previous packets also reduces the total number of packets needed.

Evaluation:
The authors provide measurements for RPCs between two hosts directly connected on a network via an Ethernet link in relatively light load conditions of 5-10% capacity. The time measured is the time between invoking and returning from an RPC. The minimum and median times are given for various argument and data sizes for each RPC along with the time it would have taken on a local call. The RPC latency is roughly between one to two orders of magnitude of the local calls. The authors do not expound much on the conclusions drawn from the data, probably because that was already covered in an earlier thesis paper on the subject.

Confusions:
I did not understand the bit on why sequence numbers in the calls from an activity are monotonic but not sequential.

1. Summary
In this paper, the authors discuss the design and implementation details of Remote Procedure calls (RPC), including the semantics of the call and the communication protocols.
2. Problem
The purpose of RPC is to enable distributed applications to run on an interconnected distributed system. The major issues for design of such systems are: integrating remote calls into existing programs, providing suitable light weight and reliable protocols for transfer of control and data, providing data integrity and security, simple and efficient semantics of the calls for binding, failure recovery and enabling argument passing for non-shared memory systems.
3. Contributions
The primary contributions of this paper are the semantics of RPC program and communication protocols for remote data and control transfer.
The RPC infrastructure is based on the concept of stubs, with an RPCRuntime handling the packet transmissions, retransmissions, acknowledgements, packet routing and encryption. A caller imports an interface, whereas a callee exports it. A grapevine distributed database is used to bind the caller with the callee. The callee provides the caller with a unique ID which is used for validating and failure checking when subsequent calls made to it.
The proposed communication protocol avoids the overhead (state information, handshaking etc.) of network protocols, which are more suitable for bulk data transfers. The call itself is considered to establish a connection and the result is treated as acknowledgement. For complicated calls, probes are sent by the caller periodically. If the arguments are too large to fit into a single packet, multiple packets with respective acknowledgements are sent. The authors chose to send single packets instead of doing bulk transfers.
4. Evaluation
For evaluation, 2 Dorados are connected by a 3Mbps Ethernet connection and latency is measured for RPC calls with different arguments and exceptions. The latency increases as the number of arguments increase because of the single packet protocol, but they got good throughput when they interleaved parallel remote calls from multiple processes. The evaluation seems limited in nature and does not perform more extensive latency measurements.
5. Confusion
It is mentioned that access controls are used to restrict users from exporting interfaces. It is not entirely clear how they do this. How can grapevine itself authorize the safety of an export interface?

Summary
The authors believed that procedure calls for transferring control and data within a program running on a single machine can be implemented across communication networks for the same purpose. They propose that this mechanism will be efficient and its generality will make it easier to use. They develop a system to implement remote procedure calls for use within the Cedar programming environment. Various components and the execution flow in the remote procedure call system are explained in this paper.

Problem
The existing communication mechanisms appeared to be a major constraint in the development of distributed computing. The semantics were not simple hence it was very hard to develop communicating programs. Other issues included integration of RPC into existing programming systems and determining the location and integrity of the callee.

Contribution
The components of the new RPC system include the user, user stub, server stub, server and RPCRuntime programs on the user and server. An RPC call is issued by the user program as a normal local call which invokes a procedure in the user stub program, which in turn identifies the specifications of the target procedure and requests the RPCRuntime to reliably transfer the packets to it. The server side RPCRuntime receives the packets and transfers them to the server stub, which unpacks the packets and calls the server procedure and which finally transmits the results back to the server. The stub codes are automatically generated by a separate program called “Lupine” hence it frees the programmer from coding communication related code.
To bind to a procedure call, a method of naming is provided which is maintained on a Grapevine distributed database. Any program wishing to export its procedures, makes a call to the RPCRuntime with the specifics of the procedure, which makes an update to the Grapevine DDB with its network address. The importer in turn makes a call to Grapevine to get the network address of the exporter, which is used in sending the RPC calls to the exporter directly.
They also maintain mechanisms to handle exceptions and isolation of effect of crashes in importer or exporter. Reliability is achieved using acknowledgement of data packets being sent. Use of unique identifiers in packets also help in detecting and eliminating duplicates.

Evaluation
They do not provide any performance comparisons with other inter process communication protocols. The authors made time elapsed measurements on 12000 remote calls between two Dorados systems connected by ethernet using varied number of arguments and sizes of arrays. They claim that non-RPC mechanism performed better during huge data transfers but by interleaving parallel remote calls, they achieved 2 megabits per second data rate on a 3 megabits Ethernet which is equivalent to a highly optimized byte-stream.

Confusions
I was not clear on the fact that upon dividing data into multiple packets, why are acknowledgements required from all packets but not the last one.

1. Summary
This paper discusses the implementation of a fast and simple Remote Procedure Call system. The semantics of the communication, binding mechanisms and packet-level protocol are explained in depth. Most design decisions are motivated by a desire to emulate local procedure calls. A few performance results are also shared.
2. Problem
A major hindrance to the development of distributed applications is the lack of an efficient and simple communication mechanism. Among various alternatives, the authors cite remote procedure call as a natural and intuitive extension for existing programming models. So the paper discusses the development of a simple, efficient but semantically rich RPC library

3. Contributions
The RPC consists of five key pieces - user code, user-stub, server-stub, server code and the RunTime on client/server. The application developer will define the interface between user (importer) and server (exporter) in the form of an interface module. This is used to automatically generate the code for the stubs. A user will invoke the RPC function similar to local function call, this will jump to the stub which will package the call into RPC packets and send it to the server stub. The server-stub will unpack the call and pass it to the appropriate procedure in the server. The communication between client and server is handled by an RPCRuntime. Binding requires the client to ‘name’ a server and identify its location. The name consists of a type, which specifies the server nature, and an instance, which specifies machine name. The server is located using a distributed database called Grapevine. When server exports its interface, it will create entries in this database with its location information. When the client wants to bind, it will query this database to know the machine location as well as unique ID for the interface. A dedicated transport protocol is designed for RPC to have minimum time between call and result as well as low setup/tear-down costs. For simple single-packet calls, this protocol does not require any ACK packets. For multi-packet calls, each packet (except the last) is ACKed explicitly. For long procedure calls, the client will periodically probe the server to check if computation is still running. To avoid process-creation and unnecessary context switch overheads, the server creates a pool of processes and each client is assigned to a particular server process. The server process ID information is cached by the client for future communication.

4. Evaluation
This paper has very little evaluation results. A few latency numbers are presented, but it is not clear how to interpret these numbers against alternative options such as message passing or any other transport protocol.


5. Confusions
What qualifies as state-information in an RPC connection?
How will a client know the list of procedures exported by a server?

Summary:
The paper provides a detailed implementation of an early RCP framework. RPC allows programmers to make function calls that are executed on remote machines which return the result locally. The authors discuss some design considerations they had and specific details of their implementation in addition to the hardware they ran it on.

Problem:
RPC solve the same problems as message passing, or just communication between two networked machines, but in a different and perhaps more appealing way. The idea of RPC has apparently been discussed before this paper was published, so the main problem being tackled by the paper seems to be that no one had implemented such a thing before.

Contribution:
The primary contribution of the paper is the detailed description of all the specifics going into an RPC framework implementation. The authors layout well made abstractions that could likely be used in other such RPC systems. Notably they do a good job of separating the work of networking and finding nodes to execute the procedure on from actually invoking or running the procedure, giving programmers a clean place to design their applications in. They also provide some specifics on how they allow named procedure lookup, and how their system finds remote nodes capable of running the procedure.

Evaluation:
The authors give some performance data on their system, but it lacks some context. It would have almost been nicer to actually see source code of a simple distributed application.

Confusion:
I don’t understand how specifying a network address as an instance when invoking a remote procedure binds to that machine at compile time. Why can a programmer not specify a variable address that is not known until runtime. They claim Grapevine can prevent MITM attacks, but I’m not sure how they can reliably verify the identity of a user exporting an interface, or how a caller would verify that the callee is the intended recipient of the RPC.

1. Summary
In the paper "Implementing Remote Procedure Calls", the authors design and build a RPC package system with the aim of making distributed programming easier. Their design choices were primarily centred around the need for providing communication with as much as ease as local procedure calls, so that programmers will be encouraged to build distributed applications. They also describe in detail about the binding mechanism((naming interface between the caller and the callee and locating callee) and light weight transport level communication protocol they implemented.

2. Problem
- choice of semantics of a call during machine and communication failures
- choice of semantics of dealing with address containing arguments (in the absence of shared address space)
- choice of protocol for data transfer between caller and callee
- providing data integrity and security in a network

3. Contributions
- completely adhere to the semantics of local procedure calls for remote procedure calls as well (for eg. no time-out mechanism limiting the duration of a remote call)
- use of RPC runtime for retransmission, acknowledgement, packet routing and encryption
- use of Grapevine distributed database as a authentication mechanism to restrict restrict the set of users exposing particular interfaces and providing client assurance of the server's authenticity
- provide various means for a caller to bind with the callee: specifying only interface type, specifying both interface type and instance or specifying the network address of the caller
- use of implicit unbinding through the unique identifier scheme so that clients are not notified of server crash
- introduces a new packet level transport protocol(unlike PUP or TCP) where explicit acks are not usually exchanged between caller and callee (acks are used only when the message size or result size is more than one packet or the results have not returned by the callee for long)
- use of a simple exception handler by sending an exception packet(exported by the interface) to the caller
- efficiently reduces the process creation overhead at the server by not killing a process when it completes; only for initial call the destination process needs to be identified by the caller

4. Evaluation
The authors have provided some empirical evidence of the performance of their RPC package implemented in Cedar environment. They have measured the elapsed time for remote procedure calls between 2 Dorados, varying the size of the arguments and the results. They have also shown the elapsed time when the caller makes a local procedure call to a callee (without involving their RPC package). Though they have discussed in fair detail about why they discarded some decision choices used by other RPC package developers, a benchmarking against other RPC packages for similar workload to substantiate their claims would have made it more effective.

5. Confusions
If the callee process is stuck in a deadlock, the caller will never come to know of this(to maintain consistency with local procedure call semantics). In such cases, what does the caller do?

Summary
The paper describes a package providing a remote procedure call facility (RPC) developed for Cedar programming environment to transfer and control data across a communication network, while keeping clean and simple semantics. The paper also discuss major decisions they made on RPC design, overall structure of their solution, binding mechanism, transport level communication protocol and the performance results.

Problem
The existing RPC facilities had many design issues and distribute computing was not easy. Few of the major design problems were: precise semantics of a call in the presence of m/c and communication failures; integration of remote calls into existing programming systems; binding; an efficient protocols to share/transfer data structures having pointers to dynamically allocated memory; data integrity and security in a communication n/w. The authors aim was to make distributed computation easy by implementing local procedure calls - RPC, make powerful semantics and provide secure end-to-end communication efficiently.

Contribution
Few of the major contributions in making easy to use RPC package were:
1. The use of RPC Runtime and Stubs to take care of communication, reliability and security making users free from design/implementation details.
2. Design of unique identifier based binding mechanism and using Grapevine database to keep track of exported procedure interfaces.
3. Enhanced security with the help of unique identifier scheme that allows calls to be made only on procedures that have been explicitly exported through RPC mechanisms.
4. Notification Mechanism: use of unique identifier in the transmitted packets which help notifying importers in case where exporter crashes/restarts.
5. Lightweight Connection Creation and Maintenance: No connection handshaking reduces cost. Idle server processes further reduce the cost of process creation and swap cost.

Evaluation
The paper doesn’t give a lot of evaluation details on RPC protocols and implementation as it’s covered in one of the author’s thesis. The paper presents measurement detail of their RPC package. These measurements were made for remote calls between two Dorado machines connected by an Ethernet. The authors compare latency of various remote calls running their package with a similar local call and report performance results. The authors also mention that by interleaving parallel remote calls from multiple processes, results are comparable to most highly optimized byte stream implementation.

Confusions
The authors suggest that server would queue & process all incoming RPCS on one thread – I am not sure why creating different thread was not thought.

Summary :
The paper describes how Xerox implemented RPC mechanisms for distributed communication in their mail server system, Grapevine. The authors introduce the semantics and design details of their protocol.

Problem :
When programmers want to build distributed applications, it is important that the distributed data computations are made easier so that focus can be laid on building the distributed system instead of worrying about the communication. This communication should be efficient, otherwise the distributed setting might not be used effectively. Along with this, the semantics of the protocol should be simple and not requiring much change to the existing programs. For this, the authors use the same idea as local procedure calls.

Contributions :
1. Designing RPC using local procedure calls semantics as a base paradigm. This makes the programmer’s job much easier by not having to change anything for communication; procedures are used widely in a local system anyway.
2. Making the user’s job easier by making him provide only the method calls. The stubs that are auto generated take care of packaging and sending it over the network. This make the system very simple.
3. Designing a relatively stateless, lightweight connection mechanism to reduce the elapsed time between initializing a call and getting results.
4. Implementing authentication protocols for the caller and the callee to authenticate themselves on Grapevine.
5. Failure handling is implemented implicitly because every RPC call executes only if the callee is alive.

Evaluation :
The authors present the times taken for the RPC calls to finish processing. But they do not really draw any conclusions from this. The paper does not compare multiple approaches with each other either.

What I found confusing :
I was wondering what other methods can be used in place of the protocols used here (like procedure calls) and how those might compare to this approach the authors have taken.

Summary:
The paper provides an overview of the Remote Procedure call mechanisms and policies that were developed for the Cedar project. The authors present the different possible design options available for some mechanisms and rationales behind their choices. The structure of the program is described and policies and mechanisms along with corner cases, like system crashes, are discussed. Finally, some possible optimizations are proposed and some performance figures are presented.

Problem:
The primary goal the authors were trying to achieve was to enable distributed computation through efficient, reliable and secure communication procedures with powerful semantics and control and data transfers compatible with existing mechanisms. The mechanism was also supposed to be robust in the sense that it had to accommodate system crashes.

Contributions:
The idea of splitting up the program into user, user-stubs and RPC Runtime on the user side with similar counterparts on the server side enabled the usability of same semantics as a local procedure call for RPCs. The RPC runtime defined a standard interface for systems which I think helped it to be portable, since a new system or programming language could use it with a customized user/server stub.
The idea of using a type and instance as a part of the name enabled multiple instances of an application to service different clients. I think the idea of using a distributed database for binding was a pretty straightforward choice but the organization of data, into individual and group entries, to locate a server was efficient. The constraint of average export rate being 1 per second seems to be good enough considering that expected amount of traffic at that point in time. The technique of using Unique ID provided security and also helped detect server crashes. The concept of call identifier provides a very elegant way of providing reliability and eliminating redundant call packets. The concept of probes, in a complicated call, which is similar to the heartbeat messages used today, enabled the server to inform the client of an ongoing requested computation, in absence of such a mechanism, the client might estimate a server crash. The use of processes and process IDs helped avoid the overhead of process creation, context switch etc.

Evaluation:
Data representing latencies for different message sizes and different number of RPC arguments is presented but this doesn't show the effectiveness of the approach, performance in the presence of traffic or the dependence of overheads of communication on message sizes or number of arguments.

Confusions:
How is a complicated RPC differentiated from a simple one? What does the state on each side, user and server,consist of?

Summary

Procedure calls are an ideal transport for remote communications in distributed systems. They provide an easy, lightweight, fast and secure mechanism for data and control messages on a local communication network. This paper describes an implementation of RPC calls in the Cedar environment on the Xerox network, introducing several novel approaches for interface binding, packet-level transport and guarantees, processes, exception handling and security.

Problem/p>

Distributed computer systems at the time lacked a simple and efficient mechanism for coordinating tasks and data across a communication network. While the idea of RPC had been floating around for a while, existing implementations faced many problems including failure handling, integration into programming systems, transport layer protocols that combined speed and reliability, data integrity and security.

Contributions

This paper provides several ideas which together form an efficient and useful RPC implementation. Some notable contributions include:

• The RPCRuntime package which handles all transport from the user-stub to server-stub and back, making it very easy for a programmer to send messages.
• Grapevine distributed database which tracks bindings between interface names and network instances.
• The use of receipt messages, instead of packet-level acks, for a reliable and fast transport protocol.
• Machines maintaing a stock of idle processes to handle incoming packets without incurring a process creation penalty.

Evaluation

The only evaluation was a short section at the end, which compares performance results for a variety of procedures, measured over 12,000 calls. The results demonstrate very good scalability (little difference between light and heavy tests) however there is no comparison against any other RPC attempts. It should be noted they claim that Bruce Nelson's thesis had a much more comprehensive analysis and they do not wish to repeat information.

Confusions

For the most part this paper was clear and straightforward. I was a bit confused about the Mesa language exceptions work; can we cover talk about this in class tomorrow?

Summary
This paper describes the implementation of a remote procedure call in a distributed system. They defined a RPC to have the same semantics as a normal procedure call, the caller would block execute and execution would resume on the callee. Despite the procedure call occurring over the network, the implementation of this RPC aimed to deliver the same semantics. Using a distributed database called Grapevine, they implemented a way for a client to simply specify the name of the remote procedure call and the server to properly handle the RPC and send results back. When sending packets over the network, their implementation made numerous optimizations, such as differentiating between simple and complicated procedure calls.
Problem
The problem this paper intended to solve was to allow a programmer to use a RPC by only specifying its name. This is difficult because using only the name, it is difficult to know which node or instance should handle the remote procedure call and it is also difficult to know how to transfer the data over the network. They also wanted to implement a remote procedure call that had similar semantics to a local procedure call.
Contributions
The implementation of the RPC was one of the biggest contribution of the paper. When a client specifies a RPC, it calls into the User-stub which packs the arguments and data into a packet. Then, the user-stub calls the RPCRuntime which transmits the packet over the network. The RPCRuntime is also responsible for submitting re-transmissions of packets if the client hasn’t heard a response in a while. Then, the RPCRuntime on the server side receives the packet and sends it to the server-stub, which unpacks the arguments. The server-stub then calls the appropriate server function. This entire process is reversed from the server back to the client to submit a response. Additionally, in order to support the client calling RPCs by name, the system uses a distributed database called Grapevine. Grapevine contains entries that hold types or instances. The data of types is simply a list of instances. The data of instances specifies the machine number for which the instance is running. Using Grapevine, the client can specify a type and an instance, or just and instance, and be able to transmit the data to the appropriate machine. The implementation of the RPC also specified their own network protocol and depending on the size of the data being transmitted, the protocol either used a simple or complicated approach. In the simple approach, the transmission of the data acts as the initiation of the connection and receiving the response acts as the acknowledgement. In the complicated approach, probe packets are sent out when the server is taking too long to process to test if the server has crashed or not.
Evaluations
The paper presents the evaluation of their implementation with respect to different amount of arguments being sent over the network. They also compare it to a local procedure call. This data would be more useful if it could be compared to a system that also implemented RPC, which might not have been possible when this paper was written. Nevertheless, they achieved their goal without incurring drastically unbearable overhead when compared to local procedure calls.
Confusions
The exact semantics of the complicated call were a bit confusing. When should the client set the packet as “don’t-ACK”, and when should it set it as “ACK”? How does retransmission work in the complicated call? Also, what sort of state information do the client and the server keep track of?

1. Summary
This paper describes the challenges faced and the decisions made to overcome them while implementing remote procedure calls. The authors also present some measurements to evaluate the performance of their implementation.

2. Problem
The problem addressed in this paper is the actual implementation of the RPC mechanism. The challenges that the designers faced included designing the communication protocol, implementing binding mechanism and handling machine failures and procedure exceptions.

3. Contributions
This paper discusses the implementation of a RPC mechanism in detail. The authors first state the goals that the implementation ought to meet and the challenges that they faced to meet the stated goals. Their design uses stubs on both the caller and the callee machines to pack and unpack the arguments and the returned results. The RPCRuntime also runs on both sides and is responsible for implementing the network protocol and security. In order for a caller to execute a remote call it has to bind to the callee. Identifying the host machine exporting the procedure is a major challenge for binding. The authors propose a naming scheme consisting of a type and an instance to solve this problem. The Grapevine distributed database is used in locating the appropriate host by storing the host's network address in the database fields. The authors implement a new transport level protocol to transfer RPC messages. The protocol is designed to be fast and reliable and is tailored for small packet bursts rather than streams. It supports duplicate removal, acknowledgements and retransmissions. It can also handle large sized arguments and return values by using multiple packets. Callee machine failure is detected by sending periodic probe messages and demanding for acknowledgment. Procedure exception is handled by sending the exception catch phrase to the caller.

4. Evaluation
The paper presents a limited set of RPC latency measurements. The authors compare their data against calling the procedure on the same machine. They do not give any detailed breakdown of where the time is spent.

5. Confusion
The transport protocol for larger arguments and return values seems confusing. In particular, I did not understand on what the decision of whether to ask for acknowledgement or not is based.

1. Summary
This paper details the design and implementation of a remote procedure call protocol implemented in the Cedar environment. The mechanics of the RPCs and a novel communication protocol are detailed.

2. Problem
At the time of the paper, designing distributed programs was difficult. The authors had access to a powerful communication network between computers that were easy to program. However, they realized that the development process was constrained by a the lack of simple, efficient communication offerings. As a result, the authors wanted to develop a remote procedure call package. This was not a new idea, but previous attempts had many issues which the authors attempted to resolve. The authors attempted to create a RPC mechanism which functioned closely to local procedure calls.

3. Contributions

A major contribution of the paper was the generated stubs and RPCRuntime packages that worked together to provide simple interfaces for remote procedure calls. To create these stubs, a user simply creates a list of interface modules. The user can then specify both server-side and client-side code (with no network knowledge) in terms of these interfaces, and the necessary details will be handled at compile-time. When making a RPC, a caller will make a local call into the user-stub, which will pack up the necessary arguments and ask RPCRuntime to transfer data. The server-side RPCRuntime will receive the data, pass it on to the server-stub, and then on to the server.

Naming and binding were also significant contributions. Interfaces are separated into types and instances. This means a server who wishes to export some interface simply calls into some central Grapevine database (via RPCRuntime). This database then stores the network address and type/instance of the interface specified by the server. Notably, this means that a client doesn’t need to specify a specific address to bind to at compile-time. A client wishing to import an interface will make a local call into the client-stub/RPCRuntime, which will then query the Grapevine database and perform a check with the machine at the specified network address. Because this Grapevine database essentially acts as a DNS server, sophisticated techniques like load balancing could be implemented.

Finally, the third major contribution from the paper is the designed communication protocol. The authors noted that most procedure calls could fit in one packet, and that the request-response nature of RPCs meant that byte stream protocols added unnecessary overhead. As a result, they implemented a protocol which tries to maintain as little state as possible. For simple calls, this simply means that the sender is responsible for sending the packet until it receives a response. This response serves as an acknowledgement that the data was received. Complicated calls are slightly different, and require acks on a second retransmission if no response was received on the first. This still means only one packet buffer is needed for each call, and allows for a very simple implementation.

4. Evaluation
The authors provide little in terms of evaluation. They present a table of results for different argument sizes, yet surprisingly provide no analysis. They do show that by interleaving parallel remote calls, they can achieve data rates equivalent to optimized byte streams. Several clients are currently using the RPC package, but not yet full-scale so the authors have few other results.

5. Confusion
At the top of page 51, the authors mention that when the connection is active, both sides retain significant information for simple calls. What is this?

Summary - The authors discuss the nuances of their Remote Procedure Call (RPC) implementation for the Cedar project. Design decisions related to binding a remote procedure to a prospective caller, the packet-level communication protocol, and exception handling are elaborated upon, and several unused alternatives are also presented to the readers.

Problem - The authors wished to reduce the complexity of programming using distributed computation, and believed in RPC as a good idea to facilitate distributed applications due to its simplicity and generality. Thus, the authors attempted to construct an RPC implementation to understand issues such as failure handling, addressing of arguments, control and data transfer and provide robust solutions. Also, they hoped to make their RPC mechanism efficient and secure.

Contributions - The main contribution of this paper was that it provided a walkthrough of the process of designing an RPC implementation, and thus, hoped to stimulate greater activity in this area. The decision to maintain semantics similar to local procedure calls will greatly aid the adoption of RPC, in my opinion. The creation of RPC runtime and stub generators is very important, particularly to expose a simple RPC interface to the programmer. The authors elegantly handle the problem of reliable binding by using the Grapevine database to track exported procedure interfaces. Finally, the use of light-weight connection management for the RPC communication is important, given the need to optimize the elapsed time between the procedure call and the return.

Evaluation - The authors do not present the results of explorations in the relevant design space to prove that their design choices are suitable for efficient RPC, as this data is present in the PhD thesis of one of the authors. The authors present performance results for their RPC implementation using two Dorado machines connected via ethernet. They report the latency for several types of remote calls, and compare it to the latency of a similar local call. The observed latency for RPC falls in the range of 1059-3374 microseconds, compared to 9-196 microseconds for local procedures. They also show the time consumed for remote communication needed for RPC.

Confusions - Where exactly is RPC used in modern applications?