“Computers are good at following instructions, but not at reading your mind.” — Donald Knuth

A typical RPC as it traverses the network — Image credit: keypuncher staff.

Remote procedure calls (hereafter referred to as RPCs) have been around since before I was born -- see Remote procedure call. According to that article, the first popular implementation of RPC was Sun RPC which formed a basis for Network File System.

RPC Steps

According to this article: What is Remote Procedure Call (RPC)? | Definition from TechTarget

The following steps occur during an RPC:
The client calls the client stub. The call is a local procedure call with parameters pushed onto the stack in the usual way.
The client stub packs the procedure parameters into a message and makes a system call to send the message. The packing of the procedure parameters is called marshaling.
The client's local OS sends the message from the client device to the remote server device.
The server OS's transport layer passes the incoming packets to the server stub.
The server stub unpacks the parameters — called unmarshaling — from the message.
When the server procedure is finished, it returns to the server stub, marshaling the return values in a message. The server stub then sends the message to the transport layer.
The transport layer sends the message to the client transport layer, which then returns the message to the client stub.
The client stub unmarshalls the return parameters and the execution returns to the caller.

This is best illustrated by this diagram:

This one show the passage of the RPC over the network through time:

Round trip of an RPC from client to server and back — The timeline of the passage of an RPC from the client to the server and back to the client.

Importance of Idempotence for RPCs

Idempotence of operations tends to be critical for RPCs. This is because of the unpredictable nature of computer networks.

An idempotent operation can be defined as: performing the same operation multiple times and having it result in the same effect as if it had only been being performed one time.

Examples of idempotence in the physical world:

Pushing an elevator call button.
Pulling the “stop” cable on a city bus.
Pushing a pedestrian traffic button.

Examples of non-idempotent operations are:

Adding elements to a list. Every time you add the same element to the list, the list grows.
Incrementing a counter. Each time you perform the increment operation, the counter goes up.

Examples of idempotence in computing are:

Creating a file or directory in a file system operating system with the exact same name.
Setting an email address in a database. Setting the same value multiple times results in the same final state.
Appending to a file (as opposed to overwriting it).
Retrying failed requests in distributed systems.
- Ideally this operation is idempotent or you are going to have a lot of upset customers! Example: when they only wanted to remove one item from their shopping cart ended up removing multiple items!
An HTTP GET request -- see https://en.wikipedia.org/wiki/HTTP#Request_methods.

YouTube videos on idempotence:

Further information on idempotence:

Some Types of RPCs

Synchronous. The client sends a request to the server and waits for the server to respond.
Nonblocking. The client application sends a request to a server to process a large dataset. The client continues with other tasks and periodically checks if the server has completed processing the dataset.
Callback. A client application requests a file download from a server and provides a callback function to handle the downloaded file. The server calls the callback function once the file is ready.
Broadcast. The client sends a request to multiple servers simultaneously, and each server processes the request independently. The client may or may not wait for responses from all servers.
Batch Mode. A client application sends a batch of database queries to a server. The server processes all the queries and returns a single response with the results of each query.

Security Implications of RPCs

Carefully managing the security of RPCs is important! These are SOME (not all) of the things to consider:

Authentication and Authorization

Risk: Unauthorized access to services.
Mitigation: Implement strong authentication mechanisms to verify the identity of clients and servers.

Data Confidentiality

Risk: Sensitive data being intercepted during transmission.
Mitigation: Use encryption protocols such as TLS (Transport Layer Security) to encrypt data in transit, ensuring that it cannot be read by unauthorized parties.

Replay Attacks

Risk: An attacker intercepts and replays a valid data transmission.
Mitigation: Implement nonce values (see: https://en.wikipedia.org/wiki/Cryptographic_nonce) or timestamps in requests to ensure that each request is unique and cannot be reused.

Denial of Service (DoS) Attacks

Risk: Overloading the server with a large number of requests, causing it to become unresponsive.
Mitigation: Implement rate limiting, request throttling, and other DoS protection mechanisms to prevent abuse.

Injection Attacks

Risk: Malicious code or commands being injected into RPC requests.
Mitigation: Validate and sanitize all input data to prevent injection attacks such as SQL injection or command injection.

Man-in-the-Middle Attacks

Risk: An attacker intercepts and potentially alters the communication between the client and server.
Mitigation: Use mutual TLS to authenticate both the client and server, ensuring that communication is secure and trusted.

Versioning and Compatibility

Risk: Incompatibility between different versions of services leading to security vulnerabilities.
Mitigation: Use versioning strategies and backward compatibility to ensure that updates do not introduce security flaws.
Good luck with this last one! Due to a lack of standardization, RPC protocols tend to compete with one another!

Advantages of RPCs

Some pros of RPCs:

Relatively short processing times.
- This depends heavily on the amount of traffic traversing the network.
Abstracts developers from the details of computer networks.
- Programmers are able to interact with the network with the language of their choice.
  - Exception: more obscure languages tend to lack RPC support.
RPCs can be used in both local and distributed environments.
Processes can be outsourced, potentially making better use of individual computers.
Scalable, especially when using the cloud: https://en.wikipedia.org/wiki/Cloud_computing.

Disadvantages of RPCs

Some cons of RPCs:

No uniform standard for RPCs.
- In fact, standards tend to compete with one another!
Typically slower than local procedure calls because they tend to run over a network.
Error rates tend to increase due to:
- dividing the work into separate processing instances
- the complexity of computer networks.
Can only pass by value, which hinders the use of pointers.
Typically unsuited to transferring large data sets, though there are some exceptions if:
- you have an abundant amount of time or
- you have a lot of computer network resources.