CS 736 Reviews - Spring 2017

Summary
The paper described how to implement remote procedure calls, aiming to make communication between servers and clients as easy as local procedure calls. The paper also discussed exception handling and security mechanism for RPC design.

Problem
The authors' designed RPC in order to make distributed computation easy, specifically, by making RPC communication highly efficient and trying to provide secure communications with RPC. The authors also addressed the usability of RPC by following the principle of making sure the semantics of remote procedure calls should be as close as possible to those of local procedure calls.

Contribution
1.Raised the idea of RPC implementation. Explained and discussed design decisions in detail.

2. Structured RPC mechanism as the user, user-stub, the RPC communications package, the server-stub and the server.

3. Apart from the effects of multimachine binding and of machine or communication failures, the call happens just as if the user had invoked the procedure in the server directly for the ease of use.

4. Described binding mechanism in detail and implemented various binding mechanisms in scenarios like when the importer specifies only the interface type but no instance.

5. Designed the complicated call mechanism to handle longer message communications.

Evaluation
The authors evaluated the performance of RPC by measuring individually the elapsed times for different procedures like 1 word array, 4 word array and many more. The time is also compared to local-only calls. The transmission time for each all is also listed. However, as the author mentioned, the transmission time was calculated from the known packet size but not measurement. If unexpected behavior happened, then the transmission time might not be accurate. Moreover, it would be nice if the paper can comment on the result, like whether those values are expected or are the values good.

Confusion
1. How specifically does Lupine generate the code for packing and unpacking arguments and results?
2. How exactly does the exception handling solves the problems raised by communication?

1. Summary
This paper introduces a mechanism to implement remote procedure calls (RPC) on a local network. By design, a programmer can perform RPC in exactly the same way as a local procedure call.

2. Problem
Programmers often used an ad-hoc approach to perform distributed programming. Issues in distributed systems included machine discovery, machine failures, network delays, and packet reordering. As a result, users avoided writing distributed programs wherever possible. However, programmers were comfortable with the abstractions and tools provided by local programming environments. Other issues in distributed environments included efficiency and security.

3. Contributions
The authors implement RPC on the Dorado machines at the Xerox Palo Alto Research Center. The user process communicates with a user stub, and the server process communicates with a server stub. Both stubs are generated automatically from an interface module written by the user. The two stubs communicate through RPCRuntime, which performs packet-level communication between the two machines. The Grapevine distributed database stores information about which servers can run each procedure. Servers export these procedures to make them known to Grapevine. When a user wants to import a procedure, it communicates with Grapevine, and also performs a lookup on the remote machine to make sure the server can still perform the procedure. Then, the user can perform RPC as many times as necessary.

RPC can handle exceptions in the same way a local program would. After an exception in a local procedure on the Dorado machines, the program can resume either at the point where the exception occurred, or the point where it is caught. Correspondingly, if the server raises an exception during an RPC call, the program can continue either on the server or the client. Another minor contribution of RPC is security; the user and server perform encrypted communication, and they are guaranteed of each other's identities.

4. Evaluation
During a single RPC call, the user sends one packet, and the server sends one packet. The protocol is optimized for the simple case; if more packets are required, then all of them require an acknowledgement except the last one. Furthermore, if the computation on the server takes a long time, then the user requests acknowledgements. Hence, RPC is not designed to handle bulk data transfers. The simple case has also been designed to have only 2 context switches at the server and 2 context switches at the client on each RPC.

The authors provide some numbers in Table I to show the time required to perform RPC. These numbers seem to show that their optimizations to limit the number of packets and context switches are unnecessary; the median elapsed time is much larger than the transmission time. The elapsed time is higher outside the simple case, such as if the size of the data is large, or if an exception occurs.

5. Confusion
In Table I, why does transmission take such a small percentage of the entire elapsed time? Why is the median elapsed time for RPC not roughly the same as the sum of the transmission time and the local-only execution time?

Summary

The paper describes the architecture, design and implementation of a then new distribution communication protocol called Remote Procedure Calls which claims to improve the efficiency by more than a factor of 5 when compared to the existing network communication protocols.

Problem

The paper made its goal clear from the very beginning. It set out to make IPC more efficient even when the processes are on different physical hosts and retaining the semantics of an intra process procedural call at the same time. The following are the major design challenges which the paper had to handle:

1. Semantics of address containing arguments because there is no guarantee that two process have a shared address space.

2. Binding the caller with the callee .i.e the exact network address and port address(or equivalent) of the server process.

3. Providing data integrity and security in an open communication network.

4. Integrating of remote calls into the existing or future programming systems.

Contributions

