Implementing Remote Procedure Call
Birrell, Nelson (1984)
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.