SOFA

An overview of RPC

Soroush Fathi's photo
Soroush Fathi
·

6 min read

Table of contents

Introduction

we have two types of IPC, message-based and shared memory. Socket, RPC and Pipe are messaged-base communication because the processes are executing on a separate system to provide remote service.

Why RPC conceptualize?

say that you are a bank and you have to send synchronously send OTP to your user to login them as below.

 def login(email, passwd):
    """ A Function to Handle Login Process
    """
    # some code
    # some code 
    # .....
    notification_otp(email)

🤔Question 1: How would you implement this? e.g. make an HTTP Call using the REST
🤔Question 2: What is the code problem for using REST?
🔹 every language has its own requests lib: in a real project, each service might be written in a different language
🔹 harder development, handling a failure or response results everywhere
🔹 not a clean code

what if we abstract out a repetitive task like communications protocol, object creation, failure, retries, streaming, etc. which is where RPC comes into the picture 🤓 the developer just focuses on writing core business logic in a function body that looks like a procedure call.

What is RPC?

RPC is a standardised communication between services. it looks like a routine procedure call, but it talks over the network with other services. The goal is to eliminate almost all the complexity of calling another function from another service.
🤔Question 3: Why RPC are magnitudes slower than local procedure calls?
🔹 marshalling and unmarshalling
🔹 network packet movement

Stub in RPC

assume that someone needs to convert (serialize) the information from one service to another service written in a different language over the network, and convert it back to native objects. Stub is a library that is supposed to help us in this area.

  • A client-side stub (called proxy) is responsible for the conversion(marshalling) of parameters and deconversion(unmarshalling) of results.

  • A server-side stub receives this message, unpack the marshalled parameters, and performs the procedure on the server

Marshalling and Unmarshalling Parameters

  1. involves packaging parameters into forms that can be transmitted over a network, the stub then transmits a message to a server using message passing

  2. On the client side, parameter marshalling involves converting the machine-dependent data into XDR before they are sent to the server. because of a different data representation on other machines (e.g. 32-bit integer or 64-bit integer, little-Indian or big-Indian), many RPC systems define the machine-independent representation of data. One such representation is known as external data representation (XDR)

  3. On the server side, the XDR data are unmarshalled and converted to a machine-dependent representation for the server.

Failure scenarios

  • at most one: use the timestamp to detect repeated messages

  • exactly one: we need to remove the risk that the server will never receive the request. To accomplish this, the server must implement the “at most once” protocol. The client must resend each RPC call periodically until it receives the ACK for that call.

Stub Generator

  1. Manually: RPC implementor

  2. Automatically: IDL (more common)

    e.g. on Windows stub code compiled from MIDL

IDL (interface definition language)

Like any other big application, we have to set up a config file to make a connection between other services. An interface definition language (IDL) is used to set up communications between clients and servers in remote procedure calls (RPC). There have been many variations of this such as Sun RPC, ONC RPC, DCE RPC, gRPC and so on. gRPC is the most famous implementation right now for RPC we are going to talk about it later.

+----------------+
| Client         |
|  +----------+  |         +---------------+
|  |   main   |  |         | Server        |
|  |----------|  |         |  +----------+ |
|  | stub_cli |----(comms)--->| stub_svr | |
|  +----------+  |         |  |----------| |
+----------------+         |  |   func   | |
                           |  +----------+ |
                           +---------------+

we first write the Interface Definition. For example, if you are using gRPC you can use the .proto format. then we write the client and server program that implements the interface.
when you run a stub generator, it will take this .proto file and generate Java code for you and the necessary piece of components that is required for making a network call, retries, etc. The beauty of it is right here, you just need to specify a destination language for the converter and it will convert it to that language, so it's just like a regular function call 😛.

gRPC

gRPC is a free and open-source framework developed by Google. gRPC is a member of CNCF, like Docker and Kubernetes. So it's an important project and is being developed.
prerequires :

  • HTTP/2

  • protocol buffers

Suppose that you have an Online Shop Website, so you have multiple services that should have to connect.

for setting up this architecture we need some :

  • Standard API

  • Standard Data Type

  • Standard for Errors

  • Load Balancer

  • a lot of other things

One of the most popular standards for implementing API is the REST standard which uses JSON. But in this article, we use gRPC. In addition, you can generate code for 12 programming languages using a protobuf file (expect php)

sample of .proto file

// The syntax for this file is proto3
syntax = "proto3";

/* Person is used to identify users
 * across our system */
message Person {
    // the age as of the person's creation
    int32 age = 1;
    // the first name as documented in the signup form
    string first_name = 2;
    string last_name = 3; // last name as documented in the signup form
    // small_picture represents a small .jpg file
    bytes small_picture = 4;
    bool is_profile_verified = 5;
    // height of the person in cm
    float height = 6;

    // a list of phone numbers that is optional to provide at signup
    repeated string phone_numbers = 7;
}

WEB API VS RPC

Interesting to know where API came from where, let's understand it by examining an example. Suppose we want to have access to a person's bank transactions. To do this, we need to connect to the bank's database using the programming language we have 😐. Now we want to do mathematical calculations that, given the heaviness of the function and that it has been written before, we want to use the service provided by the banking system. For this purpose, we need to establish an RPC connection with the bank system so that this function can be executed and we can receive the desired output 😶. What's our challenge here?

  • 🔐Security

  • 🤯Handle Connections

so here is API comes from ...

Event-Driven VS Request-Response API

Event-Driven API

  • webHooks

  • webSocket

  • HTTPStreaming

Request-Response API

  • REST

  • RPC

  • QraphQL

REST VS RPC VS GraphQL

REST

  • all about resources

  • JSON and XML

  • POST, GET, PUSH, UPDATE, DELETE

RPC

  • all about actions

  • GET and POST

  • advantage: easy to understand, high performance, light way payload

  • disadvantage: discovery is difficult, Lead to Function Explosion

GraphQL

  • By Facebook

  • POST, GET

  • Smaller payload size