Firstly the paper proposes a client-server architecture to carry out RPC calls. Client being the caller and server being the callee. Then it describes how the client and server are divided into components for clear separation of concerns. The client is made up of user code, user stub and RPC communication package RPCRuntime and equivalently the server is made up of server code, server stub and RPC communication package. User code and server code contain procedures which make and execute calls respectively. The client stub and server stub both pack the content suitable for communication and the RPCRuntime’s responsibility is to reliable deliver the packets.

For binding the RPCRuntime interacts with a distributed highly reliable graph database called Grapevine which stores the network addresses of the (interface + implementation) pairs which uniquely identify a server process.

Packet level transport protocol differs quite a bit from other popular protocols in the following ways: 1. In RPCs there is practically there is no concept of connection establishment or handshaking. Connection is established as soon as the call is made. 2. There are no explicit acknowledgements when the duration of a call and the interval between calls are less than the transmission intervals. Reponses and subsequent calls are used as acknowledgements. 3. There is no concept of cumulative acks in RPCs. Each call and response have to receive acknowledgements to proceed further.

Evaluation

While the paper made a good job evaluating the latency costs of RPCs for various message sizes and a few exceptions, it would have been better if it listed the times for existing popular network communication protocols to compare against.

Confusion

These are the questions I have:

1. It is not clear from the paper how does the system differentiate a function call in the same file/process with the same name as an RPC call. Can’t we have same names? I’m assuming it is not as restrictive as that.

2. Suppose a programmer wants multiple server processes doing the exact same thing for load balancing. It is not clear to me how load balancing would be achieved with the proposed architecture because such a decision cannot be made based on the “groups” entry in Grapevine DB.

3. RPCRuntime seemingly performs the functions of TCP and IP layers in many scenarios. Is it run in a priviliged mode? If not with my understanding it seems to be security concern.

Summary
This paper provides a comprehensive implementation details of RPC which authors implemented at Xerox. Authors provides insight into their design decisions and choices that led to the semantics of RPC similar to local procedure calls. And finally, to achieve higher throughput, parallel processes were used (with process IDs).

Problem
Though ideas of RPC existed around for years, there was no concrete implementation. Authors focused on implementing an RPC which was clean, simple, efficient, general and secure. As some of the areas weren't clearly understood in earlier works, the authors made several design decision based on specific goals and environments like, Semantics of call during failure; Semantics of arguments containing addresses, Integration of RPC into programming languages; Binding; Protocol for transfer of data and control between caller and callee; Providing data integrity and security.

Contribution
There are three main contributions of the paper:
1) To Provide Transparent communication framework that makes distributed computing easy.
2) Provide powerful semantics that are closer to local procedure call along with as high efficiency as possible.
3) Security and Integrity: Provide safe communication with RPC.

The distinguishing factor of choosing RPC, from other alternatives like message passing, was because of the control and data transfer mechanisms embedded into programming languages. This helped in achieving semantics closer to procedure calls which were quite familiar to programmers. Authors decided not to include shared address spaces due to complexities in representing remote addresses and inefficiencies attached with it.
Binding: There are two aspects of binding: What exporter service the client wants and where to get the service from. i.e. Naming and locating. Name is pair of type (What type of service) and instance (which implementation to invoke). A distributed data base is used for resolving names to machine addresses called Grapevine. The database contains key, value(s) pairs, in which key is string named RName and value is either machine address of the device exporting the service or in case of group, RNames of exporters of that type. Exporter uses ExportInterface method to register the services with the database and similarly the importer uses ImportInterface to contact database to get the exporter's unique ID and index. Every communication between client and the exporter will include these two attributes.
Due to overheads involved in transport layer protocols, to maintain large transfers and connection setup and tear down, it cannot be used for RPC. Thus, a simpler communication layer is used for higher Response time than throughput.
RPCs with arguments fitting inside a single packet and handled using Simple calls in which no explicit acks are used (subsequent call packet and result packets are used for implicit acking). For packets that do not fit in a single packet, more complicated calls are done; Each packet includes an explicit request for ack. To check for network connectivity issues, periodic 'Probes' are also sent. Expecting acks for every packet is simple and thus it obviates buffer and flow control mechanisms (only one packet to buffer).

Evaluation
The authors provide a decent evaluation of RPC with various argument sizes for the procedures. RPC number are one to three orders of magnitude slower than regular local procedure call and this was expected. It would've been good to include numbers with encryption facilities. Though authors say that detailed analysis is provided in Nelson's (one of the author) thesis, numbers related to binding and communication with Grapevine server would've been better. This would give us insight on the percentage of time spent on initial importing.

Confusion
Can you please elaborate on PUP byte stream transport protocol ?

