RPC

In an RPC, a client causes a procedure to execute on a different address space, usually a remote server. The procedure is coded as if it were a local procedure call, abstracting away the details of how to communicate with the server from the client program. Remote calls are usually slower and less reliable than local calls so it is helpful to distinguish RPC calls from local calls. Popular RPC frameworks include Protobuf, Thrift, and Avro.

RPC is a request-response protocol:

• Client program - Calls the client stub procedure. The parameters are pushed onto the stack like a local procedure call.
• Client stub procedure - Marshals (packs) procedure id and arguments into a request message.
• Client communication module - OS sends the message from the client to the server.
• Server communication module - OS passes the incoming packets to the server stub procedure.
• Server stub procedure - Unmarshalls the results, calls the server procedure matching the procedure id and passes the given arguments.
• The server response repeats the steps above in reverse order.

Sample RPC calls:

GET /someoperation?data=anId

POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC is focused on exposing behaviors. RPCs are often used for performance reasons with internal communications, as you can hand-craft native calls to better fit your use cases.

Disadvantage of RPC

• RPC clients become tightly coupled to the service implementation.
• A new API must be defined for every new operation or use case.
• It can be difficult to debug RPC.
• You might not be able to leverage existing technologies out of the box. For example, it might require additional effort to ensure RPC calls are properly cached on caching servers such as Squid.