How to choose the best RPC protocol for your needs?

Table of Contents

Introduction

In the cloud and edge computing age, scaling your processes horizontally is a given if you want to achieve high performance without paying too much upfront. To achieve this, you need some kind of protocol to allow all of your systems to communicate with each other.

A remote procedure call (RPC) protocol serves as the lynchpin holding a distributed system together. However, selecting the right RPC protocol can be complex, depending on your needs.

This article will review the basics of RPC protocols, discuss factors to consider when evaluating a protocol for your workload, and give an overview of the top protocols in use today.

What is an RPC protocol?

An RPC protocol is a standardized format for network communication. It enables you to call a remote procedure or function similar to a local one (figure 1). Remote can mean the function is located on a different device, or it can mean it’s on the same device but in a different process or container.

Local function calls and RPC function calls Fig. 1: Local function calls and RPC function calls

RPC frameworks will generate client and server code that links the local function calls to remote RPC server implementations, taking care of all the boilerplate usually involved.

How to select an RPC protocol

When building a distributed system, you must consider performance, security, and scalability. For example, a system that drives an autonomous car has different requirements than an online messaging service. Let’s discuss the categories you should evaluate when choosing an RPC protocol.

Use case

Make sure to consider your application's specific use case, as it can drastically limit your options from the start.

Do you have a local or remote use case?

Suppose you need to connect one process to others on the same machine, for example, when building a local database or indexer. In that case, you need an RPC protocol that supports inter-process communication.

In contrast, to facilitate remote communication, such as real-time chat or telemetry collection, it will be paramount to have an RPC protocol that enables remote communication.

Is your use case low- or high-level?

The abstraction level of your use case is a crucial criterion. If you’re building a high-level web-based chat system, you don’t want to slow down your engineers with RPC protocols focused on binary messages or clients using C/C++.

If you build a low-level system never directly used by a frontend developer, for example, for an IoT product, you might have to consider a protocol that sacrifices usability for low network overhead.

Performance

The performance of an RPC protocol is influenced by network overhead and serialization performance.

Do you use low-end devices?

If you’re working in an embedded or IoT environment, your devices might not have much computing power. An effective serialization format might produce fewer packages on the network. Still, if it takes too long to create these packages, it might be worth it to opt for a more computationally efficient format that produces more packages but does so much quicker (figure 2).

Serialization efficiency Fig. 2: Serialization efficiency

Do you use web browsers?

Suppose you’re working in a restricted client environment, for example, on the web, where most clients are browsers. In that case, you can’t choose from all transfer protocols that are usually available online. While UDP might perform better, a browser restricts you to HTTP or WebSockets, which both use TCP under the hood.

Do you send independent messages in parallel?

Suppose you send many messages between a client and server that don’t depend on each other. In that case, you might profit from multiplexing (figure 3), where peers use one connection to transfer several messages with one network package.

Multiplexing Fig. 3: Multiplexing

Security

Security in the form of authentication, authorization, and encryption in transit plays a huge role in creating distributed systems, especially when data is transferred via public networks.

Do you need authentication?

Authentication is about identifying clients and users in your system. If you don’t want to implement your own authentication scheme, you are well served with an RPC protocol that already includes it. If you don’t need such a feature or want to build it yourself, you might save on protocol complexity by choosing one that doesn’t include authentication.

Do you need authorization?

Authorization is about granting clients and users access to resources in your system. In the case of an RPC connection, this could include permissions to read or write specific channels. While you will handle the authentication of upstream resources, you might profit from connection permissions.

Do you need encryption in transit?

If you send public weather data, you might not need to encrypt it; reading your data on the network doesn’t pose much harm here. However, if you exchange sensitive data via RPC, it could be helpful to choose a protocol that already comes with it built-in. For example, many TCP-based RPC protocols support TLS.

Scalability

As mentioned at the start of this post, one reason to build distributed systems is to leverage horizontal scalability. If that’s the goal in your case, you might need to consider statefulness and load balancing.

Do you require stateful connections?

RPC protocols store state on different sides of a connection.

A server-side state might be good for lowering the client's resource requirements, but they’re notoriously hard to scale. A client that once used a specific server has to go to that server again; otherwise, their state isn’t available, and you have to create it again (figure 4).

State location comparison Fig. 4: State location comparison

A client-side state is easier to scale; you can move the clients between servers with every request. However, each client needs to maintain that state and potentially send it over the network, which can increase overhead.

Do you need load balancing?

If your system needs to scale horizontally, load balancing is crucial. Some RPC protocols, such as gRPC, support client-side load balancing, where the client chooses a server from a list it maintains locally. This requires more complex client logic but eliminates the need for a network request that checks which server a client should use.

Other RPC protocols, like Apache Thrift, either don’t support load balancing natively or require you to implement server-side load balancing, where the client is told which server to use. This simplifies the client and works with untrusted clients.

Ease of use

The best RPC protocols in the world won’t help if you are not able to use them. Debugging distributed systems is a complex challenge, so make sure good development resources are available.

What tooling do you need?

Can your engineers work with Netcat and Wireshark, or do they require more sophisticated tooling tailored to their RPC use cases? If they need comprehensive documentation and specifications to complete their tasks, you should also make sure your RPC protocol of choice offers such resources.

Are you comfortable with using binary formats?

You might consider this factor if your team isn’t used to binary message formats and prefers human-readable text formats. Otherwise, your development velocity might suffer greatly. Binary formats are not directly readable by humans and require additional tooling to turn them into text form.

Summary

RPC frameworks come in different flavors, and it might be difficult to decide which is the right one for your needs. However, you can filter for optimal results depending on what you’re looking to build.

With the factors discussed in this article, you can define your requirements step by step to find the right protocol for your project.

Was this article helpful?

Related Articles

Write For Us

Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 "Learn" portal. Get paid for your writing.

Write For Us

Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 “Learn” portal. Get paid for your writing.

Apply Now
Write For Us