Could not understand how a random user, impersonating as an exporter of service, is detected or is prevented from accepting call packets from clients?

1. Summary
Birrell and Nelson explore RPC as a way to simplify communication in a distributed environment and implement a communication primitive allowing programmers to design applications without an avoid communication mentality. They discuss their experience with building such a system as well as the design decisions behind it.

2. Problem
Distributed computing is challenging and at the time was left only to a select few of whom required very specialized knowledge. They wanted to expand the use of distributed computing at Xerox PARC and understand the challenges of a product implementation.

3. Contribution
The main contributions are the implementation experience for RPCRuntime, the stub generator, and the pursuit of local procedure call semantics. Additionally, the use of Grapevine solves several challenges regarding a real implementation of binding. They define exactly once semantics which is a fundamental key to assuming local procedure call semantics. Finally, they define how to handle exceptions across Mesa.

It’s interesting seeing the optimizations they chose to use and those they chose to forego in the name of local procedure call semantics. One of the main optimizations is to minimize network communication using multi-purpose packets (ie result and ack). Another is to avoid context switching by directly forwarding packets to the waiting process. Unfortunately they did not write microcode to do it in hardware.

4. Evaluation
Seems to perform relatively well being able to get to 2 Mbps out of line. It is apparent in the results that the transmission time required multiple round trips with the 40 and 100 word arrays scaling linearly. A breakdown of where time is lost throughout the RPC timeline would be nice as that would direct attention towards areas with the highest ceiling for improvement.

While they try and spin the single-packet buffer off as an optimization, it sounds like they were just lazy towards a multi-packet protocol. They mention multi-process communication as a work around… This seems like it would be a burden on the application programmer. They do ultimately say that protocols other than RPC are more advantageous here.

5. Confusion
I do not fully understand the need to limit the calls to ExportInterface. Is this a limitation due to the 1-second counter or a desire to moderate load for Grapevine?

1. Summary
The paper addresses the problem of designing clean, simple abstraction to facilitate running procedures on remote servers (RPC). The abstraction framework must offer interface similar to running procedure locally and hide the complexity of network communication with remote server from users.
2. Problem
RPC involves client process waiting for result from procedure invocation on server. This network communication exposes lot of issues like security, failure handling, knowledge of precise semantics of procedure at both ends, integration of remote calls into existing programming languages, protection from data corruption, etc.
3. Contributions
The paper proposes a design to tackle these issues with simple interface to users. The design involves running ‘RPCRuntime’ on both the ends (client and server). The authors have implemented RPC framework in Mesa language. The caller program imports the Interface exported by Server and exports the procedure implementation to the remote server. This registers the procedure in the server database. Caller program needs to bind this procedure to its interface before issuing its invocation command. The design in the paper uses Grapevine distributed database for storing RPC binding metadata. The two types interfaces exported (type and Instance) are registered in this database. Caller needs to lookup in this database to bind its interface to already exported procedure. Binding a procedure makes client aware of server network address and other required information. Callers then invoke remote procedures synchronously. The RPCRuntime doesn’t allow multiple active invocations. The RPC framework has to provide failure detection and handling. To achieve failure resilience, the authors have optimized Transport layer protocol for RPC. As per this protocol, the caller waits for almost round-trip time before retransmitting the same RPC invocation request. The callee maintains a state of active RPC requests. The state is useful to discard late retransmission requests from callers. The state is identified by monotonic sequence of numbers. Authors have also tweaked the network stack to directly pass RPC packets to respective processes by extracting PID from the packet. As a result of bypassing the network stack, the authors managed to skip 2 process interactions. In case of failures in the procedure execution, the exceptions are propagated to caller via network. Authors have also tackled security issues by providing end to end encryption and authentication provided via Grapevine database.
4. Evaluation
The evaluation involves running different types of workloads. The authors have compared the performance of RPC against local execution. Authors have also provided the network transmission overhead. The overhead of RPC seems to be at least 10x excluding the transmission delay. The RPC performance on traditional network stack should be analyzed.
5. Confusion
How relevant are RPC frameworks with the onset of AWS lambda/Open Lambda Serverless computing?
The paper has not discussed the Security Isolation provided to each procedure.

1. Summary
This paper introduces how to implement remote procedure call (RPC), which is a widely-used method for communicating across network between different programs. This paper shows the details and underlying protocols of how to implement a RPC library.

2. Problems
In distributed systems or network systems, it is very difficult to construct communication programs for different machines, because a program like this need to consider network protocol, network and server problems, and etc. Only some communication experts can do this, and it is a difficult task even for these experts. This paper want to make this easier by providing a level of abstraction for common users, making remote procedure call almost as easy as local ones. This will make it easier for people to build distributed applications, and also guarantees procedure call semantics and efficiency.

3. Contributions
The architecture of RPC system consists of an interface shared by caller and callee, and a RPCRuntime that manages all the lower level details like transmission, acknowledgements, and routing. Caller and callee need to bind with each other before procedure call. Here, the naming and locating of remote machines are supported by a distributed database system called Grapevine. After binding, caller can make function calls on a remote machine just like local function calls, and the underlying RPCRuntime will transfer function identifier and parameters to remote machine, execute in remote machine and transfer back the result. This design focuses on the semantics aspect, most network related operations are transparent to user, and it supports exception handlings just like normal function. This design also focuses on efficiency. There are special packet transmissions for short, frequent, and simple calls to reduce the overhead to acknowledgement, and there is a design of process pool to handle multiple callers efficiently.

4. Evaluation
The experiment section of this paper is not well written. I think maybe it is because this paper mainly focuses on implementation details of RPC system, performance will be thoroughly evaluated in some related papers. This paper varies the size of arguments and includes some cases with exception, and compares the execution time with local procedure call. I think it makes no sense to compare to local calls because the remote call must be slower. I think the writer should compare this system with some existing RPC system, and make a comparison to show this one is more efficient. Also, this paper lists the transmission time of RPC, I think a better way is to do a breakdown of RPC time, and see what is the bottleneck of this RPC system apart from the transmission.

5. Confusion
I don’t understand why there is a ‘constrains for the rate of calls on ExportInterface’ in section 2.2, there is also something in section 2.3 about access control, I think they are related but I am not sure. My understanding is that there will be only one ExportInterface call, then there will be many import operations, so why is this constrains necessary?

Summary

The goal of the paper is layout the stucture of a system that
supports Remote procedural calls while abstracting away as much of
the details from the programmer as possible. The authors come up
with system based on stubs that describe a simple and easy
implementation of RPC's

Problem

Unlike the other papers we've read so far there isn't really a
problem. The authors want to build something new. They have a few
set goals:

* Their primary goal was to make it easy to use for programmers.
They wanted writing a RPC to be not a whole lot different from
writing a local procedure call. This meant the systems people
had to do all the heavy lifting in the background to get this to
work.

* Secondary goal I: Highly efficient (This one I take with a grain
of salt. Given the time this paper was written this goal
might've been well accomplished. I don't know!)

* Security: Make transmission secure( which they don't specfify
exacltly but some form of encryption was used)

Contribution (Confusions put in between [] )

General Structure:

They introduce the concept of stubs, Client has client
stub. Server has server stub. Both stubs talk to a RPC runtime
which talks to a grapevine distributed database The stub code and
the runtime code is generated by lupine].

[What is Lupine? Are things like Lupine common?]

[I get how this works at a very very high level. I'm pretty
clueless about how one would implement this in practice. This
might be due to a complete unfamiliarity with databases which I
still view as a giant hashtable]

PACKET LEVEL: They felt the need to come up with their own packet
level transmission protocol.

* Caller sends call packet which consists of call identifier, data
and arguments

* Keep sending call packets till ack recd (the result of a call
counts as ack also) [Waiting for an ack for every packet in RPC
call seems a bit much to me, will slow stuff down for large
transfers]]

* Caller receives result packet with the same identifier as call
indentifier.

The caller identifier is a tuple (machine identifier, process,
sequence number): Helps match calls with results in conjunction
with the RPC runtime

[They claim that they don't transmit based on any two-way
handshake connection (say like TCP which is 3-way) but the
workings of their transmission to be worse off than something like
TCP which I believe does allow out of order transmission, and the
receiver can look at the sequence numbers and rebuild packet. This
also could be because the paper was written when the dinosaurs
lived so this was the best known mechanism. I don't know!]

[They assume ethernet, what if this was used the big internet like
we know today? The transport protocol doesn't seem like it'll be
able to keep up]]

1. Summary
The authors make the case for a remote procedure call (RPC) as a clean and simple model for distributed computations, and describe their design of such an RPC system. It includes mechanism for efficient and transparent communication through stubs and a specialized transport protocol, and mechanisms for handling machine failures.

2. Problem
RPC had been around in literature for about 8 years before this paper was published. The authors argue that existing RPC implementations were few, and several areas were poorly understood which could lead to poor performance. Their intention is to shed light on the design choices that can help build more efficient RPC systems. They also highlight the security problems associated with previous systems — machines could pretend to be clients or servers, and messages containing passwords were sent in clear text format. Building a more secure RPC system is listed as a secondary goal

3. Contributions
Several contributions are made which show how an RPC system ought to be designed:
1. The idea of stubs with a lot of boilerplate code to provide an easy way to invoke remote procedures while needing minimal code changes for client and server programs. The stubs are also generated automatically and perform argument type checking and packing / unpacking.
2. The idea of using the Grapevine database during bind time to eliminate the need to statically couple client-server pairs. It also allows policies to return the closest servers to a client during bind time. Its use also provides an easy way to impose access controls and avoid security problems associated with earlier systems.
3. A new transport protocol for RPC which optimizes for the common case where the arguments and results can be fit in one packet, and avoid the overheads of handshakes and ACKs.
4. The idea of keeping a stock of server processes running to reduce the process creation costs.
5. Exception handling mechanisms and mechanisms for handling machine failures.

4. Evaluation
Evaluation is done for multiple RPC argument formats and for exception handling, along with network transmission time and local-only (ie. no RPC) numbers to get a sense of the RPC overhead. The evaluation section is the weakest link of the paper. No comparison with other RPC systems are provided. No separate evaluations for different design choices are done to prove the impact of the design choices.

They assert that RPC arguments fitting into one packet is a common case, without actually instrumenting and proving that it is indeed common. This “intuition” is used to justify implementing a new transport protocol. I am not convinced by some of their over optimizations such as removing ACKs, which resulted in only a 10% improvement. On the contrary, their new protocol seems unsuitable for large transfers, and we see network transmission accounting for 30-40% of the time for the RPC with large arguments case. Could we have had better performance with existing protocols such as TCP which are suitable for large data transfers? They also avoid mechanisms for congestion control in their protocol and conveniently test their RPC system for a lightly loaded network. Can their protocol handle congestion? These questions remain unanswered.

5. Confusion
1. The authors argue that existing transport protocols were not suitable enough. Can you provide more context on the state of networking protocols during this time and whether the authors really had no alternatives? I know that TCP/IP was proposed in 1974, and UDP was invented in 1980

1. summary
This paper presents an implementation of Remote Procedure Calls, including the principles it follows and the choices it makes.

2. Problem
There are many designs regarding Remote Procedure Calls (RPCs), but fewer full-scale implementations of RPC is avaiable. Another problem is the construction of communication programs is difficult. Besides, there are many issues facing the PRC design such as, 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 existing programming systems, binding, suitable protocols for transfer of data and control between caller and callee, data integrity and security in an open communication network.

3. Contributions
This paper aims at providing easy distributed computation (the primary goal), highly efficient and secure communication, and powerful semantics. The authors make the choices based on their aims and their programming environment. One important contributions is that they do not follow conventional choices like emulating some form of shared address space among computers and PUP byte streams. Instead they design the message passing and transport protocol specialized for their goals, thus improving the efficiency much. They also optimize the implement. For example they maintain in each machine a stock of idle server processes willing to handle incoming packets

4. Evaluation
The authors only did a simple measurement on the elapsed time, because they thought Nelson's thesis had done enough analysis and examniations. The authors measured the time elapsed on remote calls between two Dorados connected by an Ethernet (2.94Mb/s). Many cases with varying argument sizes were tested repeatitively. Nevertheless, it lacks comparation to other designs and implementations. The results does not support their claim strongly.
5. Confusion
The exporter information on the Grapevine database is stored as key-value pair in a map. If two servers exports the same instance, will that cause a conflict?
There are two different protocols, one for simple calls and another for complicated calls. How do we determine whether a call is simple or complicated?

1. Summary

This paper describes an implementation of Remote Procedure Calls (RPC) which provide a way for processes on different machines to transparently communicate with each other. The calling process invokes the function on the remote machine through a stub as if it is invoking a on the same machine. The RPC runtime which executes on both the client and the server machines takes care of the discovery and communication aspects of Remote Procedure Calls. An important component of this implementation is the grapevine database which provides binding and name service to the applications.

2. Problem

No adequate implementation of RPCs existed at the time. The designers of RPCs did not know the precise semantics of the call in the presence of machine and communication failures. The RPCs needed an efficient implementation. Moreover, the integration of RPCs to the existing systems was also challenging. Ideally to achieve most of these qualities, the RPC should appear to the user as if it was a normal local function call. However, no efficient implementation that provided these qualities existed at the time.

3. Contributions

