DISTRIBUTED
COMPUTING
Sunita Mahajan, Principal, Institute of
Computer Science, MET League of
Colleges, Mumbai
Seema Shah, Principal, Vidyalankar
Institute of Technology, Mumbai
University
© Oxford University Press 2011
Chapter - 4
Remote Communication
© Oxford University Press 2011
Topics
•
•
•
•
•
•
•
•
Introduction to Remote Communication
Remote Procedural Call Basics
RPC Implementation
RPC Communication
Other RPC Issues
Case Study: Sun RPC
Remote invocation Basics
RMI Implementation
© Oxford University Press 2011
Introduction to Remote
Communication
© Oxford University Press 2011
Introduction
• Middleware
© Oxford University Press 2011
Remote Procedural Call Basics
© Oxford University Press 2011
Local Procedure Call
© Oxford University Press 2011
Remote Procedure Call
• Basic RPC operation
© Oxford University Press 2011
RPC operation
© Oxford University Press 2011
Elements of RPC mechanism
implementation
•
•
•
•
•
Client
Client stub
RPC Runtime
Server stub
Server
© Oxford University Press 2011
RPC Execution
© Oxford University Press 2011
Stub generation
• Manual generation
• Auto generation using Interface Definition
Language (IDL)
© Oxford University Press 2011
RPC Compilation
© Oxford University Press 2011
RPC Implementation
© Oxford University Press 2011
RPC implementation
• Types of RPC messages:
– Call / Request
– Reply
© Oxford University Press 2011
RPC Call/ Request message
Reply msg, =1
© Oxford University Press 2011
RPC reply conditions
© Oxford University Press 2011
RPC reply message
© Oxford University Press 2011
Parameter Passing Semantics
• Funtion of client stub is to take parameters
from the process, pack them into a msg and
send it to the server stub.
• Various parameter passing semantics are:
• Call by value, call by reference and call by
copy/restore
© Oxford University Press 2011
• Call-by-value semantic : Call-by-value copies
all parameters into a message before
transmission .
• works well for compact data type such as int,
char and arrays.
• Marshalling : The process of packing the
parameters into a msg is termed as marshalling.
• Marshalling process consist of the following steps:
• Identify the msg data-arguments in client or server and
transmit result
• Encode the data on the sender’s machine and place
them into msg buffer
• On receiving machine, decode the msg
© Oxford University Press 2011
Call-by-value semantic
© Oxford University Press 2011
Byte ordering
© Oxford University Press 2011
• Call-by –reference semantic : passes pointers to
the parameters that are passed from the client to
the server.
• This semantic is used in DS having a shared
memory mechanism
• Call-by-copy/restore semantic: uses temporary
storage (stack) accessible to both programs.
• It is not often used to handle linked data
structure such as list, graph, tree, hash table etc.
bcz it takes large amount of stack memory.
© Oxford University Press 2011
Server management
• Server implementation
– Stateless server: does not maintain the state
information of RPC execution in the system.
– Stateful server: the state information of all the
calls of client is maintained by the server
© Oxford University Press 2011
Server management
• Server creation semantics: During RPC, the
middleware creates and installs the server process earlier or
creates it on demand.
• Depending of the time duration for which a server is active,
servers are classified into
– Instance per call: after RPC execution, middleware
destroy this server.
– Instance per session: instance is maintained such that
multiple RPC calls can be executed by same client.
– Server manager register with binding agent, client contact
binding agent and get server manager address
– Persistent servers: servers exists indefinitely and is
sharable among the clients.
© Oxford University Press 2011
RPC communication
• RPC call semantics: how often the remote
procedure may be executed under fault
condition
© Oxford University Press 2011
• a. May-Be Call Semantics
• This means that the caller waits until a pre-determined
timeout period and then continues to execute.
• This semantics is applicable where the response message
is less important.
• b. Last-Once Call Semantics
• This call semantics uses the idea of retransmitting the call
message based on timeouts until the caller receives a
response.
• The results of the last executed call are used by the
caller
© Oxford University Press 2011
c. Last-of-Many Call Semantics
• This semantics neglects orphan calls unlike last-once call
semantics. Orphan call is one whose caller has expired due to
node crash.
• To identify each call, unique call identifiers are used which to
neglect orphan calls.
• A response is accepted only if the call identifier associated
with it matches the identifier of the most recent call else it is
ignored.
d. At-Least-Once Call Semantics
• This semantics guarantees that the call is executed one or
more times but does not specify which results are returned to
the caller.
© Oxford University Press 2011
e. Exactly-Once Call Semantics
• This is the strongest and the most desirable
call semantics. It eliminates the possibility of a
procedure being executed more than once
irrespective of the number of retransmitted
call.
© Oxford University Press 2011
Orphan calls
• Calls whose caller has expired due to a node
crash
• Handle orphan calls by using:
– Extermination
– Reincarnation
– Gentle reincarnation
– Expiration
© Oxford University Press 2011
RPC communication protocols
• Request protocol
• Request/Reply protocol
• Request/Reply/ Acknowledge- Reply protocol
© Oxford University Press 2011
Request protocol
© Oxford University Press 2011
Request/Reply protocol
© Oxford University Press 2011
Request/Reply/ Acknowledge- Reply
protocol
© Oxford University Press 2011
Client server binding process
© Oxford University Press 2011
Client Server binding
• Issues
• Types of binding
– Server naming
– Server locating
– Fixed binding
– Dynamic binding
• Binding agent primitives
– Register
– Deregister
– Lookup
© Oxford University Press 2011
• At compile time
• At link time
• At run time
Other RPC Issues
© Oxford University Press 2011
Other issues in RPC implementation
•
•
•
•
•
Exception handing and security
RPC in heterogeneous environment
Failure handling
Optimizing RPC execution
Various types of complicated RPCs
© Oxford University Press 2011
Exception handing and security
• If RPC does not executed successfully, the
server reports an error in the reply msg.
• So RPC should have an effective exception
handling mechanism to report failures to
clients.
• Some programming language supports
exception handling mechanism but if language
does not support than in such a case, the local
operating system needs to take care of these
exception.
© Oxford University Press 2011
RPC in heterogeneous environment
• Data presentation
• Transport protocol
• Control protocol
© Oxford University Press 2011
Failure handling mechanism in RPC
•
•
•
•
•
Client cannot find the server
Request from client to the server is lost
Reply from server to the client is lost
Server crashes after getting the request
Client crashes after sending the request
© Oxford University Press 2011
RPC Optimization
• To achieve better performance of distributed
applications using RPC
© Oxford University Press 2011
Concurrent access to multiple servers
•
•
•
•
•
•
Use of threads
Early reply technique
Call buffering approach
Serving multiple requests simultaneously
Reducing call workload of server
Using reply cache for idempotent RPC
© Oxford University Press 2011
Early Reply technique
© Oxford University Press 2011
Call buffer approach
© Oxford University Press 2011
Complicated and special RPCs
• Complicated RPCs
– RPCs with long duration calls or with gaps
between calls
– RPCs with long messages
• Special RPCs:
– Call back RPC
– Broadcast RPC
– Batch mode RPC
© Oxford University Press 2011
Call back RPC
• Client handle is provided to the server
• Client process should wait for callback RPC
• Handle callback deadlocks
© Oxford University Press 2011
Case Study: Sun RPC
© Oxford University Press 2011
Case Study- Sun RPC
• Uses rpcgen compiler which generates
– Header file
– XDR filter file
– Client stub file
– Server stub file
© Oxford University Press 2011
Remote invocation Basics
© Oxford University Press 2011
Remote Object Invocation
• Distributed object concept
– Remote objects reference
– Remote interface
© Oxford University Press 2011
RMI
© Oxford University Press 2011
RMI vs LMI
© Oxford University Press 2011
RMI Implementation
© Oxford University Press 2011
RMI implementation
Design issues in RMI
• RMI invocation
semantics
• Level of transparency
– Marshalling
– Message passing
– Task of locating and
contacting the remote
object for the client
• RMI invocation semantics
– Maybe semantics
– At-least-once semantics
– At-most-once semantics
© Oxford University Press 2011
Invocation semantics
© Oxford University Press 2011
Level of Transparency
© Oxford University Press 2011
Components of RMI
© Oxford University Press 2011
RMI execution components
•
•
•
•
•
•
Communication module
Remote reference module
RMI software
Server program
Client program
Binder
© Oxford University Press 2011
RMI execution
© Oxford University Press 2011
RMI software
• Proxy
• Dispatcher
• Skeleton
© Oxford University Press 2011
Types of objects
© Oxford University Press 2011
Remote invocation readiness
© Oxford University Press 2011
RMI binding
• Implicit binding
• Explicit binding
© Oxford University Press 2011
Parameter passing in RMI
• Pass by value
• Pass by reference
© Oxford University Press 2011
Case study: Java RMI
© Oxford University Press 2011
Java RMI layer
© Oxford University Press 2011
Summary
•
•
•
•
•
•
•
•
Introduction to Remote Communication
Remote Procedural Call Basics
RPC Implementation
RPC Communication
Other RPC Issues
Case Study: Sun RPC
Remote invocation Basics
RMI Implementation
© Oxford University Press 2011