rpc远程过程调用_远程过程调用| RPC

rpc远程过程调用

远程过程调用| 中华人民共和国 (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是Remote Procedure Call的缩写)是一种进程间通信技术，它允许计算机程序在另一个地址空间(通常在通过网络连接的另一台计算机上)中调用过程。 程序员不在乎远程交互的实现细节：从代码的角度来看，该调用类似于本地过程调用。

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.

RPC是一种流行的技术，用于实现分布式计算的客户端-服务器模型。 客户端向远程服务器发送消息以执行特定过程，从而启动远程过程调用。 响应返回给客户端。 过程调用站点和远程过程调用站点之间的重要区别是，在第一种情况下，由于网络问题，调用可能会失败。 在这种情况下，甚至无法保证已调用该过程。

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.

RPC的想法可以追溯到1976年，当时它在RFC 707中进行了描述。该技术最早的商业用途之一是Xerox在1981年的“ Courier”中进行的。Unix的第一个流行实现是Sun的RPC(现在称为ONC)。 RPC)，用作网络文件系统的基础，并且仍在许多平台上使用。

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.

另一个实现是Apollo Computer公司的Unix网络计算系统(NCS)的先驱，后来被用作分布式计算环境(DCE)中DCE / RPC的基础。 十年后，微软采用DCE / RPC作为自己实现RPC，MSRPC的基础，DCOM就是基于此系统实现的。 仍在1990年代的同一时期，施乐PARC ILU和CORBA提供了另一种基于分布式对象并具有继承机制的RPC范例。

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.

同样，当前被用作XML接口描述语言，而HTTP被用作构建Web服务的网络协议，其实现包括SOAP和XML-RPC。

RPC模型 (RPC Model)

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.

在RPC模型中，进程调用以类似的方式发生。 一个线程负责控制两个过程：调用者和服务器。 调用者进程首先将消息发送到服务器进程，然后等待(阻止)回复消息。 调用消息包含过程的参数，回复消息包含执行过程的结果。 收到回复消息后，将收集该过程的执行结果，然后调用方继续执行。

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.

在此模型中，两个过程中只有一个在给定的时刻保持活动状态。 但是，此模型只是一个示例。 ONC RPC协议对允许这些进程之间竞争的实现不做任何限制。 例如，可以选择实现异步调用，这将允许客户端在等待回复消息时继续进行有用的工作。

本地过程的远程过程调用在某些方面有所不同： (A remote procedure call for local calls differs in some points:)

1. Error handling: failures of the server or network must be addressed.
   错误处理：必须解决服务器或网络故障。
2. 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.
   全局变量和副作用：由于服务器无法访问客户端的地址空间，因此受保护的任何参数都不能作为全局变量传递或返回。
3. Performance: remote calls typically operate at lower speeds in one or more orders of magnitude compared to local calls.
   性能：与本地呼叫相比，远程呼叫通常以一个或多个数量级的较低速度运行。
4. 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.

因此，即使有几种自动生成客户端和服务器的工具，也必须谨慎地开发协议。

运输语义学 (Transport Semantics)

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.

RPC协议可以在不同类型的传输协议上实现，因为它与在进程之间传输消息的方式无关。 重要的是，RPC协议不实现任何形式的可靠性，并且应用程序必须注意RPC操作所基于的协议类型。 如果它是诸如TCP之类的可靠协议，则已经解决了可靠性问题。 另一方面，如果传输层不可靠(例如UDP)，则必须实施超时机制，重传和重复检测，因为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.

由于传输层的独立性，RPC协议不会修改远程调用的语义或其性能要求。 可以从使用中的传输层推断出语义。 例如，考虑PRC在不可靠的传输层(例如UDP)上运行的情况。 如果应用程序在超时后重新传输RPC消息调用，并且没有收到任何答案，则无法推断该过程已执行的次数。 如果收到消息，则可以推断该过程至少执行了一次。 服务器可以执行执行次数的控制，只需记录成功执行的最后一个过程的次数即可，而无需重新执行同一调用。

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.

另一方面，当PRC在可靠的传输层(例如TCP)上运行时，应用程序可以从回复消息中推断出，该过程仅执行了一次。 但是，如果未收到响应消息，则应用程序无法假定未执行该过程。 请注意，即使使用面向连接的协议，应用程序仍然需要超时来识别服务器故障。

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.

除了数据报和基于连接的协议之外，还有许多其他传输方式。 例如，TCP可以使用诸如VMTP之类的查询响应协议。

实施RPC (Implementing RPC)

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.

为了允许不同的客户端访问服务器，已创建了不同的标准化RPC系统。 它们中的大多数使用接口描述语言(IDL)，以便不同平台可以调用过程。 利用RPCGEN之类的工具，可以从IDL文件(称为存根)在客户端和服务器之间创建接口。 由于存根嵌入在客户端和服务器应用程序中，因此PRC不是中间件层。

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.

通过调用远程过程，您应该意识到客户端和服务器可能是不同的平台，它们代表不同的数据。 在这种情况下，您需要一个通用的数据表示协议，例如XDR，或确保双方都知道数据以转换支持的数据类型。 作为另一个地址空间中的远程呼叫，必须注意移动指针的挑战。 在这种情况下，PRC的内部实现必须在过程返回时通过复制和还原存储区来传递指针的内容。

RPC —局限性 (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.

大多数实现不支持客户端与服务器之间的P2P和/或异步交互(根据定义，从应用程序的角度来看，远程调用与本地调用相对应，从而阻碍了方式)。 同步通信意味着客户端和服务器的持续可用性。

Study: From Wikipedia, the free encyclopedia. The text is available under the Creative Commons.

研究：来自维基百科，免费的百科全书。 该文本可在“ 知识共享”下找到 。

翻译自: https://www.eukhost.com/blog/webhosting/remote-procedure-call-rpc/

rpc远程过程调用