This basic components of this RPC implementation include, a user process, a user side stub, a server process, a server side stub and an RPC runtime. The call to a remote procedure is just an extension of a local procedure call. When a caller calls a remote procedure, the execution of the caller is suspended and the corresponding function in the user stub is invoked. The user stub packs the arguments of the call to one or more network packets and asks the RPC runtime at the user side to send that packet to the server. On the server side the RPC runtime receives the packet and passes the arguments to the server stub. The server stub in turn makes the local procedure call at the server, receives the resulting data from it and sends it back to the user through the RPC runtime. On receipt of the result, the user process resumes its invocation. To make RPC more efficient, the result of the function call is used as an implicit ack for reliability. This helps avoids transport layer connection setup overheads and makes the execution faster. If the result is not received within a timeout window, a failure is assumed and the function call is made again by the user side stub. Monotonic sequence numbers are used to detect and discard duplicates.

Central to this RPC implementation is the grapevine database. This database stores the network address of the servers providing an instance of a particular service. The user contacts this database first to find the network address of the server.

4. Evaluation

The evaluation of this paper is surprisingly small. The authors measure the completion time of various RPC calls with different number of arguments and data size and compare it with purely local calls. I am not quite sure what to make of these results. The increased execution time compared to local implementation is obvious but perhaps they could have compared it with some existing alternative implementation to quantify the actual performance gains. They could also have run it with a transport protocol such as TCP to justify the usage of function call returns as implicit acks which is so emphatically touted .

5. Confusion
What happens with the void functions which don't return anything. How does the client know the function has been successfully executed?

Why haven't they tested it on TCP or even mentioned TCP in the paper? TCP was around at that time.

What happens if the grapevine database crashes?

1. Summary

This paper describes an implementation of Remote Procedure Calls (RPC) which provide a way for processes on different machines to transparently communicate with each other. The calling process invokes the function on the remote machine through a stub as if it is invoking a on the same machine. The RPC runtime which executes on both the client and the server machines takes care of the discovery and communication aspects of Remote Procedure Calls. An important component of this implementation is the grapevine database which provides binding and name service to the applications.

2. Problem

No adequate implementation of RPCs existed at the time. The designers of RPCs did not know the precise semantics of the call in the presence of machine and communication failures. The RPCs needed an efficient implementation. Moreover, the integration of RPCs to the existing systems was also challenging. Ideally to achieve most of these qualities, the RPC should appear to the user as if it was a normal local function call. However, no efficient implementation that provided these qualities existed at the time.

3. Contributions

This basic components of this RPC implementation include, a user process, a user side stub, a server process, a server side stub and an RPC runtime. The call to a remote procedure is just an extension of a local procedure call. When a caller calls a remote procedure, the execution of the caller is suspended and the corresponding function in the user stub is invoked. The user stub packs the arguments of the call to one or more network packets and asks the RPC runtime at the user side to send that packet to the server. On the server side the RPC runtime receives the packet and passes the arguments to the server stub. The server stub in turn makes the local procedure call at the server, receives the resulting data from it and sends it back to the user through the RPC runtime. On receipt of the result, the user process resumes its invocation. To make RPC more efficient, the result of the function call is used as an implicit ack for reliability. This helps avoids transport layer connection setup overheads and makes the execution faster. If the result is not received within a timeout window, a failure is assumed and the function call is made again by the user side stub. Monotonic sequence numbers are used to detect and discard duplicates.

Central to this RPC implementation is the grapevine database. This database stores the network address of the servers providing an instance of a particular service. The user contacts this database first to find the network address of the server.

4. Evaluation

The evaluation of this paper is surprisingly small. The authors measure the completion time of various RPC calls with different number of arguments and data size and compare it with purely local calls. I am not quite sure what to make of these results. The increased execution time compared to local implementation is obvious but perhaps they could have compared it with some existing alternative implementation to quantify the actual performance gains. They could also have run it with a transport protocol such as TCP to justify the usage of function call returns as implicit acks which is so emphatically touted .

5. Confusion
What happens with the void functions which don't return anything. How does the client know the function has been successfully executed?

Why haven't they tested it on TCP or even mentioned TCP in the paper? TCP was around at that time.

What happens if the grapevine database crashes?

1. Summary

This paper describes an implementation of Remote Procedure Calls (RPC) which provide a way for processes on different machines to transparently communicate with each other. The calling process invokes the function on the remote machine through a stub as if it is invoking a on the same machine. The RPC runtime which executes on both the client and the server machines takes care of the discovery and communication aspects of Remote Procedure Calls. An important component of this implementation is the grapevine database which provides binding and name service to the applications.

2. Problem

No adequate implementation of RPCs existed at the time. The designers of RPCs did not know the precise semantics of the call in the presence of machine and communication failures. The RPCs needed an efficient implementation. Moreover, the integration of RPCs to the existing systems was also challenging. Ideally to achieve most of these qualities, the RPC should appear to the user as if it was a normal local function call. However, no efficient implementation that provided these qualities existed at the time.

