**4.1. Working and architecture of RPC**

RPC is analogous to a function call extending the notion of conventional local procedure calling so that procedure need not exists in the same address space as the calling procedure. Like a function call, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure.

The client makes a procedure call that sends a request to the server and waits for response, as shown in **Figure 6**. The thread is blocked from processing until either a reply is received, or it times out. When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply back to the client. After the RPC call is completed, the client program continues its normal execution [4].

Stub: Stubs are generated at the static compilation time and then deployed to the client side which is used as a proxy for the client. Client-side proxy acts as a mediator between the client and the broker and provides additional transparency between them and the client so that a remote object appears like a local one. The proxy hides the inter-process communication (IPC) at protocol level and performs marshaling of parameter values and un-marshaling of results from the server.

system-specific networking functions and provides high-level APIs to mediate between the server and the broker. It also receives the requests, unpacks the requests, un-marshals the method arguments, calls the suitable service, and also marshals the result before sending it

Evolution and Paradigm Shift in Distributed System Architecture

http://dx.doi.org/10.5772/intechopen.80644

13

• The client calls the client stub. The call is a local procedure call, with parameters pushed on

• The client stub packs the parameters into a message and makes a system call to send the

• The client's local operating system sends the message from the client machine to the server

• The local operating system on the server machine passes the incoming packets to the server stub. • The server stub unpacks the parameters from the message. Unpacking the parameters is

Finally, the server stub calls the server procedure. The reply traces the same steps in the

back to the client [2].

**Figure 7.** Event flow in RPC.

machine.

called un-marshaling.

Sequence of events during an RPC:

to the stack in the normal way.

message. Packing the parameters is called marshaling.

reverse direction. **Figure 7** shows the event flow of RPC.

Skeleton: Skeleton is generated by the service interface compilation and then deployed to the server side, which is used as a proxy for the server. Server-side proxy encapsulates low-level

**Figure 6.** Remote procedure call.

Evolution and Paradigm Shift in Distributed System Architecture http://dx.doi.org/10.5772/intechopen.80644 13

**Figure 7.** Event flow in RPC.

**4. Remote procedure mechanism**

12 New Trends in Industrial Automation

**4.1. Working and architecture of RPC**

for a response to be returned from the remote procedure.

client program continues its normal execution [4].

**Figure 6.** Remote procedure call.

Remote procedure call works on client–server communication protocol that is used by one program to request a service from a program located in another computer in a network without understanding network details. It is based on RPC is a synchronous operation requiring the requesting program to be suspended till the results of remote procedure are returned [13].

RPC is analogous to a function call extending the notion of conventional local procedure calling so that procedure need not exists in the same address space as the calling procedure. Like a function call, the calling arguments are passed to the remote procedure and the caller waits

The client makes a procedure call that sends a request to the server and waits for response, as shown in **Figure 6**. The thread is blocked from processing until either a reply is received, or it times out. When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply back to the client. After the RPC call is completed, the

Stub: Stubs are generated at the static compilation time and then deployed to the client side which is used as a proxy for the client. Client-side proxy acts as a mediator between the client and the broker and provides additional transparency between them and the client so that a remote object appears like a local one. The proxy hides the inter-process communication (IPC) at protocol level and performs marshaling of parameter values and un-marshaling of results from the server.

Skeleton: Skeleton is generated by the service interface compilation and then deployed to the server side, which is used as a proxy for the server. Server-side proxy encapsulates low-level system-specific networking functions and provides high-level APIs to mediate between the server and the broker. It also receives the requests, unpacks the requests, un-marshals the method arguments, calls the suitable service, and also marshals the result before sending it back to the client [2].

Sequence of events during an RPC:


Finally, the server stub calls the server procedure. The reply traces the same steps in the reverse direction. **Figure 7** shows the event flow of RPC.
