Academy of Engineering and
Medical Sciences
Computer Engineering
Sem (10)
Distributed System
Lecture 5 ,6
Dr. Mutaz Hamed
1
Basics
• Distributed systems can be built using messages
with send and receive
• But these are rather low-level constructs
• Remote Procedure Call (1984 – Birrell &
Nelson) provides a higher-level alternative
• It provides access transparency, i.e. the use of a
local service (e.g. provided by the OS) has the
same form as the use of a non-local one.
2
Basics (continued)
• So a process on the client “calls” a process
on the server to execute the code of the
procedure (providing some service)
• Arguments are sent in the message to the
server
• The result is sent in the reply from the
server to the client
3
Remote Procedure Call (RPC) between
clients and Server (synchronous)
The RPC protocol allows the construction of client-server applications,
using a demand/response protocol with the management of transactions.
4
RPC between Client and Server
(asynchronous)
5
Middleware layers
Applications, services
RMI, RPC and events
Middleware
Request reply protocol & layers
External data representation
(interprocess communication primitives)
Operating System (UDP & TCP)
Remote Method Invocation (RMI)
User Datagram Protocol (UDP)
Transmission Control Protocol (TCP)
6
Stubs
A client stub (sometimes called proxy)
• Instead of the code to provide the service,
the client machine has a stub procedure.
That:
– puts the arguments in a message
– sends that message to the server
– waits for the reply message
– unpacks the result
– returns to the application call
7
Server stub (or skeleton)
A sever stub (sometimes called proxy)
• Transparency works both ways!
• Code in the server to provide the service
should also be “normal” – so it can be used
by other code on the server to provide the
same service locally ….
8
First Six Steps of RPC
9
Remaining Steps
7: add executes and returns the answer the to server
stub
8: server stub composes a reply message containing
this answer
9:the message is sent across the network
10: client OS passes reply to the client stub
11: client stub unpacks and returns the result
10
Parameter Marshalling
• Packing parameters into a message is known as
parameter marshalling
• The inverse operation is unmarshalling
• These operations need to take into account
problems associated with having different
machines and different languages in use in the
network
11
Representational issues
• Client and server can use different ways to
represent values:
– Floating point formats
– Big-endian (Western style) vs little-endian (e.g.,
Intel)
– Character sets
– Size issues (e.g. 64 bit ints or 32 bit ints)
Big-endian is an order in which the "big end" (most significant value in the
sequence) is stored first, at the lowest storage address. Little-endian is an
order in which the "little end" (least significant value in the sequence) is
stored first.
12
Generating Stubs
• The code for the stubs can be generated once the
specification of the procedure is known.
• This should ideally be done in a language-
independent way – so that the remote service is
available in many languages
• Interface Definition Language (IDL)
13
Remote Method Invocation (RMI)
• Java includes RMI in its API
• Marshalling is simpler: Java <=> Java
• It requires that objects sent as arguments or
results be serializable, i.e. there is a standard
external form for them. This allows arbitrarily
complex structures (not possible with
copy/restore parameters)
14
RMI implementation
• As with RPC, the client has a stub (called here a
proxy) for each remote class instance – to marshal
arguments to, and unmarshal results from, method
calls
• This communicates with the dispatcher for the
class, which forwards to the skeleton which
implements unmarshalling etc.
15
Dispatcher / Skeleton
• Server has a dispatcher & a skeleton for each class of
remote object
• The dispatcher receives the incoming message and uses
its method info to pass it to the right method in the
skeleton. (Dispatcher and proxy both work from the
remote interface to get the same method info!)
• Skeleton implements methods of the remote interface to
unmarshalling arguments and invokes the corresponding
method in the servant. It then marshalls the result (or
any exceptions thrown) into a reply message to the
proxy.
16
