Remote Procedure Call (RPC) - Revision history

User: The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

2021-02-06T17:59:20Z

The LinkTitles extension automatically added links to existing pages (https://github.com/bovender/LinkTitles).

User at 19:09, 28 May 2020

2020-05-28T19:09:22Z

User: A remote procedure call (RPC) is a network programming model or interprocess communication technique that is used for point-to-point communications between software applications.

2019-01-04T22:25:43Z

A remote procedure call (RPC) is a network programming model or interprocess communication technique that is used for point-to-point communications between software applications.

User: Created page with "'''Content Coming Soon'''"

2018-12-21T15:14:35Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

@@ Line 1: / Line 1: @@
-A '''Remote Procedure Call (RPC)''' is a network programming model or interprocess communication technique that is used for point-to-point communications between software applications. Client and server applications communicate during this process. A remote procedure call is sometimes called a function call or a subroutine call.<ref>Definition - What does Remote Procedure Call (RPC) mean? [https://www.techopedia.com/definition/24022/remote-procedure-call-rpc Techopedia]</ref>
+A '''Remote Procedure Call (RPC)''' is a [[network]] programming [[model]] or interprocess communication technique that is used for point-to-point communications between [[software]] applications. Client and [[server]] applications communicate during this [[process]]. A remote procedure call is sometimes called a function call or a subroutine call.<ref>Definition - What does Remote Procedure Call (RPC) mean? [https://www.techopedia.com/definition/24022/remote-procedure-call-rpc Techopedia]</ref>
 '''History and Origins'''<ref>History and Origins of RPC [https://en.wikipedia.org/wiki/Remote_procedure_call Wikipedia]</ref><br />
-Response–request protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. In the 1990s, with the popularity of object-oriented programming, the alternative model of [[Remote_Method_Invocation_(RMI)|remote method invocation (RMI)]] was widely implemented, such as in [[Common_Object_Request_Broker_Architecture_(CORBA)|Common Object Request Broker Architecture (CORBA, 1991)]] and Java remote method invocation. RMIs in turn fell in popularity with the rise of the internet, particularly in the 2000s. Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system, which used a request-response communication protocol for process synchronization. The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents. In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" (1981), and the first practical implementation was by Andrew Birrel and Bruce Nelson, called Lupine, in the Cedar environment at Xerox PARC. Lupine automatically generated stubs, providing type-safe bindings, and used an efficient protocol for communication. One of the first business uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Network File System.
+Response–request protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. In the 1990s, with the popularity of object-oriented programming, the alternative model of [[Remote_Method_Invocation_(RMI)|remote method invocation (RMI)]] was widely implemented, such as in [[Common_Object_Request_Broker_Architecture_(CORBA)|Common Object Request Broker Architecture (CORBA, 1991)]] and Java remote method invocation. RMIs in turn fell in popularity with the rise of the [[internet]], particularly in the 2000s. Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming [[system]], which used a request-response communication protocol for process synchronization. The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents. In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" (1981), and the first practical implementation was by Andrew Birrel and Bruce Nelson, called Lupine, in the Cedar environment at Xerox PARC. Lupine automatically generated stubs, providing type-safe bindings, and used an efficient protocol for communication. One of the first [[business]] uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Network File System.
 '''How RPC Works'''<ref>How does RPC Work? [https://users.cs.cf.ac.uk/Dave.Marshall/C/node33.html Dave Marshall]</ref><br />
-An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. Figure 1. below shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. 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 to the client. After the RPC call is completed, the client program continues. RPC specifically supports network applications.
+An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. Figure 1. below shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. 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 to the client. After the RPC call is completed, the client program continues. RPC specifically supports network applications.
@@ Line 22: / Line 22: @@
 *Run-time libraries and header files
 *Name service provider (sometimes referred to as the Locator)
-*Endpoint mapper (sometimes referred to as the port mapper)
+*Endpoint mapper (sometimes referred to as the [[port]] mapper)
-In the RPC model, you can formally specify an interface to the remote procedures using a language designed for this purpose. This language is called the [[Interface_Definition_Language_(IDL)|Interface Definition Language]], or IDL. The Microsoft implementation of this language is called the Microsoft Interface Definition Language, or MIDL. After you create an interface, you must pass it through the MIDL compiler. This compiler generates the stubs that translate local procedure calls into remote procedure calls. Stubs are placeholder functions that make the calls to the run-time library functions, which manage the remote procedure call. The advantage of this approach is that the network becomes almost completely transparent to your distributed application. Your client program calls what appear to be local procedures; the work of turning them into remote calls is done for you automatically. All the code that translates data, accesses the network, and retrieves results is generated for you by the MIDL compiler and is invisible to your application.
+In the RPC model, you can formally specify an interface to the remote procedures using a language designed for this purpose. This language is called the [[Interface_Definition_Language_(IDL)|Interface Definition Language]], or IDL. The Microsoft implementation of this language is called the Microsoft Interface Definition Language, or MIDL. After you create an interface, you must pass it through the MIDL compiler. This compiler generates the stubs that translate local procedure calls into remote procedure calls. Stubs are placeholder functions that make the calls to the run-time library functions, which manage the remote procedure call. The advantage of this approach is that the network becomes almost completely transparent to your distributed [[application]]. Your client program calls what appear to be local procedures; the work of turning them into remote calls is done for you automatically. All the code that translates [[data]], accesses the network, and retrieves results is generated for you by the MIDL compiler and is invisible to your application.
 '''RPC Model'''<ref>RPC Model [https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.progcomc/rpc_mod.htm IBM]</ref><br />
 The remote procedure call (RPC) model is similar to a local procedure call model. In the local model, the caller places arguments to a procedure in a specified location such as a result register.
-Then, the caller transfers control to the procedure. The caller eventually regains control, extracts the results of the procedure, and continues execution. RPC works in a similar manner, in that one thread of control winds logically through two processes: the caller process and the server process. First, the caller process sends a call message that includes the procedure parameters to the server process. Then, the caller process waits for a reply message (blocks). Next, a process on the server side, which is dormant until the arrival of the call message, extracts the procedure parameters, computes the results, and sends a reply message. The server waits for the next call message. Finally, a process on the caller receives the reply message, extracts the results of the procedure, and the caller resumes execution. The Remote Procedure Call Flow figure (Figure 2) illustrates the RPC paradigm.
+Then, the caller transfers [[control]] to the procedure. The caller eventually regains control, extracts the results of the procedure, and continues execution. RPC works in a similar manner, in that one thread of control winds logically through two processes: the caller process and the server process. First, the caller process sends a call message that includes the procedure parameters to the server process. Then, the caller process waits for a reply message (blocks). Next, a process on the server side, which is dormant until the arrival of the call message, extracts the procedure parameters, computes the results, and sends a reply message. The server waits for the next call message. Finally, a process on the caller receives the reply message, extracts the results of the procedure, and the caller resumes execution. The Remote Procedure Call Flow figure (Figure 2) illustrates the RPC paradigm.
@@ Line 47: / Line 47: @@
-*RPC Process: The RPC process starts on the client side. The client application calls a local stub procedure instead of code implementing the procedure. Stubs are compiled and linked with the client application during development. Instead of containing code that implements the remote procedure, the client stub code retrieves the required parameters from the client address space and delivers them to the client runtime library. The client runtime library then translates the parameters as needed into a standard [[Network Data Representation (NDR)|Network Data Representation (NDR)]] format for transmission to the server.
+*RPC Process: The RPC process starts on the client side. The client application calls a local stub procedure instead of code implementing the procedure. Stubs are compiled and linked with the client application during development. Instead of containing code that implements the remote procedure, the client stub code retrieves the required parameters from the client address space and delivers them to the client runtime library. The client runtime library then translates the parameters as needed into a [[standard]] [[Network Data Representation (NDR)|Network Data Representation (NDR)]] format for transmission to the server.
-''Note'': There are two NDR marshalling engines within the RPC runtime library: NDR20 and NDR64. A 32-bit client initiating the communication uses the NDR20 marshalling engine; a 64-bit client can use either the NDR20 or the NDR64 marshalling engine. The same marshalling engine is used on both the client and the server side, regardless of program architecture. There is a slight decline in performance when either the client or server uses an architecture different from the other because the marshalling engine must do additional translation during the communication.
+''Note'': There are two NDR marshalling engines within the RPC runtime library: NDR20 and NDR64. A 32-bit client initiating the communication uses the NDR20 marshalling engine; a 64-bit client can use either the NDR20 or the NDR64 marshalling engine. The same marshalling engine is used on both the client and the server side, regardless of program [[architecture]]. There is a slight decline in performance when either the client or server uses an architecture different from the other because the marshalling engine must do additional translation during the communication.
@@ Line 66: / Line 66: @@
 '''RPC Architecture'''<ref>RPC Architecture [https://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx Microsoft]</ref><br />
-By replacing dedicated protocols and communication methods with a robust and standardized interface, RPC is designed to facilitate communication between client and server processes. The functions contained within RPC are accessible by any program that must communicate using a client/server methodology. The following figure (Figure 3.) shows the RPC architecture.
+By replacing dedicated protocols and communication methods with a robust and standardized interface, RPC is designed to facilitate communication between client and server processes. The functions contained within RPC are accessible by any program that must communicate using a client/server [[methodology]]. The following figure (Figure 3.) shows the RPC architecture.

← Older revision		Revision as of 19:09, 28 May 2020
Line 1:		Line 1:
−	A ~~remote procedure call~~ (RPC) is a network programming model or interprocess communication technique that is used for point-to-point communications between software applications. Client and server applications communicate during this process. A remote procedure call is sometimes called a function call or a subroutine call.<ref>Definition - What does Remote Procedure Call (RPC) mean? [https://www.techopedia.com/definition/24022/remote-procedure-call-rpc Techopedia]</ref>	+	A '''Remote Procedure Call (RPC)''' is a network programming model or interprocess communication technique that is used for point-to-point communications between software applications. Client and server applications communicate during this process. A remote procedure call is sometimes called a function call or a subroutine call.<ref>Definition - What does Remote Procedure Call (RPC) mean? [https://www.techopedia.com/definition/24022/remote-procedure-call-rpc Techopedia]</ref>

← Older revision		Revision as of 22:25, 4 January 2019
Line 1:		Line 1:
−	'''~~Content Coming Soon~~'''	+	A remote procedure call (RPC) is a network programming model or interprocess communication technique that is used for point-to-point communications between software applications. Client and server applications communicate during this process. A remote procedure call is sometimes called a function call or a subroutine call.<ref>Definition - What does Remote Procedure Call (RPC) mean? [https://www.techopedia.com/definition/24022/remote-procedure-call-rpc Techopedia]</ref>
		+
		+
		+	'''History and Origins'''<ref>History and Origins of RPC [https://en.wikipedia.org/wiki/Remote_procedure_call Wikipedia]</ref><br />
		+	Response–request protocols date to early distributed computing in the late 1960s, theoretical proposals of remote procedure calls as the model of network operations date to the 1970s, and practical implementations date to the early 1980s. In the 1990s, with the popularity of object-oriented programming, the alternative model of [[Remote_Method_Invocation_(RMI)\|remote method invocation (RMI)]] was widely implemented, such as in [[Common_Object_Request_Broker_Architecture_(CORBA)\|Common Object Request Broker Architecture (CORBA, 1991)]] and Java remote method invocation. RMIs in turn fell in popularity with the rise of the internet, particularly in the 2000s. Remote procedure calls used in modern operating systems trace their roots back to the RC 4000 multiprogramming system, which used a request-response communication protocol for process synchronization. The idea of treating network operations as remote procedure calls goes back at least to the 1970s in early ARPANET documents. In 1978, Per Brinch Hansen proposed Distributed Processes, a language for distributed computing based on "external requests" consisting of procedure calls between processes. Bruce Jay Nelson is generally credited with coining the term "remote procedure call" (1981), and the first practical implementation was by Andrew Birrel and Bruce Nelson, called Lupine, in the Cedar environment at Xerox PARC. Lupine automatically generated stubs, providing type-safe bindings, and used an efficient protocol for communication. One of the first business uses of RPC was by Xerox under the name "Courier" in 1981. The first popular implementation of RPC on Unix was Sun's RPC (now called ONC RPC), used as the basis for Network File System.
		+
		+
		+	'''How RPC Works'''<ref>How does RPC Work? [https://users.cs.cf.ac.uk/Dave.Marshall/C/node33.html Dave Marshall]</ref><br />
		+	An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure. Figure 1. below shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. 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 to the client. After the RPC call is completed, the client program continues. RPC specifically supports network applications.
		+
		+
		+	[[File:RPC.gif\|400px\|How RPC Works]]<br />
		+	Figure 1. source: [https://users.cs.cf.ac.uk/Dave.Marshall/C/node33.html Dave Marshall]
		+
		+
		+	Figure 1: Remote Procedure Calling Mechanism A remote procedure is uniquely identified by the triple: (program number, version number, procedure number) The program number identifies a group of related remote procedures, each of which has a unique procedure number. A program may consist of one or more versions. Each version consists of a collection of procedures which are available to be called remotely. Version numbers enable multiple versions of an RPC protocol to be available simultaneously. Each version contains a a number of procedures that can be called remotely. Each procedure has a procedure number.
		+
		+
		+	'''RPC Components'''<ref>Major RPC Components [https://msdn.microsoft.com/en-us/library/windows/desktop/aa374169(v=vs.85).aspx MSDN]</ref><br />
		+	RPC includes the following major components:
		+	*MIDL compiler
		+	*Run-time libraries and header files
		+	*Name service provider (sometimes referred to as the Locator)
		+	*Endpoint mapper (sometimes referred to as the port mapper)
		+
		+	In the RPC model, you can formally specify an interface to the remote procedures using a language designed for this purpose. This language is called the [[Interface_Definition_Language_(IDL)\|Interface Definition Language]], or IDL. The Microsoft implementation of this language is called the Microsoft Interface Definition Language, or MIDL. After you create an interface, you must pass it through the MIDL compiler. This compiler generates the stubs that translate local procedure calls into remote procedure calls. Stubs are placeholder functions that make the calls to the run-time library functions, which manage the remote procedure call. The advantage of this approach is that the network becomes almost completely transparent to your distributed application. Your client program calls what appear to be local procedures; the work of turning them into remote calls is done for you automatically. All the code that translates data, accesses the network, and retrieves results is generated for you by the MIDL compiler and is invisible to your application.
		+
		+
		+	'''RPC Model'''<ref>RPC Model [https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.progcomc/rpc_mod.htm IBM]</ref><br />
		+	The remote procedure call (RPC) model is similar to a local procedure call model. In the local model, the caller places arguments to a procedure in a specified location such as a result register.
		+	Then, the caller transfers control to the procedure. The caller eventually regains control, extracts the results of the procedure, and continues execution. RPC works in a similar manner, in that one thread of control winds logically through two processes: the caller process and the server process. First, the caller process sends a call message that includes the procedure parameters to the server process. Then, the caller process waits for a reply message (blocks). Next, a process on the server side, which is dormant until the arrival of the call message, extracts the procedure parameters, computes the results, and sends a reply message. The server waits for the next call message. Finally, a process on the caller receives the reply message, extracts the results of the procedure, and the caller resumes execution. The Remote Procedure Call Flow figure (Figure 2) illustrates the RPC paradigm.
		+
		+
		+	[[File:RPC1.jpg\|400px\|RPC Model]]<br />
		+	Figure 2. source: [https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.progcomc/rpc_mod.htm IBM]
		+
		+
		+	In the RPC model, only one of the two processes is active at any given time. Furthermore, this model is only an example. The RPC protocol makes no restrictions on the concurrency model implemented, and others are possible. For example, an implementation can choose asynchronous Remote Procedure Calls so that the client can continue working while waiting for a reply from the server. Additionally, the server can create a task to process incoming requests and thereby remain free to receive other requests.
		+
		+
		+	'''RPC Processes and Interactions'''<ref>RPC Processes and Interactions [https://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx#w2k3tr_rpc_how_tvtb Microsoft]</ref><br />
		+	The RPC components make it easy for clients to call a procedure located in a remote server program. The client and server each have their own address spaces; that is, each has its own memory resource allocated to data used by the procedure. The following figure (Figure 4.) shows the RPC process.
		+
		+
		+	[[File:RPC3.gif\|400px\|RPC Processes and Interactions]]<br />
		+	Figure 4. source: [https://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx#w2k3tr_rpc_how_tvtb Microsoft]
		+
		+
		+	*RPC Process: The RPC process starts on the client side. The client application calls a local stub procedure instead of code implementing the procedure. Stubs are compiled and linked with the client application during development. Instead of containing code that implements the remote procedure, the client stub code retrieves the required parameters from the client address space and delivers them to the client runtime library. The client runtime library then translates the parameters as needed into a standard [[Network Data Representation (NDR)\|Network Data Representation (NDR)]] format for transmission to the server.
		+
		+	''Note'': There are two NDR marshalling engines within the RPC runtime library: NDR20 and NDR64. A 32-bit client initiating the communication uses the NDR20 marshalling engine; a 64-bit client can use either the NDR20 or the NDR64 marshalling engine. The same marshalling engine is used on both the client and the server side, regardless of program architecture. There is a slight decline in performance when either the client or server uses an architecture different from the other because the marshalling engine must do additional translation during the communication.
		+
		+
		+	The client stub then calls functions in the RPC client runtime library (rpcrt4.dll) to send the request and its parameters to the server. If the server is located on the same host as the client, the runtime library can use the Local RPC (LRPC) function and pass the RPC request to the Windows kernel for transport to the server. If the server is located on a remote host, the runtime library specifies an appropriate transport protocol engine and passes the RPC to the network stack for transport to the server. RPC can use other IPC mechanisms, such as named pipes and Winsock, to accomplish the transport. The other IPC mechanisms allow RPC more flexibility in the way in which it completes its communications tasks.
		+
		+
		+	'''Terms and Definitions'''<ref>Terms and Definitions associated with RPC [https://technet.microsoft.com/en-us/library/cc787851(v=ws.10).aspx Technet]</ref><br />
		+	The following terms are associated with RPC.
		+	*Client: A process, such as a program or task, that requests a service provided by another program. The client process uses the requested service without having to “deal” with many working details about the other program or the service.
		+	*Server: A process, such as a program or task, that responds to requests from a client.
		+	*Endpoint: The name, port, or group of ports on a host system that is monitored by a server program for incoming client requests. The endpoint is a network-specific address of a server process for remote procedure calls. The name of the endpoint depends on the protocol sequence being used.
		+	*Endpoint Mapper (EPM): Part of the RPC subsystem that resolves dynamic endpoints in response to client requests and, in some configurations, dynamically assigns endpoints to servers.
		+	*Client Stub: Module within a client application containing all of the functions necessary for the client to make remote procedure calls using the model of a traditional function call in a standalone application. The client stub is responsible for invoking the marshalling engine and some of the RPC application programming interfaces (APIs).
		+	*Server Stub: Module within a server application or service that contains all of the functions necessary for the server to handle remote requests using local procedure calls.
		+
		+
		+	'''RPC Architecture'''<ref>RPC Architecture [https://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx Microsoft]</ref><br />
		+	By replacing dedicated protocols and communication methods with a robust and standardized interface, RPC is designed to facilitate communication between client and server processes. The functions contained within RPC are accessible by any program that must communicate using a client/server methodology. The following figure (Figure 3.) shows the RPC architecture.
		+
		+
		+	[[File:RPC2.gif\|400px\|RPC Architecture]]<br />
		+	Figure 3. source: [https://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx Microsoft]
		+
		+
		+	===References===
		+	<references/>
		+
		+
		+	===Further Reading===
		+	*What is RPC and why is it so important? [https://superuser.com/questions/616098/what-is-rpc-and-why-is-it-so-important superuser.com]
		+	*Remote Procedure Call (RPC) - A Different Paradigm for Accessing Network Services [https://web.cs.wpi.edu/~cs4514/b98/week8-rpc/week8-rpc.html WPI Computer Science Department]
		+	*Remote Procedure Calls - Introduction and Implementation [https://www.cs.rutgers.edu/~pxk/417/notes/08-rpc.html Rutgers Department of Computer Science]