implementing remote procedure calls authored by: andrew d. birrel and bruce jay nelson presented by:...
Post on 18-Dec-2015
229 views
TRANSCRIPT
Implementing Remote Procedure Calls
Authored by: Andrew D. Birrel and Bruce Jay Nelson Presented by: Terry, Jae, Denny
Outline:
An introduction to RPC
Principles to follow in RPC
An implementation of RPC
• Binding
• Packet-level Transport Protocol
• Other issues
1. Introduction to RPC
Basic idea
• Extend local procedure calls
General steps
• Caller calls a remote procedure
• System suspend caller
• Pass parameters of the call to callee
• Invoke desired procedure executed in callee
• Callee returns the result back to caller
• Caller receives the result and resumes.
RPC: Advantages
Clean and simple semantics
• Local call alike
Efficient: Procedure steps can be executed rapidly
Generality:
• Procedures: the most important mechanism for communication between parts of the algorithm
• Think about distributed computation
RPC: Major issues
The precise semantics of a call when• Machine failure• Communication failures
The presentation of address in the absence of a shared address space
Integration of remote calls into existing programming systems.
Binding Data and control protocol between caller and callee Data integrity and security in an open communication
network.
Aim to built RPC package
Primary goal: Make distributed computation easy.
Secondary goals:
• Expected to be efficient.
• Semantics should be as powerful as possible.
• Provide clients secure communication with RPC.
Built RPC: Fundamental Decisions
Paradigm for expressing control and data transfer
• Procedure call
• Reason:
• Procedures are popular:
• The major control and data transfer mechanism in the language
Alternatives:
• shared space
Built RPC: principle
Semantics of remote procedure calls:
• as close as possible to local procedure calls
Fail to obey this principle are likely to make the package difficult to use
Following this rule:
• Have to discard some attractive ideas
• No timeout limiting duration of a call
• Local calls does not set timeout
RPC: Structure
Concepts of stubs
Five modules
• User
• User-stub
• The RPC communicate package (RPCRuntime)
• Server-stub
• Server
RPC: Steps
Normal call by user invokes corresponding procedure in the user-stub User-stub place a specification of the target procedure
and the arguments into packet (marshalling) User-stub ask RPCRuntime to send RPCRuntime in callee receive packets RPCRuntime pass packet to server-stub Server-stub unpack (unmarshalling ) and call local call Server returns to server-stub Result passed back to process in the caller
Structure: RPCRuntime
RPCRuntime:
• A standard part of the operation system In charge of:
• Retransmission of not ACKed packets
• Acknowledgments of received packets
• Routing and encryption of packets TCP/IP protocol?
Structure: User and server stubs
User and server stubs:
• Automate generated by a program called Lupine Generation is specified by a interface module Interface module:
• A list of procedure names
• With the types of their arguments and results
Compare to Sun RPC:
• Interface compiler generate client and server stubs from the interface definition of the service
Structure
Interface module provide sufficient info to Lupine
Export interface:
• Program module that implements procedures in an interface
Import interface:
• program calling procedures from an interface
How to use?
Designing the interface
• Write interface module
• Presents the interface to Lupine
Write user and server code
Invoke the inter-machine binding
Handle failures.
2. Binding
Aim:
• Binds an importer of an interface to an exporter of an interface
Two questions:
• How does a client of the binding mechanism specify what he wants to be bound to?
• How does a caller determine the machine address of the callee and specify to the callee the procedure to be invoked?
Compare with port-mapper used in Sun RPC
Binding: naming
Name of an interface has two parts:
• Type
• At some level of abstraction which interface the caller expects the callee to implement
• Instance
• Which particular implementor of an abstract interface is desired.
Binding: Locating an appropriate exporter
Distributed database used
In the database:
• Entry for instance
• Individual whose connect-site is a network address
• Entry for type
• A Group whose members are keys of the instance
of that type which have been exported.
Binding: exporter side
When An exporter wishes to make his interface available to clients
Server calls the server-stub
Server-stub calls a procedure, ExportInterface in the RPCRuntime
ExportInterface is given the interface name (type and instance), and a dispatcher.
Binding: exporter side (con’t)
The procedure check the DB, making sure that:
• the instance is the member of the type
• and connect-site of the instance is the network address of the exporting machine.
Now Grapevine update the exporter information
Every export is assigned a unique identifier (counter).
Binding: importer side
When a importer wishes to bind an exporter User call user-stub User-stub calls a procedure, ImportInterface, in the
RPCRuntime, giving the desired interface type and instance.
RPCRuntime ask Grapevine for instance, get connect-site
Binding: importer side (con’t)
RPCRuntime make RPC call to the RPCRuntime on that machine asking for the binding information associated with this interface type and instance.
If the specified machine is not exporting then binding fails. Else returns :
• The corresponding unique identifier
• the table index to the importing machine Binding succeeds User-stub record info for next time:
• The exporter network address
• Identifier
• Table index of dispatcher
Binding
Now user-stub make a call on the imported remote interface
The call packet contains the unique identifier and table index of the desired interface
RPCRuntime on the callee machine receives the packet Uses the index to look up its table of current exports Verifies the unique identifier
Pass the packet to the dispatcher procedure specified in the table
Binding: compare to Port Mapper
Compare to Port Mapper in Sun RPC
• Port mapper:
• Runs locally
• Port as result
• Our implementation
• Use distributed database
• Does not use TCP/IP, do not have port
• Interface type and instance to find
• Result is table index to the dispatcher and unique ID
Which is better?
3. Packet-level transport protocol
Specialized packet-level protocol gives us:
• Minimizing the time between initiating a call and result
• Minimizing the load imposed on a server
Simple calls: how to
Caller sends a call packet containing:• A call identifier
• Call identifier• Calling machine identifier• Machine-related Process identifier• Sequence number of the transaction• Activity is defined:
[machine ID, process ID]
• data specifying the desired procedure, and arguments
Callee return a result packet containing:• The same call identifier• the results
Simple calls: how to (con’t)
A call packet is ACKed by the result packet
A result packet is ACKed by the next call packet
If duration of a call and the interval between calls are less than the transmission delay• Two packets per call, one in each direction, one call, one ACK
If calls last longer or intervals longer:• Two additional packets send (a retransmission, an explicit ACK)
An overhead we can endure
Simple calls: Call identifier
Call identifier is used for several reasons:
• Allows the caller to determine that the result is the result of current call
• Allows the callee to eliminate duplicate call packets
Simple Protocol: summary
No special connection establishment protocol
• receive of a call packet is enough
No communication to maintain idle connection
No explicit connection termination protocol
• discard state information after an interval.
Relies on the unique identifier to detect duplicates
Also assume that the call sequence number from an activity does not repeat.
Complicated Calls
Packet transmitted are modified to request an explicit ACK
Caller periodically sends probe packet to callee Callee expected to ACK to the probe Caller wait as long as probes are ACKed When communication failure
• caller should be told fairly soon (no ACK for probe) Only detect failure in communication levels
• principle of making RPC semantics similar to local calls.
Complicated Calls (con’t)
If the arguments are too large, multiple packets
Last of these packets request explicit ACK
Use only one packet buffer at each end for the call
• Avoid to include buffering and flow control Call-relative sequence number
• for multiple data packets within a call
Complicated Call: performance
If transferring a large amount of data in one direction
• Sends up to twice as needed
if represented as procedure calls
• Still desirable
Dominant advantage over requiring one ACK for each packet
• Simplifies and optimizes the implementation
Other issues
Exception handling:• Emulate signals:
• exception and catch• Add a call failed exception
• Raise if communication difficulty happened• The primary way for clients to note the difference between
local and remote calls Take process creation and swap into consideration
• Process creation and swaps consume significant cost• Aim to lower the cost• After the refinement
• simple calls create no processes• only a few process swaps in each call