n Department of Information Technology

n Distributed & Cloud Computing Systems

(ITec5252)

Ayalew Belay(PhD)

E-mail: [email protected]
[email protected]
.
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022)
 Introduction
 Inter process 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

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 1

 Objectives of the Chapter
 review of how processes communicate in a network (the rules or the
protocols) and their structures

 introduce most widely used communication models for

distributed systems:
 Network Protocols and Standards
 Remote Procedure Call (RPC) -which hides the details of
message passing and suitable for client-server models
 Remote Object (Method) Invocation (RMI)
 Message-Oriented Middleware (MOM) -instead of the client-
server model, think in terms of messages and have a high
level message queuing model similar to e-mail
 Stream-Oriented Communication -for multimedia to support
the continuous flow of messages with timing constraints
 Multicast Communication -information dissemination for
several recipients

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 3

4.1 Network Protocols and Standards
 why communication in distributed systems? because there
is no shared memory
 two communicating processes must agree on the syntax
and semantics of messages
 a protocol is a set of rules that governs data
communications
 a protocol defines what is communicated, how it is
communicated, and when it is communicated

 the key elements of a protocol are syntax, semantics, and

timing
 syntax: refers to the structure or format of the data
 semantics: refers to the meaning of each section of bits
 timing: refers to when data should be sent and how fast they
can be sent

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022)

 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 transport layer protocols: connection-
oriented and connectionless

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 5

 layers, interfaces, and protocols in the OSI model
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 6
 Media (lower) Layers
 Physical: Physical characteristics of the media
 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, ...
Host (upper) Layers
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 7
 a typical message as it appears on the network

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 8

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

discussion between a receiver and a sender in the data link layer

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 9
 Transport Protocols: Client-Server 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
normal operation of TCP
to finish conversation (9)
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 10
 much of the overhead in TCP is for managing the connection
 combine connection setup with
request and closing connection
with answer
 such protocol is called TCP for
Transactions (T/TCP)
 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) transactional
15th IEEE/ACM International Conference on Utility and Cloud Computing TCP
(UCC2022) 11
 Application Protocols
 file transfer (FTP - File Transfer Protocol)
 HTTP - Hypertext Transfer Protocol for accessing data on the
WWW

 Middleware Protocols
 a middleware is an application that contains general-purpose
protocols to provide services
 example of middleware services
 authentication and authorization services - Chapter 8
 distributed transactions (commit protocols; locking
mechanisms) - Chapters 5 and 7
 middleware communication protocols (calling a procedure
or invoking an object remotely, synchronizing streams for
real-time data, multicast services) - see later in this Chapter
 hence an adapted reference model for networked
communications is required
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 12
 an adapted reference model for networked communication

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 13

4.1.2 Types of Communication
 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., e-mail delivery, snail mail delivery
 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
 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

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 14

 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

Persistent Transient

Asynchronous

 

Synchronous message-oriented; three forms

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 15

 persistent asynchronous  persistent synchronous
communication communication

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 16

  transient asynchronous receipt-based transient
communication synchronous communication

 weakest form; the sender is

blocked until the message is
stored in a local buffer at the
receiving host

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 17

  delivery-based transient response-based transient
synchronous communication at synchronous communication
message delivery

 the sender is blocked until the  strongest form; the sender is

message is delivered to the blocked until it receives a reply
receiver for further processing message from the receiver

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 18

 4.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?

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 19

 Conventional Procedure Call, i.e., on a single machine
 e.g. count = read (fd, buf, bytes); a C like statement, where
fd is an integer indicating a file
buf is an array of characters into which data are read
bytes is the number of bytes to be read
Stack pointer

Stack pointer

parameter passing in a local procedure the stack while the called

call: the stack before the call to read procedure is active
 parameters can be call-by-value (fd and bytes) or call-by
reference (buf) or in some languages call-by-copy/restore
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 20
 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

principle of RPC between a client and server program

 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
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 21
 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
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 22
 Parameter Passing
1. Passing Value Parameters
 e.g., consider a remote procedure add(i, j), where i and j are
integer parameters

steps involved in doing remote computation through RPC

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 23
2. Passing Reference Parameters
 assume the parameter is a pointer to an array
 copy the array into the message and send it to the server
 the server stub can then call the server with a pointer to this
array
 the server then makes any changes to the array and sends it
back to the client stub which copies it to the client
 this is in effect call-by-copy/restore
 optimization of the method
 one of the copy operations can be eliminated if the stub
knows whether the parameter is input or output to the
server
 if it is an input to the server (e.g., in a call to write), it need
not be copied back
 if it is an output, it need not be sent over in the first place;
only send the size
 the above procedure can handle pointers to simple arrays
and structures, but difficult to generalize it to an arbitrary
data structure
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022)
24
 Asynchronous RPC
 if there is no need to block the client until it gets a reply
 two cases
1. if there is no result to be returned
 e.g., adding entries in a database, ...
 the server immediately sends an ack promising that it
will carryout the request
 the client can now proceed without blocking

a) the interconnection between client and server in a traditional RPC

b)15th
theIEEE/ACM
interaction using asynchronous
International RPC
Conference on Utility and Cloud Computing (UCC2022) 25
2. if the result can be collected later
 e.g., prefetching network addresses of a set of hosts, ...
 the server immediately sends an ack promising that it
will carryout the request
 the client can now proceed without blocking
 the server later sends the result

a client and server interacting through two asynchronous RPCs

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 26
  the above method combines two asynchronous RPCs
and is sometimes called deferred synchronous RPC
 variants of asynchronous RPC
 let the client continue without waiting even for an ack,
called one-way RPC
 problem: if reliability of communication is not guaranteed

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 27

 4.3 Remote Object (Method) Invocation (RMI)
 resulted from object-based technology that has proven its
value in developing non 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
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 28
 the state of an object is not distributed, only the interfaces are; such
objects are also referred to as remote objects
 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

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 29

 common organization of a remote object with client-side proxy

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 30

 Binding a Client to an Object
 a process must first bind to an object before invoking its
methods, which results in a proxy being placed in the
process’s address space
 binding can be implicit (directly invoke methods using
only a reference to an object) or explicit (by calling a
special function)
 an object reference could contain
 network address of the machine where the object
resides
 endpoint of the server
 an identification of which object
 the protocol used
 ...

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 31

 Parameter Passing
 there are two situations when invoking a method with
object reference as a parameter: the object can be local or
remote to the client
 local object: a copy of the object is passed; this means the
object is passed by value
 remote object: copy and pass the reference of the object
as a value parameter; this means the object is passed by
reference

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 32

 the situation when passing an object by reference or by value
 two examples:
 DCE Remote Objects
 Java RMI
 read pages 93-98
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 33
 4.4 Message Oriented Communication

 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

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 34

 Persistence and Synchronicity in Communication
 assume the communication system is organized as a
computer network shown below

general organization of a communication system in which hosts are

connected through a network
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 35
 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
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 36
 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
 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

Persistent Transient

Asynchronous  

Synchronous  message-oriented; three forms

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 37

 persistent asynchronous persistent synchronous
communication communication

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 38

 transient asynchronous receipt-based transient
communication synchronous communication

 weakest form; the sender is

blocked until the message is
stored in a local buffer at the
receiving host

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 39

 delivery-based transient response-based transient
synchronous communication synchronous communication
at message delivery

 the sender is blocked until the  strongest form; the sender is

message is delivered to the blocked until it receives a reply
receiver for further processing message from the receiver

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 40

 4.5 Stream Oriented Communication
 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

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 41

 The Challenge
 new applications
 multimedia will be pervasive in few years (as graphics)
 storage and transmission
 e.g., 2 hours uncompressed HDTV (1920×1080) movie:
1.12 TB (1920×1080x3x25x60x60x2)
 videos are extremely large, even after compressed
(actually encoded)
 continuous delivery
 e.g., 30 frames/s (NTSC), 25 frames/s (PAL) for video
 guaranteed Quality of Service
 admission control
 search
 can we look at 100… videos to find the proper one?
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 42
 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

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 43

 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 (only visual frames)
 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, ...)

15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022) 44

 Thank you!
?
15th IEEE/ACM International Conference on Utility and Cloud Computing (UCC2022)