Chapter 2 of the document discusses communication in distributed systems, focusing on protocols like RPC and RMI, and the importance of message passing over shared memory. It introduces key communication models and describes layered protocols, emphasizing standards such as ISO OSI and TCP/IP. The chapter also distinguishes between different types of communication (persistent, transient, synchronous, and asynchronous) and their implications in the context of distributed networks.

1. Distributed Systems
Chapter 2 - Communication

2. Objectives of the Chapter
 review of how processes communicate in a network (the
rules or the protocols) and their structures
 introduce the four widely used communication models for
distributed systems:
 Remote Procedure Call (RPC)
 Remote Method Invocation (RMI)
 Message-Oriented Middleware (MOM)
 Streams
2

3. Introduction
 Interprocess communication is at the heart of all distributed
systems
 communication in distributed systems is based on message
passing as offered by the underlying network as opposed to
using shared memory
 modern distributed systems consist of thousands of
processes scattered across an unreliable network such as
the Internet
 unless the primitive communication facilities of the network
are replaced by more advanced ones, development of large
scale Distributed Systems becomes extremely difficult.
3

4. 2.1 Layered Protocols
 two computers, possibly from different manufacturers, must
be able to talk to each other
 for such a communication, there has to be a standard
 The ISO OSI (Open Systems Interconnection) Reference
Model is one of such standards - 7 layers
 TCP/IP protocol suite is the other; has 4 or 5 layers
 OSI
 Open – to connect open systems or systems that are open
for communication with other open systems using standard
rules that govern the format, contents, and meaning of the
messages sent and received
 these rules are called protocols
 two types of protocols: connection-oriented and
connectionless
4

5. layers, interfaces, and protocols in the OSI model
5

6.  Physical: Physical characteristics of the media
Host (upper) Layers
Media (lower) Layers
 Data Link: Reliable data delivery across the link
 Network: Managing connections across the network
or routing
 Transport: End-to-end connection and reliability
(handles
lost packets); TCP (connection-oriented),
UDP (connectionless), etc.
 Session: Managing sessions between applications
(dialog control and synchronization); rarely
supported
 Presentation: Data presentation to applications; concerned
with the syntax and semantics of the
information transmitted
 Application: Network services to applications; contains
protocols that are commonly needed by
users; FTP, HTTP, SMTP, ...
6

7. a typical message as it appears on the network
7

8. discussion between a receiver and a sender in the data link layer
 a conversation occurs between a sender and a receiver at
each layer
 e.g., at the data link layer
8

9. normal operation of TCP
assuming no messages are lost,
 the client initiates a setup
connection using a three-way
handshake (1-3)
 the client sends its request (4)
 it then sends a message to
close the connection (5)
 the server acknowledges
receipt and informs the client
that the connection will be
closed down (6)
 then sends the answer (7)
followed by a request to close
the connection (8)
 the client responds with an ack
to finish conversation (9)
 Transport Protocols: Client-Server TCP
9

10. transactional TCP
 much of the overhead in TCP is for managing the connection
 the client sends a single
message consisting of a setup
request, service request, and
information to the server that
the connection will be closed
down immediately after
receiving the answer (1)
 the server sends acceptance of
connection request, the
answer, and a connection
release (2)
 the client acknowledges tear
down of the connection (3)
 combine connection setup with
request and closing connection
with answer
 such protocol is called TCP for
Transactions (T/TCP)
10

11. 2.2 Remote Procedure Call
 the first distributed systems were based on explicit message
exchange between processes through the use of explicit
send and receive procedures; but do not allow access
transparency
 in 1984, Birrel and Nelson introduced a different way of
handling communication: RPC
 it allows a program to call a procedure located on another
machine
 simple and elegant, but there are implementation problems
 the calling and called procedures run in different address
spaces
 parameters and results have to be exchanged; what if the
machines are not identical?
 what happens if both machines crash?
11

12. principle of RPC between a client and server program
 Client and Server Stubs
 RPC would like to make a remote procedure call look the
same as a local one; it should be transparent, i.e., the calling
procedure should not know that the called procedure is
executing on a different machine or vice versa
 when a program is compiled, it uses different versions of
library functions called client stubs
 a server stub is the server-side equivalent of a client stub 12

13. 13
RPC Model
 A Server defines the server’s interface using an interface
definition language (IDL)
 The IDL specifies the names, parameters, and types for all client-
callable server procedures.
 A stub compiler reads the IDL and produces two stub
procedures for client and server:
 The server program implements the server procedures and links them
with the server-side stubs.
 The client program implements the client program and links it with the
client-side stubs.
 The stubs are responsible for managing all details of the remote
communication between client and server.

14. 14

15.  Steps of a Remote Procedure Call
1. Client procedure calls client stub in the normal way
2. Client stub builds a message and calls the local OS
(packing parameters into a message is called parameter
marshaling)
3. Client's OS sends the message to the remote OS
4. Remote OS gives the message to the server stub
5. Server stub unpacks the parameters and calls the server
6. Server does the work and returns the result to the stub
7. Server stub packs it in a message and calls the local OS
8. Server's OS sends the message to the client's OS
9. Client's OS gives the message to the client stub
10. Stub unpacks the result and returns to client
 hence, for the client remote services are accessed by making
ordinary (local) procedure calls; not by calling send and
receive
server machine vs server process; client machine vs client process
15

16.  resulted from object-based technology that has proven its
value in developing no distributed applications
 it is an expansion of the RPC mechanisms
 it enhances distribution transparency as a consequence of
an object that hides its internal from the outside world by
means of a well-defined interface
 Distributed Objects
 an object encapsulates data, called the state, and the
operations on those data, called methods
 methods are made available through interfaces
 the state of an object can be manipulated only by invoking
methods
 this allows an interface to be placed on one machine while
the object itself resides on another machine; such an
organization is referred to as a distributed object
 the state of an object is not distributed, only the interfaces
are; such objects are also referred to as remote objects
2.3 Remote Object (Method) Invocation (RMI)
16

17.  the implementation of an object’s interface is called a proxy
(analogous to a client stub in RPC systems)
 it is loaded into the client’s address space when a client
binds to a distributed object
 tasks: a proxy marshals method invocation into messages
and unmarshals reply messages to return the result of the
method invocation to the client
 a server stub, called a skeleton, unmarshals messages and
marshals replies
17

18. common organization of a remote object with client-side proxy
18

19. 19
The General RMI Architecture
 The server must first bind
its name to the registry
 The client lookup the
server name in the registry
to establish remote
references.
 The Stub serializing the
parameters to skeleton,
the skeleton invoking the
remote method and
serializing the result back
to the stub.
RMI Server
skeleton
stub
RMI Client
Registry
bind
lookup
return call
Local Machine
Remote Machine

20. 20
The Stub and Skeleton
 A client invokes a remote method, the call is first
forwarded to stub.
 The stub is responsible for sending the remote call
over to the server-side skeleton
 The stub opening a socket to the remote server,
marshaling the object parameters and forwarding the
data stream to the skeleton.
 A skeleton contains a method that receives the remote
calls, unmarshals the parameters, and invokes the
actual remote object implementation.
Stub
RMI Client RMI Server
skeleton
return
call

21.  RPCs and RMIs are not adequate for all distributed system
applications
 the provision of access transparency may be good but
they have semantics that is not adequate for all
applications
 example problems
 they assume that the receiving side is running at the
time of communication
 a client is blocked until its request has been processed
2.4 Message Oriented Communication
21

22. 2.4.1 Persistence and Synchronicity in
Communication
general organization of a communication system in which hosts are connected
through a network
 assume the communication system is organized as a
computer network shown below
22

23.  communication can be
 persistent or transient
 asynchronous or synchronous
 persistent: a message that has been submitted for
transmission is stored by the communication system as long
as it takes to deliver it to the receiver
 e.g., email delivery, snail mail delivery
persistent communication of letters back in the days of the Pony Express
23

24.  transient: a message that has been submitted for transmission
is stored by the communication system only as long as the
sending and receiving applications are executing
Persistent Transient
Asynchronous  
Synchronous  message-oriented; three forms
 asynchronous: a sender continues immediately after it has
submitted its message for transmission
 synchronous: the sender is blocked until its message is
stored in a local buffer at the receiving host or delivered to the
receiver
 the different types of communication can be combined
 persistent asynchronous: e.g., email
 transient asynchronous: e.g., UDP, asynchronous RPC
 in general there are six possibilities
24

25. persistent asynchronous communication persistent synchronous communication
25

26. receipt-based transient synchronous
communication
transient asynchronous communication
 weakest form; the sender is
blocked until the message is
stored in a local buffer at the
receiving host
26

27. response-based transient synchronous
communication
delivery-based transient synchronous
communication at message delivery
 the sender is blocked until the
message is delivered to the
receiver for further processing;
e.g., asynchronous RPC
 strongest form; the sender is
blocked until it receives a reply
message from the receiver
27

28. 2.4.3 Message-Oriented Persistent Communication
 there are message-oriented middleware services, called
message-queuing systems or Message-Oriented Middleware
(MOM)
 they support persistent asynchronous communication
 they have intermediate-term storage capacity for messages,
without requiring the sender or the receiver to be active
during message transmission
Message-Queuing Model
 applications communicate by inserting messages in
specific queues
 it permits loosely-coupled communication
 the sender may or may not be running; similarly the
receiver may or may not be running, giving four possible
combinations
28

29.  until now, we focused on exchanging independent and
complete units of information
 time has no effect on correctness; a system can be slow or fast
 however, there are communications where time has a critical
role
 Multimedia
 media
 storage, transmission, interchange, presentation,
representation and perception of different data types:
 text, graphics, images, voice, audio, video, animation, ...
 movie: video + audio + …
 multimedia: handling of a variety of representation media
 end user pull
 information overload and starvation
 technology push
 emerging technology to integrate media
2.4 Stream Oriented Communication
29

30.  Types of Media
 two types
 discrete media: text, executable code, graphics, images;
temporal relationships between data items are not
fundamental to correctly interpret the data
 continuous media: video, audio, animation; temporal
relationships between data items are fundamental to
correctly interpret the data
 a data stream is a sequence of data units and can be applied
to discrete as well as continuous media
 stream-oriented communication provides facilities for the
exchange of time-dependent information (continuous media)
such as audio and video streams
30

31.  timing in transmission modes
 asynchronous transmission mode: data items are
transmitted one after the other, but no timing constraints;
e.g. text transfer
 synchronous transmission mode: a maximum end-to-end
delay defined for each data unit; it is possible that data can
be transmitted faster than the maximum delay, but not slower
 isochronous transmission mode: maximum and minimum
end-to-end delay are defined; also called bounded delay
jitter; applicable for distributed multimedia systems
 a continuous data stream can be simple or complex
 simple stream: consists of a single sequence of data; e.g.,
mono audio, video only
 complex stream: consists of several related simple streams
that must be synchronized; e.g., stereo audio, video
consisting of audio and video (may also contain subtitles,
translation to other languages, ...)
31

32.  Quality of Service (QoS)
 QoS requirements describe what is needed from the
underlying distributed system and network to ensure
acceptable delivery; e.g. viewing experience of a user
 for continuous data, the concerns are
 timeliness: data must be delivered in time
 volume: the required throughput must be met
 reliability: a given level of loss of data must not be
exceeded
 quality of perception; highly subjective
32

33. 33