RPC Message Protocol

The distributed information system is defined as “a number of interdependent computers linked by a network for sharing information among them”. A distributed information system consists of multiple autonomous computers that communicate or exchange information through a computer network. There are three ways by which entities in the distributed systems communicate:

• Interprocess Communication: It is a low-level communication paradigm. Examples are: Distributed shared memory like a mailbox
• Remote Invocation: It is a high-level and direct communication paradigm. Examples are: RPC, RMI, etc
• Indirect Communication: It is a high-level indirect communication paradigm. Examples are: Group communication, Publish/Subscribe model, etc

RPC stands for Remote Procedure Call. In RPC, a computer program causes a procedure to operate in a different address space, and it is programmed as if it were a normal procedure call.  Whether the subroutine is local to the current program or remote, the programmer writes essentially the same code. A request-response message-passing mechanism is generally used to accomplish this type of client-server interaction. It’s preferable to think of it as a generic structure for distributed systems. RPC is popular because it is built on the semantics of a local procedure call: the application software makes a call to a procedure, regardless of whether it is local or remote, and waits for it to return.  RPCs are represented via remote method invocation in the object-oriented programming paradigm. 

Theoretical suggestions of remote procedure calls as the paradigm of network operations come from the 1970s, while actual implementations emerge from the early 1980s. In 1981, Bruce Jay Nelson is credited with coining the term ‘Remote procedure call’. It is widely used in: 

• Protobufs (Google)
• Thrift on Facebook
• Finagle on Twitter

RPC aims to make network communication appear as if it were a function call. An application developer’s job can be considerably simplified if he is entirely unaware of whether an operation is local or remote. When the procedures being called are methods of objects in an object-oriented language, RPC is known as a remote method invocation. While the RPC concept is simple, it has some flaws listed below:

• The network between the calling and called processes is prone to limit message sizes and has a proclivity for losing and reordering messages.
• The calling and called processes may operate on machines with vastly different architectures and data representation types.

RPC mechanism consists of two key components:

• A protocol that controls the messages delivered between the client and server processes and deals with the underlying network’s possibly unfavorable characteristics.
• The arguments are packaged into a request message on the client computer, which is then translated back into the arguments on the server machine, and the return value is translated back into the parameters. A stub compiler is a name given to this part of the RPC system.
• Client-server request lost
• Server-client reply lost
• Server crashes after receiving a request
• Client crashes after delivering the request

The fundamental algorithm is easy to understand. The client sends a request message, which is acknowledged by the server. The server then sends a reply message after completing the operation, which the client acknowledges.

RPC timeline

Following steps are followed in the RPC mechanism:

• Each RPC takes place within a thread. A thread is a single control flow that has just one point of execution at any one time. An application thread is a thread that is generated and maintained by application code.
• Both RPCs and RPC run-time calls are issued by RPC apps using application threads. One or more client application threads, each of which can conduct one or more RPCs, make up an RPC client.
• In addition, an RPC server employs one or more call threads provided by the RPC run-time framework to execute called remote operations. The server application thread sets the maximum number of concurrent calls it will execute when it starts listening.
• There is only one call thread in single-threaded programs. In multi-threaded applications, the maximum number of call threads is determined by the application’s architecture and RPC implementation policies. The call threads are created in the server execution context by the RPC run-time mechanism.
• An RPC can be used in both client and server environments. As a result, when a client application thread contacts a remote procedure, it becomes part of an RPC thread, which is a logical thread of execution.
• An RPC thread is a conceptual construct that extends over real execution threads and the network to include the different phases of an RPC.
• The calling client application thread joins the RPC thread after making an RPC. Until the call returns, the RPC thread usually retains execution control.
• The RPC thread of a successful RPC passes through the execution stages depicted in RPC Thread Execution Phases.
• The following items are included in the execution phase:
  • The RPC thread starts in the client process when a client application thread makes an RPC to its stub; the client thread then joins the RPC thread.
  • The RPC thread connects to the server across the network.
  • The RPC thread becomes a calling thread, which runs the remote procedure.
  • The calling thread becomes part of the RPC thread when a called remote operation is running.
  • When the call completes, the calling thread is no longer part of the RPC thread.
  • The RPC thread then returns to the client via the network.
  • When the RPC thread reaches the calling client application thread, it delivers any call results, and the client application +thread exits the RPC thread.

Getting Around Network Limitations:

To deal with the reality that networks aren’t ideal conduits, RPC protocols frequently perform extra duties. There are two such functions:

• Deliver messages in a timely manner.
• Fragmentation and reassembly are used to support huge message sizes.

In most situations, the RCP protocol builds its own reliable message delivery layer on top of an unreliable substrate (e.g., UDP/IP). Similar to TCP, such an RPC protocol would most likely implement dependability using acknowledgements and timeouts.

Benefits of RPC:

• Process-oriented and thread-oriented architectures are both supported by remote procedure calls.
• Remote procedure calls can be utilized in both a distributed and a local context.
• The user is not aware of RPC’s underlying message transmission method.
• To enhance performance, RPC skips several of the protocol layers.
• In remote procedure calls, the work required to rewrite and develop the code is minimal.

Drawbacks of RPC:

• The notion of a remote procedure call can be implemented in a variety of ways. It isn’t a set of rules.
• RPC does not allow for hardware architectural flexibility. It is solely dependent on interaction.
• Costs have increased as a result of the remote procedure call.