本文将mark下Remote Procedure Calls(RPC)的相关notes。

Goal

Provide a layer of abstraction for process-to-process communication that enables a process on one system to invoke a function, or service, on a another system without having to deal with the problems of formatting data and parsing the request.

Introduction

In 1984, Birrell and Nelson devised a mechanism to allow programs to call procedures on other machines. A process on machine A can call a procedure on machine B. When it does so, the process on A is suspended and execution continues on B. When B returns, the return value is passed to A and A continues execution. This mechanism is called the Remote Procedure Call (RPC). To the programmer, it appears as if a normal procedure call is taking place. Obviously, a remote procedure call is different from a local one in the underlying implementation.

Steps

  1. The client calls a local procedure, called the client stub. To the client process, this appears to be the actual procedure, because it is a regular local procedure. It just does something different since the real procedure is on the server. The client stub packages the parameters to the remote procedure (this may involve converting them to a standard format) and builds one or more network messages. The packaging of arguments into a network message is called marshalling and requires serializing all the data elements into a flat array-of-bytes format.
  2. Network messages are sent by the client stub to the remote system (via a system call to the local kernel using sockets interfaces).
  3. Network messages are transferred by the kernel to the remote system via some protocol (either connectionless or connection-oriented).
  4. A server stub, sometimes called the skeleton, receives the messages on the server. It unmarshals the arguments from the messages and, if necessary, converts them from a standard network format into a machine-specific form.
  5. The server stub calls the server function (which, to the client, is the remote procedure), passing it the arguments that it received from the client.
  6. When the server function is finished, it returns to the server stub with its return values.
  7. The server stub converts the return values, if necessary, and marshals them into one or more network messages to send to the client stub.
  8. Messages get sent back across the network to the client stub.
  9. The client stub reads the messages from the local kernel.
  10. The client stub then returns the results to the client function, converting them from the network representation to a local one if necessary.

Advantages

  • You don’t have to worry about getting a unique transport address (picking a unique port number for a socket on a machine). The server can bind to any available port and then register that port with an RPC name server. The client will contact this name server to find the the port number that corresponds to the program it needs. All this will be invisible to the programmer.
  • The system can be independent of transport provider. The automatically-generated server stub can make itself available over every transport provider on a system, both TCP and UDP. The client can choose dynamically and no extra programming is required since the code to send and receive messages is automatically generated.
  • Applications on the client only need to know one transport address: that of the name server that is responsible for telling the application where to connect for a given set of server functions.
  • The function-call model can be used instead of the send/receive (read/write) interface provided by sockets. Users don’t have to deal with marshalling parameters and then parsing them out on the other side.

参考资料:

  1. CS 417/Lecture Notes