3. Contributions

This basic components of this RPC implementation include, a user process, a user side stub, a server process, a server side stub and an RPC runtime. The call to a remote procedure is just an extension of a local procedure call. When a caller calls a remote procedure, the execution of the caller is suspended and the corresponding function in the user stub is invoked. The user stub packs the arguments of the call to one or more network packets and asks the RPC runtime at the user side to send that packet to the server. On the server side the RPC runtime receives the packet and passes the arguments to the server stub. The server stub in turn makes the local procedure call at the server, receives the resulting data from it and sends it back to the user through the RPC runtime. On receipt of the result, the user process resumes its invocation. To make RPC more efficient, the result of the function call is used as an implicit ack for reliability. This helps avoids transport layer connection setup overheads and makes the execution faster. If the result is not received within a timeout window, a failure is assumed and the function call is made again by the user side stub. Monotonic sequence numbers are used to detect and discard duplicates.

Central to this RPC implementation is the grapevine database. This database stores the network address of the servers providing an instance of a particular service. The user contacts this database first to find the network address of the server.

4. Evaluation

The evaluation of this paper is surprisingly small. The authors measure the completion time of various RPC calls with different number of arguments and data size and compare it with purely local calls. I am not quite sure what to make of these results. The increased execution time compared to local implementation is obvious but perhaps they could have compared it with some existing alternative implementation to quantify the actual performance gains. They could also have run it with a transport protocol such as TCP to justify the usage of function call returns as implicit acks which is so emphatically touted .

5. Confusion
What happens with the void functions which don't return anything. How does the client know the function has been successfully executed?

Why haven't they tested it on TCP or even mentioned TCP in the paper? TCP was around at that time.

What happens if the grapevine database crashes?

1. Summary

This paper describes an implementation of Remote Procedure Calls (RPC) which provide a way for processes on different machines to transparently communicate with each other. The calling process invokes the function on the remote machine through a stub as if it is invoking a on the same machine. The RPC runtime which executes on both the client and the server machines takes care of the discovery and communication aspects of Remote Procedure Calls. An important component of this implementation is the grapevine database which provides binding and name service to the applications.

2. Problem

No adequate implementation of RPCs existed at the time. The designers of RPCs did not know the precise semantics of the call in the presence of machine and communication failures. The RPCs needed an efficient implementation. Moreover, the integration of RPCs to the existing systems was also challenging. Ideally to achieve most of these qualities, the RPC should appear to the user as if it was a normal local function call. However, no efficient implementation that provided these qualities existed at the time.

3. Contributions

This basic components of this RPC implementation include, a user process, a user side stub, a server process, a server side stub and an RPC runtime. The call to a remote procedure is just an extension of a local procedure call. When a caller calls a remote procedure, the execution of the caller is suspended and the corresponding function in the user stub is invoked. The user stub packs the arguments of the call to one or more network packets and asks the RPC runtime at the user side to send that packet to the server. On the server side the RPC runtime receives the packet and passes the arguments to the server stub. The server stub in turn makes the local procedure call at the server, receives the resulting data from it and sends it back to the user through the RPC runtime. On receipt of the result, the user process resumes its invocation. To make RPC more efficient, the result of the function call is used as an implicit ack for reliability. This helps avoids transport layer connection setup overheads and makes the execution faster. If the result is not received within a timeout window, a failure is assumed and the function call is made again by the user side stub. Monotonic sequence numbers are used to detect and discard duplicates.

Central to this RPC implementation is the grapevine database. This database stores the network address of the servers providing an instance of a particular service. The user contacts this database first to find the network address of the server.

4. Evaluation

The evaluation of this paper is surprisingly small. The authors measure the completion time of various RPC calls with different number of arguments and data size and compare it with purely local calls. I am not quite sure what to make of these results. The increased execution time compared to local implementation is obvious but perhaps they could have compared it with some existing alternative implementation to quantify the actual performance gains. They could also have run it with a transport protocol such as TCP to justify the usage of function call returns as implicit acks which is so emphatically touted .

5. Confusion
What happens with the void functions which don't return anything. How does the client know the function has been successfully executed?

Why haven't they tested it on TCP or even mentioned TCP in the paper? TCP was around at that time.

What happens if the grapevine database crashes?

1. Summary

This paper describes an implementation of Remote Procedure Calls (RPC) which provide a way for processes on different machines to transparently communicate with each other. The calling process invokes the function on the remote machine through a stub as if it is invoking a on the same machine. The RPC runtime which executes on both the client and the server machines takes care of the discovery and communication aspects of Remote Procedure Calls. An important component of this implementation is the grapevine database which provides binding and name service to the applications.

