RPC chains: 5 min read

RPC chains turn Remote Procedure Calls into an efficient stack

When we write applications, many of us think of REST as a common standard for inter-service communications. Yet there are many other forms of communications, RPC being one of them. It is important to note, that the choice of communication means depends on many factors like business requirements, legacy code, technologies and budget available, not to mention architectural patterns you choose.

Popular in distributed computing, RPC (remote procedure call) is a procedure where a computer program is executed in a different computer (server) while the program (the code) abstracts the connection between the client and the server.

Many of you can learn about RPC in the internet but I found it difficult to find information about “RPC chains”. I even didn’t know of its existence until recently, when I read an interesting paper at Microsoft Research. Here I want to share with you a quick preview of this paper, which I missed when looking for RPC Chains in the internet.

1. Introduction: RPC vs RPC chains

RPC chains solve the problem of performance and efficiency issues related to standard RPC, where one single task may involve several client server calls to different sites. If you look at the figure below, you can immediately notice the difference:

Figure 1: (Left) Standard RPCs. (Right) RPC chain. (link to the original paper)

RPC chains allow the client to call multiple servers in succession (A−B−E−F−C−D−A) without involving the client every time.

2. Main mechanism

As server services provided in the form of service functions (remote methods) in RPC model, they can be logically sequenced in a chain of functions specifying the next service function to execute (possibly at different servers). As authors put, they can be C# or Java methods (stored and thus retrieved from a remote repository to the service), but they cannot refer to non-local variables as they need to be compiled independently.

Figure 2: Execution of RPC chain (the image is taken from the original paper)

3. Broken chains: detection & recovery

Any server can crash during RPC chain execution. It is detected by a simple mechanism called chain heartbeats, whereby a chain periodically sends and an alive message to the client that created it, with its unique chain identifier.

If a broken chain detected, the client retransmits the request and then, thanks to cached results in each server, the process continues from the host where the chain was broken.

CONCLUSION

RPC chain combines RPC calls into a chain, thus allowing to decrease the network hops (thus smaller end-to-end latencies) and bandwidth in applications using complex nested service calls as clients don’t receive unnecessary data. For more detailed information about RPC chains, please read the original paper.

Further readings:

1. Software Architecture Patterns: 5 minute read
2. How to Scale Your Applications: 5 min read
3. Caching as a part Software Architecture: 5 min read
4. When DataViz embraces Game Development
5. Creating Users and Roles in AWS: 5 min read