Implementing Remote Procedure Call

What sort of paper is this?

• Big idea.
• Describes an implementation.
• Discusses trade-offs.

Why RPC?

• Clean simple semantics.
• Easy for people to use
• Efficiency.
• Generality.

Goals

• Make distributed computing easy.
• Highly efficient (no more than 5 times local).
• Same semantics as local procedure call.
• Secure communication.

Choices discarded

• Message passing.
• Parallel fork.

Structure

• Use Mesa to create interface modules.
• Stubs
  • Automatically generated from interface modules.
  • Client stub is called like a regular procedure call. Marshalls arguments and passes off to runtime.
  • Server stub accepts requests, unmarshalls arguments, calls local server, sends result.
• RPCRuntime
  • Takes care of message transmission.
  • Handles retransmission and acknowledgments.

Binding

• Naming
  • Name has a type and an instance.
  • type: abstract indication of what service is provided. (e.g. mail server)
  • instance: which particular server is handling the service. (e.g. steward's mail server)
  • agreement between client and server.
• Use Grapevine as binding service.
  • For each RName, maintain a connect-site and member- list.
  • connect-site: network address to which to connect to use the particular service.
  • member-list: for groups, a list of RNames that identify every instance of a service.
  • both instances and types are RNames.
  • for an instance, the connect-site is that last machine that exported the instance.
  • for a type, the Grapevine entry is a group containing RNames for all the instances of the type.
• Exporting an interface
  • Call RPCRuntime ExportInterface.
  • identify the type, instance, and name of server stub procedure that will do dispatch.
  • RPCRuntime maintains a table of currently exported interfaces on the machine.
  • Each interface is assigned a unique id.
• Importing an interface
  • Call RPCRuntime ImportInterface.
  • specify type and instance.
  • RPCRuntime contacts grapevine to find an exporter.
  • The unique ID is returned.
  • Local machine records the imported interface.

Transport Protocol

• Built their own protocol Why?
  • Minimize latency (not transfer).
  • Minimize server load (i.e. setup must be cheap).
  • Enforce desired RPC semantics.
• Simple calls.
  • All parameters fit in one packet.
  • Response is the ACK.
  • Next message is the ACK of the response.
  • Implies only one outstanding RPC at a time (this is OK because RPC semantics are like local, they are not asynchronous).
• Complicated calls.
  • Multiple packets.
  • Requires an ACK on every packet.
  • Last packet does not require explicitly ACK.
• Exceptions
  • Emulate MESA signals.
  • Server can transmit and exception; local stub must handles it and respond accordingly.
  • Uses failed exception to indicate communication failure.
• Processes
  • One process per call too expensive.
  • Keep a pool of processes at server.
  • Use process identifiers to exchange messages between particular, cooperating processes.
• Security
  • Provides for encrypted RPC.

Performance

• Measurements are pretty minimal.
• Convince you that the system works.
• Analysis isn't very detailed, so you can't say much about the numbers.