Remote Procedure Call | PRC
Remote Procedure Call (RPC is acronym for Remote Procedure Call) is an inter-process communication technology that allows a computer program to call a procedure in another address space (commonly on another computer, connected by a network). The programmer does not care about implementation details of remote interaction: from the standpoint of the code, the call is similar to local procedure calls.
RPC is a popular technology for implementing the client-server model of distributed computing. A remote procedure call is initiated by the client sending a message to a remote server to perform a specific procedure. A response is returned to the client. An important difference between procedure calls and remote procedure calls sites is that in the first case, the call may fail because of network problems. In this case, there is not even guaranteed that the procedure was invoked.
The idea of RPC dates from 1976, when it was described in RFC 707. One of the earliest commercial uses of the technology was made by Xerox in the “Courier” in 1981. The first popular implementation for Unix was Sun’s RPC (now called ONC RPC), used as the basis of the Network File System, and is still used on many platforms.
Another implementation was the pioneer in Unix Network Computing System (NCS) from Apollo Computer, which was later used as the foundation of the DCE / RPC in Distributed Computing Environment (DCE). A decade later Microsoft adopted DCE / RPC as the basis for its own implementation of RPC, MSRPC, the DCOM was implemented based on this system. Still in the same period of the 1990s, the Xerox PARC ILU and CORBA offered another RPC paradigm based on distributed objects, with mechanisms of inheritance.
Similarly, currently is used as XML interface description language and HTTP as the network protocol to build Web services, whose implementations include SOAP and XML-RPC.
The standard Remote Procedure Call is similar to the model of local calls to procedures, in which the routine that invokes the procedure places the arguments in a well known area of memory and transfers control to the running procedure, which reads the arguments and processes them. At some point, the routine regains control, extracting the result of executing a well known area of memory. After that, the routine continues with normal execution.
In the RPC model, the process invocation occurs in a similar manner. One thread is responsible for control of two processes: invoker and server. The caller process first sends a message to the server process and waits (blocks) a reply message. The invocation message contains the parameters of the procedure and the reply message contains the result of performing the procedure. Once the reply message is received, the results of implementation of the procedure are collected and the caller continues execution.
On the server side, a process remains on hold until the arrival of a message invocation. When an invocation message is received, the server extracts the parameters, processes them and produces results that are sent in the reply message. The server then returns to await a new message invocation.
In this model, only one of two processes remains active at a given instant of time. However, this model serves as an illustration. The ONC RPC protocol makes no restrictions on implementations that allow competition between these processes. For example, one could choose to implement asynchronous calls, which would allow the client to continue with useful work while he was awaiting a reply message.
A remote procedure call for local calls differs in some points:
- Error handling: failures of the server or network must be addressed.
- Global variables and side effects: Since the server does not have access to the client’s address space, protected no arguments can be passed as global variables or returned.
- Performance: remote calls typically operate at lower speeds in one or more orders of magnitude compared to local calls.
- Authentication: since remote procedure calls can be transported over unsecured networks, authentication may be required.
Thus, even though there are several tools that automatically generate the client and server, the protocols must be developed carefully.
The RPC protocol can be implemented on different types of transport protocols, since it is indifferent to the way a message is transmitted between processes. Importantly, the RPC protocol does not implement any form of reliability and that the application must take care regarding the type of protocol over which RPC operates. If it is a reliable protocol such as TCP, the reliability concerns are already addressed. On the other hand, if the transport layer is unreliable, such as UDP, timeout mechanisms, retransmission and duplicate detection must be implemented, since these services are not provided by the PRC.
Due to the independence of the transport layer, the RPC protocol does not modify the semantics of remote calls, nor its performance requirements. Semantics can be inferred from the transport layer in use. For example, consider the case in which the PRC operates on a layer of unreliable transport such as UDP. If an application retransmits RPC messages invocation, after timeouts, and receives no answers, can not infer the number of times the procedure was performed. If a message is received, it can infer that the procedure was performed at least once. The server can perform the control of the number of executions, simply recording the number of the last procedure executed successfully, avoiding re-execution of the same call.
On the other hand, when PRC operates over a reliable transport layer such as TCP, the application can infer from a reply message, the procedure was executed exactly once. However, if no response is received message, the application can not assume that the procedure was not performed. Note that even using a connection-oriented protocol, applications still require timeouts to identify server failures.
There are also many other means of transport besides datagram and connection-based protocols. For example, query-response protocols such as VMTP may be used by TCP.
To allow servers to be accessed by different clients, different standardized RPC systems have been created. Most of them use an interface description language (IDL) for different platforms can call procedures. Making use of a tool like RPCGEN, you can create interfaces between client and server from an IDL file, called stubs. Since the stubs are embedded in client and server applications, the PRC is not a middleware layer.
In encryption, the client remote procedure calls client stub procedure like any other place, and the internal implementation of the client stub is responsible for initiating the process of transmission to the server stub, packaging the call in a message. Upon arriving, the server stub unpacks the message and invokes the procedure locally, waiting for the return. When the local call returns, the server stub is responsible for initiating the process of transmission to the client stub, bundling the answer in a message. Getting the answer is unpacked by the client stub, and returned locally to the procedure that made the remote call.
By invoking the remote procedure, you should be aware that client and server may be different platforms, which represent data differently. In this case you need a common protocol for data representation, such as XDR, or ensuring that both parties know the data to convert data types supported. Being a remote call, in another address space, one must note also the challenge of moving a pointer. In this case, the internal implementation of the PRC must pass the contents of the pointer by copying and restoring the memory area in the return of the procedure.
RPC — Limitations
Different implementations of remote procedure call are often mutually incompatible, although there are exceptions. Therefore, the use of a particular implementation is likely to result in dependence on the vendor implementation. This incompatibility between implementations is also shown in the availability of features, supporting different network protocols and different file systems.
Most implementations do not support P2P and / or asynchronous interaction between client and server (by definition, the remote call corresponds to a local call from the viewpoint of application, blocking the way). Synchronous communication implies the constant availability of both the client and the server.
Study: From Wikipedia, the free encyclopedia. The text is available under the Creative Commons.
- Cloud Computing: The Concept and Examples of its Virtual Services | Part 1 - July 23, 2012
- Why Rapidly Growing Companies Need Cloud Computing | Part 1 - July 22, 2012
- Web Designing Process | Strategic Planning | Part 1 - August 7, 2011