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:
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.
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: