Inter-Process Communication is at the heart of all distributed systems, so we need to know the ways that processes can exchange information. Communication in distributed systems is based on Low-level message passing as offered by the underlying network.

1. Inter-Process
Communication
(IPC)
1

2. Agenda
• Introduction
• Layered Protocols (7 Layers)
• Types of Communication (3 Categories)
• Models for Communication (3 Models)
• The Group Communication and the
Multicasting Communication
2

3. Introduction
• IPC is at the heart of all distributed systems, so
we need to know the ways that processes can
exchange information.
• Communication in distributed systems is
based on Low-level message passing as
offered by the underlying network.
3

4. Layered Protocols
Two processes A,B
A wants to communicate with B.
A builds a message in its own address space.
A execute a call to the OS to send the message.
To prevent chaos (mass)
A,B have to agree on the meaning of the bites
being sent.
4

5. • The International Standards Organization (ISO)
developed a reference model that clearly
identifies the various levels involved
Open Systems Interconnection (OSI).
• It provides a description of how network
hardware and software work together in a
layered fashion to make communications
possible.
5

6. • Communication divided into 7 layers.
• Each layer has a responsibility to perform
specific tasks but all of the layers are needed
for a message to reach its destination.
• Message send (downwards) Message received
(upwards).
6

7. Two general type of protocols
• Connection oriented protocols:
Before exchanging data the sender and receiver first
establish a connection, and possibly negotiate the
protocol they will use When they are done, they
must terminate the connection.
The Telephone
• Connectionless protocols:
No setup in advance is needed, The sender just
transmits the first message when it is ready.
The mailbox or mail
7

8. Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Application Layer
Layered Protocols
8

9. Application Layer
• It is the software that the end-user interacts
with.
• It serves as a window through which
application processes can access network
services.
9

10. Presentation Layer
• Think of it as the network's translator.
• It is responsible for translating the data,
encrypting the data, changing or converting
the character set.
• Manages data compression to reduce the
number of bits that need to be transmitted.
10

11. Session Layer
• Provides dialog control between
communicating processes, such as which party
is currently talking, when, and for how long.
• Allows users to insert checkpoints into long
transfers.
• In the event of crash, it is necessary to go
back only to the last checkpoint.
11

12. Transport Layer
• Turns the underlying network into something
that an application developer can use.
• Ensures that packets are delivered error free,
in sequence, and without losses or
duplications.
12

13. Network Layer
• Addresses the packets and translating logical
addresses and names into physical addresses.
• Determines the route from the source to the
destination computer (Delay-Wise).
13

14. Data Link Layer
• Groups bits into frames and sees that each
frame is correctly received (checksum), If
checksums differ, requests a retransmission.
• Sends data frames from the network layer to
the physical layer
14

15. 15

16. Physical Layer
• The physical layer is totally hardware-
oriented.
• It is responsible for transmitting bits (zeros
and ones) from one computer to another.
• Defines the duration of each impulse.
16

17. Middleware Protocols
• Communications Middleware is the layer that
lies between the operating system and system
applications that allows for communications.
• Sometimes Communications Middleware is
referred to as “plumbing” because it is the
piece that connects two (or more) applications
and allows data to pass through.
17

18. • Communications Middleware can be cross-
platform, that is, it facilitates communications
between these differing devices.
• We can use a cell phone and a PC here as an
example. They both function in vastly different
capacities, but with Communications
Middleware, are able to “talk” to and “work
with” each other
18

19. 19

20. Remote Procedure Call

21. • Many distributed systems have been based on
explicit message exchange between processes
and this exchange must be transparent.
• Problems
 the calling and called procedures run on different
machines, they execute in different address
spaces.
 Parameters and results also have to be passed.
 Either or both machines can crash and each of the
possible failures causes different problems.

22. count =read (fd, buf, nbytes);
fd is an integer
indicating a file.
buf is an array of
characters into which data
are read.
nbytes is an integer
telling how many bytes to
read.

23. • By Value
• By Reference
• By Copy and Restore
count =read (fd, buf, nbytes);

24. Performing read operation in RPC :
1. The client procedure calls the client stub in the normal way.
2. The client stub builds a message and calls the local
operating system
3. The client's as sends the message to the remote as.
4. The remote as gives the message to the server stub.
5. The server stub unpacks the parameters and calls the
server.
6. The server does the work and returns the result to the stub.
7. The server stub packs it in a message and calls its local as.
8. The server's as sends the message to the client's as.
9. The client's as gives the message to the client stub.
10. The stub unpacks the result and returns to the client.

25. • By Value
• By Reference
• Problems
add(i, j);

26. • The message format must be defined, the caller
and the callee must agree on the format of the
messages they exchange, and that they follow
the same steps when it comes to.
• The interface language must be the same in
client and server.

28. • developed by the Open Software Foundation
(OSF).
• DCE RPC is not as popular as some other RPC
systems.
• Initially designed for UNIX, it has now been
ported to all major operating systems including
VMS and Windows variants.
• Idea
Distributed Computing Environment

29. Procedures that form part of DCE
The distributed file service is a worldwide file system that
provides a transparent way of accessing any file in the system in
the same way.
The directory service is used to keep track of the location of all
resources in the system. These resources include machines,
printers, servers, data, and much more, and they may be
distributed geographically over the entire world. The directory
service allows a process to ask for a resource and not have to be
concerned about where it is, unless the process cares.
The security service allows resources of all kinds to be
protected, so access can be restricted to authorized persons.
The distributed time service is a service that attempts to keep
clocks on the different machines globally synchronized.

31. • Cannot pass pointers
 call by reference becomes copy-restore (but
might fail)
• Weakly typed languages
 client stub cannot determine size
• Not always possible to determine parameter
types
• Cannot use global variables
RPCs, i.e., enhance access transparency but they are
not always appropriate to distributed system. 31

32. Message-Oriented Communication is a way of
communicating between processes. Messages,
which correspond to events, are the basic units of
data delivered. Message-oriented communication
is classified according to two factors:
• synchronous or asynchronous communication,
and transient or persistent communication.
32

33. Many distributed systems built on top of simple
message-oriented model
– Example: Berkeley sockets
– Socket?
33

34. 34

35. • Sockets designed for network communication (e.g.,
TCP/IP)
 Support simple send/receive primitives
 Use general-purpose protocol stacks such as TCP/IP
• Abstraction not suitable for other protocols in clusters
of workstations or massively parallel systems
 Need an interface with more advanced primitives
• Large number of incompatible proprietary libraries
and protocols.
 Need for standard interface
35

36. • Message-passing interface (MPI)
 Hardware independent
 Designed for parallel applications (uses
transient communication)
• Key idea: communication between groups of
processes
 Each endpoint is a (groupID, processID) pair
• An MPI implementation allows a user to start
multiple threads and provide functions for the
threads to communicate and synchronize.
36

37. • The need for persistent communication services
is clear in developing middleware for large-scale
distributed applications.
• If you use direct point-to-point interfaces to
integrate your systems means that every system
would have to know exactly how to connect to
all other systems and enterprise.
37

38. You can see that as you add more systems it gets more
complex!
N(N-1)/2 different connections!
38

39. 39

40. • Message queuing systems or Message-Oriented
Middleware (MOM).
 Support asynchronous persistent
communication
 Intermediate storage for message while
sender/receiver are inactive
 Example application: email
• Communicate by inserting messages in queues
• Sender is only guaranteed that message will be
eventually inserted in recipient’s queue
 When/if the message will be read?
40

41. • Queues are managed by queue managers
They move a message from a source queue to a
destination queue.
Special queue managers operate as routers or
relays: they forward incoming messages to other
queue managers.
41

42. Four combinations for loosely-coupled
communications using queues:
42

43. General Architecture of MOM:
43

44. The general organization of a message-
queuing system with routers:
44

45. Relays/Routers:
• special queue managers that operate as routers
and forward incoming messages to other queue
managers (Overlay network)
45

46. Why Routers??
• Only the routers need to be updated when queues
are added or removed
• Allow for secondary processing of messages (e.g.,
logging for fault tolerance)
• Used for multicasting purposes
• Act as message brokers
46

47. The Role of Message Brokers:
• Often, there’s a need to integrate new/existing apps
into a “single, coherent Distributed Information System
(DIS)”.
• Problem: different message formats exist in legacy
systems (cooperation and adherence to open standards
was not how things were done in the past).
It may not be convenient to “force” legacy systems to adhere
to a single, global message format (cost!?).
It is often necessary to live with diversity (there’s no choice).
• Solution: the “Message Broker”.
47

48. Message Broker
• In message-queuing systems, conversions are handled
by special nodes in a queuing network, known as
message brokers.
• A message broker acts as an application-level gateway
in a message-queuing system.
• Purpose - convert incoming messages so that they can
be understood by the destination application.
Note: a message broker is just another application - not
considered to be an integral part of the queuing system.
• Message brokers can be simple (reformat messages) or
complex (find associated applications, convert data).
48

49. The general organization of a message
broker in a message-queuing system:
49

50. Message-Queuing (MQ)
Applications:
• General-purpose MQ systems support a wide range
of applications, including:
Electronic mail.
Workflow.
Groupware.
Batch Processing.
• Most important MQ application area:
Integration of a widely dispersed collection of database
applications (which is all but impossible to do with
traditional RPC/RMI techniques).
50

51. Example IBM WebSphere
Message-Queuing system:
51

52. 52

53. References
• http://www.ibiblio.org/gdunc/netone/NETESS3_html/netess3/ch05b.htm
• http://education-portal.com/academy/lesson/osi-model-using-open-
systems-interconnection-to-send-and-receive-data.html
• http://www.informit.com/articles/article.aspx?p=349749&seqNum=2
• http://www.twinoakscomputing.com/coredx/middleware_tour
• http://www.slideshare.net/Rishikese/middleware-and-middleware-in-
distributed-application?related=1
• http://www.w3.org/TR/wsdl.html
• https://msdn.microsoft.com/en-us/library/ms189921.aspx
• http://en.wikipedia.org/wiki/Remote_procedure_call
• http://jan.newmarch.name/go/arch/chapter-arch.html
• http://en.wikipedia.org/wiki/Communications_protocol
• http://www.cs.uoi.gr/~pitoura/courses/ds04_gr/communication-part1.pdf
53