2. Problem

No adequate implementation of RPCs existed at the time. The designers of RPCs did not know the precise semantics of the call in the presence of machine and communication failures. The RPCs needed an efficient implementation. Moreover, the integration of RPCs to the existing systems was also challenging. Ideally to achieve most of these qualities, the RPC should appear to the user as if it was a normal local function call. However, no efficient implementation that provided these qualities existed at the time.

3. Contributions

This basic components of this RPC implementation include, a user process, a user side stub, a server process, a server side stub and an RPC runtime. The call to a remote procedure is just an extension of a local procedure call. When a caller calls a remote procedure, the execution of the caller is suspended and the corresponding function in the user stub is invoked. The user stub packs the arguments of the call to one or more network packets and asks the RPC runtime at the user side to send that packet to the server. On the server side the RPC runtime receives the packet and passes the arguments to the server stub. The server stub in turn makes the local procedure call at the server, receives the resulting data from it and sends it back to the user through the RPC runtime. On receipt of the result, the user process resumes its invocation. To make RPC more efficient, the result of the function call is used as an implicit ack for reliability. This helps avoids transport layer connection setup overheads and makes the execution faster. If the result is not received within a timeout window, a failure is assumed and the function call is made again by the user side stub. Monotonic sequence numbers are used to detect and discard duplicates.

Central to this RPC implementation is the grapevine database. This database stores the network address of the servers providing an instance of a particular service. The user contacts this database first to find the network address of the server.

4. Evaluation

The evaluation of this paper is surprisingly small. The authors measure the completion time of various RPC calls with different number of arguments and data size and compare it with purely local calls. I am not quite sure what to make of these results. The increased execution time compared to local implementation is obvious but perhaps they could have compared it with some existing alternative implementation to quantify the actual performance gains. They could also have run it with a transport protocol such as TCP to justify the usage of function call returns as implicit acks which is so emphatically touted .

5. Confusion
What happens with the void functions which don't return anything. How does the client know the function has been successfully executed?

Why haven't they tested it on TCP or even mentioned TCP in the paper? TCP was around at that time.

What happens if the grapevine database crashes?

1. Summary

This paper describes an implementation of Remote Procedure Calls (RPC) which provide a way for processes on different machines to transparently communicate with each other. The calling process invokes the function on the remote machine through a stub as if it is invoking a on the same machine. The RPC runtime which executes on both the client and the server machines takes care of the discovery and communication aspects of Remote Procedure Calls. An important component of this implementation is the grapevine database which provides binding and name service to the applications.

2. Problem

No adequate implementation of RPCs existed at the time. The designers of RPCs did not know the precise semantics of the call in the presence of machine and communication failures. The RPCs needed an efficient implementation. Moreover, the integration of RPCs to the existing systems was also challenging. Ideally to achieve most of these qualities, the RPC should appear to the user as if it was a normal local function call. However, no efficient implementation that provided these qualities existed at the time.

3. Contributions

This basic components of this RPC implementation include, a user process, a user side stub, a server process, a server side stub and an RPC runtime. The call to a remote procedure is just an extension of a local procedure call. When a caller calls a remote procedure, the execution of the caller is suspended and the corresponding function in the user stub is invoked. The user stub packs the arguments of the call to one or more network packets and asks the RPC runtime at the user side to send that packet to the server. On the server side the RPC runtime receives the packet and passes the arguments to the server stub. The server stub in turn makes the local procedure call at the server, receives the resulting data from it and sends it back to the user through the RPC runtime. On receipt of the result, the user process resumes its invocation. To make RPC more efficient, the result of the function call is used as an implicit ack for reliability. This helps avoids transport layer connection setup overheads and makes the execution faster. If the result is not received within a timeout window, a failure is assumed and the function call is made again by the user side stub. Monotonic sequence numbers are used to detect and discard duplicates.

Central to this RPC implementation is the grapevine database. This database stores the network address of the servers providing an instance of a particular service. The user contacts this database first to find the network address of the server.

4. Evaluation

The evaluation of this paper is surprisingly small. The authors measure the completion time of various RPC calls with different number of arguments and data size and compare it with purely local calls. I am not quite sure what to make of these results. The increased execution time compared to local implementation is obvious but perhaps they could have compared it with some existing alternative implementation to quantify the actual performance gains. They could also have run it with a transport protocol such as TCP to justify the usage of function call returns as implicit acks which is so emphatically touted .

5. Confusion
What happens with the void functions which don't return anything. How does the client know the function has been successfully executed?

Why haven't they tested it on TCP or even mentioned TCP in the paper? TCP was around at that time.

What happens if the grapevine database crashes?