Distributed Objects

Interprocess Communication - Introduction

• This is concerned with Middleware.

2
Interprocess Communication -
Characteristics
• Message passing between a pair of processes can be
supported by TWO message communication operations:
SEND and RECEIVE.
• This activity involves communication of data from sending
process to the receiving process and may involve the
synchronization of two process.
• Synchronous Communication – where S and R
synchronize at every message. Performs Blocking operation.
• Asynchronous Communication - S operation is non
blocking but R can be blocking or non blocking.
• Message Destination - Messages are sent as pairs
(Internet address, local port).
• Local port is message destination within computer,
3
specified as integer. Port has one receiver but many sender.
Interprocess Communication -
Characteristics

agreed port
any port
socket socket

message

client server

other ports

Internet address = 138.37.94.248 Internet address = 138.37.88.249

Interprocess communication using Sockets

4
Interprocess Communication -
Characteristics
• Reliability
• Reliable Communication in terms of
• Validity: Any message in the outgoing message buffer is
eventually delivered to the incoming message buffer
• Integrity: The message received is identical to one sent, and
no messages are delivered twice

• Ordering
• Messages should be delivered in the order in which
they were transmitted by sender. If it is out of order
then it is regarded as failure by such application.

5
Client-server Communication

• This form of communication is designed to support the

roles and message exchanging in Client server
interaction.
• Synchronous request reply communication.
• It is reliable because reply from server is
acknowledgement to client.
• Achieved through request-reply protocol
Client Server

Request
doOperation
message getRequest
select object
(wait) execute
Reply method
message sendReply
(continuation)

6
Client-server Communication

• Operations of the request-reply protocol

doOperation();
Sends a request message to the remote server and returns
the reply.
The arguments specify the remote server, the operation to
be invoked and the arguments of that operation.
getRequest ();
Acquires a client request via the server port.
sendReply();
Sends the reply message back to the client at its Internet
address and port.
7
Client-server Communication
• Message Identifier consists of-
• A requestId from sending process in increasing sequence
and,
• An identifier for sender process <port , internet address>

messageType int (0=Request, 1= Reply)

requestId int
remoteReference RemoteRef
operationId int or Operation
arguments array of bytes

Message Identifiers – Request Reply message structure

8
Client-server Communication
• Failure model for Request-Reply protocol

• If three primitives <do operation, get request, send

reply> are implemented over UDP datagrams, then
they suffer from communication failures. Such as
• Omission failure
• Messages are not guaranteed to deliver.
• Also, protocol can suffer from failure of process.
This means crash failures means when they halted
they remains halted.

9
Client-server Communication
• Time Out
• Are due to request or reply message getting lost.
• do-Operation can do after time out.
• For lost message do-Operation send request
repeatedly.

• Discarding Duplicate request message

• Due to re-transmission of messages.
• Due to time out after sending
• Request Identifier to be attached with messages to
filter out duplicate messages.

10
Client-server Communication
• Lost Reply Messages
• If server has already sent reply when it receives a
duplicate request it will need to execute the operation
again to obtain the result, unless it has stored the
result of original execution.
• Some servers can execute their operations more than
once and obtain the same results each time.

11
Client-server Communication
• RPC Exchange Protocol
• Three protocols with different semantics in
the presence of communication failure are
used for implementing various types of RPC.
• They are
• The request (R) protocol
• The request-reply (RR) protocol
• The request-reply- acknowledge reply
(RRA) protocol

12
Client-server Communication
• The R protocol is used when there is no value to
be returned from the procedure and the client
requires no confirmation that the procedure has
been executed
• The RR protocol is useful for client-server
exchange
• The RRA is based on exchange of three messages,
The acknowledge reply message contains the
requestId from the reply message being
acknowledged. This helps server in discarding
the message from history

13
Client-server Communication

Name Messages sent by

Client Server Client
R Request
RR Request Reply
RRA Request Reply Acknowledge reply

Messages passed in client-server communication

14
Group Communication
The pair wise exchange of message is not the best model for
communication from one process to a group of other
processes, as for example when a service is implemented as a
number of different processes in different computers,
perhaps to provide fault tolerance or to enhance availability.
A multicast operation is more appropriate – this is an
operation that sends a single message from one process to
each of the members of a group of processes, usually in such
a way that the membership of the group is transparent to the
sender.
There is a range of possibilities in the desired behavior of a
multicast. The simplest provides no guarantees about
message delivery or ordering.
15
Group Communication - Characteristics

Multicast message provide a useful infrastructure for

constructing distributed systems with the following
characteristics:
Fault tolerance based on replicated services: A replicated
services consists of a group of servers. Client requests are
multicast to all the members of the group, each of which
performs an identical operation. Even when some of the
members fail, clients can still be served.
Finding the discovery servers in spontaneous
networking:
Multicast message can be used by servers and clients to
locate available discovery services in order to register their
interfaces or to look up the interfaces of other services in the
distributed system.
16
Group Communication - Characteristics

Better Performance through Replicated data:

Data are replicated to increase the performance of a service –
in some cases replicas of the data are placed in users
computers. Each time the data changes, the new value is
multicast to the processes managing the replicas.
Propagation of event notifications:
Multicast to a group may be used to notify processes when
something happens For example, a news system might
notify interested users when a new message has been posted
on a particular newsgroup.
IP multicast & review need a group of the above users of
group communication to see which of them can be satisfied
by IP multicast.
17
IP multicast – an implementation of
group communication
IP Multicast is built on top of the internet Protocol, IP.
IP packets are addressed to computers- ports belong to the
TCP and UDP levels.
IP multicast allows the sender to transmit a single IP packets
to a set of computers that forms a multicast group.
The sender is unaware of the identities of the individual
recipient and of the size of the group.
A multicast group is specified by a class D internet address -
that is, an address whose first 4 bits are 1110 in IPv4.

