Remote procedure call (RPC) is a common communication primitive for invoking a service from a remote computer. RPCs hide the complexities of network programming behind the familiar face of a standard procedure call, allowing developers to focus on the application’s business logic. Many of the modern applications accessible through the Internet or intranet are distributed and consist of diverse services, running on multiple computer systems that are often located at remote sites. This means that in order to complete a task, such an application may have to make multiple RPCs to different servers, which may result in unacceptably low responsiveness of the application.
To minimize overheads of multiple RPCs, Song et al. propose a new communication primitive: an RPC chain that allows a client to specify the flow of multiple successive requests. This can significantly improve the communication pattern and latency, as control can pass directly from server to server, before returning to the client when the end of the chain is reached, as opposed to plain RPCs, where control must return to the client after each single request. An important feature is that RPC chains are dynamic--that is, servers that execute chaining functions specified by a client calculate them at runtime. This is a very powerful generalization of the original RPC mechanism, and the authors do a very good job of presenting it.
Apart from describing the general design of an RPC chain mechanism, Song et al. also discuss: a way to handle legacy RPC services; isolation strategies to prevent chaining functions from crashing the servers that execute them; mechanisms for handling exceptions thrown along the chain; detection and recovery from chains broken by server crashes; and infrastructure for the debugging and profiling of RPC chains.
Performance improvement of an example RPC chain implementation compared to standard RPC is measured with micro-benchmarks and two applications, Web mail and storage. Micro-benchmarks are used to establish the overheads introduced by the chaining functions. The application benchmarks show how the responsiveness of test applications improves when using RPC chains, instead of multiple standard RPCs. The authors conclude the paper with a discussion of the limitations of RPC chains and possible extensions.
The ideas and implementations are described very clearly. This is an excellent paper.