18
Reliability and ordering of multicast
The IP multicast suffers from omission failures.
• Recipients may drop the message because its buffer is full.
• One multicast router to another may be lost.
Another factor is that any process may fail.
Ordering is another issue.

19
Events and notifications
The idea behind the use of events is that one object can react
to a change occurring in another object.
Notification of events are essentially asynchronous and
determined by their receivers.
In particular, in interactive applications, the actions that the
user performs on objects, are seen as events that cause
changes in the objects that maintain the state of the
application.
The objects that are responsible for displaying a view of the
current state are notified whenever the state changes.

20
Events and notifications
Distributed event-based systems extend the local event
model by allowing multiple objects at different locations to
be notified of events taking place at an object.
They use the publish subscribe- paradigm, in which an
object that generates events publishes the type of events that
it will make available for observation by other objects.
Object that want to receive notification from an object that
has published its event subscribe to the types of events that
are of interest to them.
Objects that represent events are called notification.
Notification may be stored, sent in messages, queried and
applied in a variety of orders to different thing
21
Events and notifications
When a publisher experiences an event, subscribers that
expressed an interest in that type of event will receive
notifications.
Subscribing to a particular type of event is also called
registering interest in that type of event.

22
Events and notifications
Each event has attributes that specify information about
that event, such as the name or identifier of the object that
generated it, the operation, its parameters and the time
An event Sources can generate events of one or more
different types.
Distributed event based systems have two main
characteristics:
- Heterogeneous
- Asynchronous

23
Participants in Distributed Event
Notification
The object of Interest: Object that experiences changes of state, as a
result of its operations being invoked.
Event: An event occurs at an object of interest as the result of the
completion of a method execution.
Notifications: It is an object that contains information about an event
(type and its attributes).
Subscriber: It is an object that has subscribed to some type of events
in another object. It receives notifications about such events.
Observer objects: The main purpose is to decouple an object of
interest from its subscribers. An object of interest can have many
different subscribers with different interests.
Publisher: This is an object that declares that it will generate
notifications of particular types of event. A publisher may be an object
of interest or an observer.
24
Architecture of Distributed Event
Notification

1. An object of interest is inside the event service without the

observer. It sends notifications directly to the subscriber
2. An object of interest is inside the event service with observer. It
sends notifications via observer to the subscriber
3. An object of interest is outside the event service. In this case, an
observer queries the object of interest in order to discover when
25
events occur. The observer sends notifications to the subscriber
Remote Procedure Call
• Remote procedure call (RPC) is a powerful technique for
constructing distributed, client-server based applications.
• RPC is a technology that allows a computer program to cause a
subroutine or procedure to execute in another address space
(commonly on another computer on a shared network) without the
programmer explicitly coding the details for this remote
interaction.
•That is, the programmer would write essentially the same code
whether the subroutine is local to the executing program, or
remote.
• When the software in question is written using object-oriented
principles

26
Remote Procedure Call - Terms
• Client
• Server
• Endpoint
• Endpoint Mapper (EPM)
• Client Stub
• Server Stub

27
Remote Procedure Call - Process
• The RPC process starts on the client side.
• The client application calls a local stub procedure instead of code
implementing the procedure.
• Stubs are compiled and linked with the client application during
development.
• Instead of containing code that implements the remote procedure,
the client stub code retrieves the required parameters from the
client address space and delivers them to the client runtime library.
• The client runtime library then translates the parameters as
needed into a standard Network Data Representation (NDR) format
for transmission to the server

28
Remote Procedure Call - Process

29
Remote Procedure Call - Works

30
Remote Procedure Call - Process

31
 Remote Procedure Call - Steps

1. The client calls a local procedure, called the client stub. To the
client process, it appears that this is the actual procedure. The client
stub packages the arguments to the remote procedure and builds
one or more network messages. The packaging of arguments into a
network
32
message is called marshaling.
Remote Procedure Call - Steps
2. Network messages are sent by the client stub to the remote system.
3. Network messages are transferred by the kernel to the remote system
via some protocol.
4. A server stub procedure on the server receives the messages. It
unmarshals the arguments from the messages and possibly converts them
from a standard form into a machine-specific form.
5. The server stub executes a local procedure call to the actual server
function, passing it the arguments that it received from the client.
6. When the server is finished, it returns to the server stub with its return
values.
7. The server stub converts the return values (if necessary) and marshals
them into one or more network messages to send to the client stub.
8. Messages get sent back across the network to the client stub.
33
Remote Procedure Call - Steps
7. The server stub converts the return values (if necessary) and
marshals them into one or more network messages to send to the
client stub.
8. Messages get sent back across the network to the client stub.
9. The client stub reads the messages from the local kernel.
10. It then returns the results to the client function (possibly
converting them first).
The client code then continues its execution

34
Remote Procedure Call - Advantages
• No need to worry about getting a unique transport address (a
socket on a machine). The server can bind to any port and register
the port with its RPC name server. The client will contact this
name server and request the port number that corresponds to the
program it needs.
• The system is transport independent. This makes code more
portable to environments that may have different transport
providers in use. It also allows processes on a server to make
themselves available over every transport provider on a system. ƒ
•Applications on the client only need to know one transport address
—that of the rpcbind (or portmap) process.
•ƒ The function-call model can be used instead of the send/receive
(read/write) interface provided by sockets.
35