Chapter 4 - Communication

Ayalew Belay (PhD)

Ayalew.belay@aau.edu.et

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003

 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 which is harder 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 2

 Objectives of the Chapter
 Review how processes communicate in a network (the rules or
the protocols) and their structures
 Introduce the five widely used communication models for
distributed systems:
 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
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 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
 For instance, for one computer to send a message to another
computer, the first computer must perform the following general
steps (highly simplified)
 Break the data into small sections called packets (message,
segment, datagram/packet, frame)
 Add addressing information to the packets identifying the source
and destination computers
 Deliver the data to the network interface card for transmission
over the network 4
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003
  The receiving computer must perform the same steps, but in
reverse order
 Accept the data from the NIC
 Remove transmitting information that was added by the
transmitting computer
 Reassemble the packets of data into the original message
 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
 Functions of protocols
 Each device must perform the same steps the same way so
that the data will arrive and reassemble properly; if one
device uses a protocol with different steps, the two devices
will not beOFable
DEPARTMENT to communicate
COMPUTER with
SCIENCE CoSc each other
6003 5
 Protocols in a layered architecture
 Protocols that work together to provide a layer or layers of the
model are known as a protocol stack or protocol suite, e.g.
TCP/IP
 Each layer handles a different part of the communications
process and has its own protocol
 Data Communication Standards
 Standards are essential for interoperability
 Data communication standards fall into two categories
 De facto standards: that have not been approved by an
organized body; mostly set by manufacturers
 De jure standards: those legislated by an officially recognized
body such as ISO, ITU, ANSI, IEEE

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 6

Network (Reference) Models
 Layers and Services
 Within a single machine, each layer uses the services
immediately below it and provides services for the layer
immediately above it
 Between machines, layer x on one machine communicates with
layer x on another machine
 Two important network models or architectures
 The ISO OSI (Open Systems Interconnection) Reference Model
 The TCP/IP Reference Model
a. The OSI Reference Model
 consists of 7 layers
 was never fully implemented as a protocol stack, but a good
theoretical model
 Open – to connect open systems or systems that are open for
communication with other
DEPARTMENT OF COMPUTER systems
SCIENCE CoSc 6003 7
 Layers, interfaces, and protocols in the OSI model

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 8

 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
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 9
 A typical message as it appears on the network

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 10

b. The TCP/IP Reference Model
 TCP/IP - Transmission Control Protocol/Internet Protocol
 Used by ARPANET and its successor the Internet
 Design goals
 The ability to connect multiple networks (internetworking) in a
seamless way
 The network should be able to survive loss of subnet
hardware, i.e., the connection must remain intact as long as
the source and destination machines are properly functioning
 Flexible architecture to accommodate requirements of
different applications - ranging from transferring files to real-
time speech transmission
 These requirements led to the choice of a packet-switching
network based on a connectionless internetwork layer
 Has 4 (or 5 depending on how you see it) layers: Application,
Transport, Internet (Internetwork), Host-to-network (some split it
into Physical and Data Link)
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 11
 OSI and TCP/IP Layers Correspondence

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 12

 Layers involved in various hosts (TCP/IP)
 When a message is sent from device A to device B, it may pass
through many intermediate nodes
 The intermediate nodes usually involve the first three layers

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 13

 Middleware Protocols
 A middleware is an application that contains general-purpose
protocols to provide services
 Example of middleware services
 Authentication and authorization services
 Distributed transactions (commit protocols; locking
mechanisms) - see later in Chapter 8
 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 14

 An adapted reference model for networked communication

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 15

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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 16

 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 17

persistent asynchronous  persistent synchronous
communication communication

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 18

 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 19

  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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 20

 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?

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 21

 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

22
reference (buf)OForCOMPUTER
DEPARTMENT in someSCIENCE
languages call-by-copy/restore
CoSc 6003
 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 DEPARTMENT
server stub is the server-side equivalent of a client stub
OF COMPUTER SCIENCE CoSc 6003 23
 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 machineOF
DEPARTMENT vsCOMPUTER
server process;
SCIENCE client
CoScmachine
6003 vs client process 24
 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 25
 The above discussion applies if the server and the client machines
are identical
 But that is not the case in large distributed systems
 The machines may differ in data representation (e.g., IBM
mainframes use EBCDIC whereas IBM PCs use ASCII)
 There are also differences in representing integers (1’s complement
or 2’s complement) and floating-point numbers
 Byte numbering may be different (from right to left in Pentium called
little endian and left to right in SPARC, big endian)
 e.g.
 Consider a procedure with two parameters, an integer and a
four-character string; each one 32-bit word (5, “JILL”)
 The sender is Intel and the receiver is SPARC

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 26

 Original message on the Pentium
(the numbers in boxes indicate the address of each byte)

The message after receipt on the SPARC; wrong integer (224+226 =

83,886,080), but correct string

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 27

 One approach is to invert the bytes of each word after receipt

The message after being inverted (correct integer but wrong string)

 Additional information is required to tell which is an integer and

which is a string

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 28

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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 29

 Parameter Specification and Stub Generation
 The caller and the callee need to use the same protocol (format of

messages) and the same steps; with such rules the client and
server stubs can assemble, communicate, and interpret messages
correctly
 Consider the following example; the procedure foobar has 3

parameters: a character, a floating point number, and an array of 5

integers

 Assume a word is 4 bytes

 One possibility is to transmit the character in
the rightmost byte, a float as a whole word, and
an array as a group of words equal to the array
length preceded by a word giving the length
 This way both client stub and server stub can
understand outgoing and incoming messages
The corresponding message
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 30
 Other issues that need the agreement of the client and the server
 How are simple data structures like integers (e.g. 2’s
complement), characters (e.g. 16-bit Unicode), Booleans, ...
represented?
 Endianess
 Which transport protocol to use - the connection-oriented TCP or
the unreliable connectionless UDP

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 31

Asynchronous RPC
 A shortcoming of the original model is that it is blocking: but no

need of blocking for the client in some cases

 Two cases

1. If there is no result to be returned

 e.g., inserting records 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) The interaction
DEPARTMENT OF using asynchronous
COMPUTER RPC6003
SCIENCE CoSc 32
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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 33
  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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 34

 DCE (Distributed Computing Environment) RPC
 A middleware and an example RPC system developed by OSF
(Open Software Foundation), now The Open Group; it is
designed to execute as a layer of abstraction between existing
OSs and distributed applications
 Available as open source and vendors integrate it into their
systems (http://www.opengroup.org/dce/)
 It uses the client-server programming model and communication
is by means of RPCs
 Services
 Distributed file service: a worldwide file system that provides a
transparent way of accessing files
 Directory service: to keep track of the location of all resources
in the system (machines, printers, data, servers, ...); a process
can ask for a resource without knowing its location
 Security service: for protecting resources; access is only
through authorization
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 35
  Distributed time service: to maintain clocks on different
machines synchronized (clock synchronization is covered in
Chapter 6)

 Binding a Client to a Server in DCE RPC

 Binding means locating the correct server and setting up
communication between client and server software
 For a client to call a server, the server must be registered with the
daemon (1 & 2 in the following figure)
 The registration allows the client to locate the server & bind to it
 The DCE daemon maintains a table (server, endpoint) and the
protocols the server uses
 The directory server maintains the locations of all resources in
the system (machines, servers, data,, ...)

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 36

  Two steps for locating the server
 Locate the server’s machine (3)

 Locate the server process on that machine (with an endpoint

or port) (4)
 Now the RPC can take place; the above look up information can
be stored for subsequent RPCs

Client-to-server binding in DCE

 Others RPC systems: Sun RPC and DCOM (Microsoft's system
for distributed computing - Distributed Component Object
37
Model)
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003
 4.3 Remote Object (Method) Invocation (RMI)
(Chapter 10: Distributed Object-Based Systems; from page 443)
 Resulted from object-based technology that has proven its value
in developing nondistributed 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 an interface
 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
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 38
 If the state of an object is not distributed, but only the interfaces
are, then such an object is referred to as a remote object
 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 39

Common organization of a remote object with client-side proxy

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 40

 Object Servers
 An object server is a server to support distributed objects
 It does not provide a specific service; services are implemented
by the objects that reside on the server
 The server provides only the means to invoke local objects based
on remote client requests

 Alternatives for Invoking Objects

 To invoke an object, the object server needs to know
 Which code to execute
 On which data it should operate
 Whether it should start a separate thread
 ...

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 41

 Different approaches exist
1.Assume that all objects look alike and there is only one way to
invoke an object like in DCE; inflexible
2.Let a server support different policies
 Transient versus persistent objects

 Transient object: create it at first request and destroy it if no

clients are bound to it or
 Persistent object: it exists even if it is not currently used
 Separate or shared memory

 Put each object in a memory segment of its own, i.e., objects

share neither code nor data; protection of segments required,
probably by the underlying OS or
 Objects can at least share code
 Threading

 Implement the server with a single thread of control; or

 The server may have several threads, one for each of its
objects 42
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003
 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)

Distr_object* obj_ref; // Declare a systemwide object reference

obj_ref = …; // Initialize the reference to a distributed object
obj_refdo_something(); // Implicitly bind and invoke a method
(a)
Distr_object obj_ref; // Declare a systemwide object reference
Local_object* obj_ptr; // Declare a pointer to local objects
obj_ref = …; // Initialize the reference to a distributed object
obj_ptr = bind(obj_ref); // Explicitly bind and obtain a pointer to the local proxy
obj_ptrdo_something(); // Invoke a method on the local proxy
(b)

(a) An example with implicit binding using only global references

(b) An example with explicit binding using global and local references
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 43
  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
 ...
 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 44

 The situation when passing an object by reference or by value

 Example object-based systems:

 DCE Remote Objects  Globe
 Java RMI  ICE
 Java Beans  CORBA
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 45
 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
 Messaging is the solution

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 46

 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 47

 Message-Oriented Transient Communication
 Many applications are built on top of the simple message-
oriented model offered by the transport layer
 Standardizing the interface of the transport layer by providing
a set of primitives allows programmers to use messaging
protocols
 They also allow porting applications

1. Berkley Sockets
 An example is the socket interface as used in Berkley
UNIX
 A socket is a communication endpoint to which an
application can write data that are to be sent over the
network, and from which incoming data can be read

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 48

Primitive Meaning Executed by
Socket Create a new communication endpoint both
Attach a local address to a socket;
Bind e.g., IP address with a known port
number

Listen Announce willingness to accept servers

connections; non-blocking

Accept Block caller until a connection request

arrives
Actively attempt to establish a
Connect connection; the client is blocked until clients
connection is set up
Send Send some data over the connection

Receive Receive some data over the both

connection
Close Release the connection
SocketSCIENCE
DEPARTMENT OF COMPUTER primitives for6003
CoSc TCP/IP 49
 Connection-oriented communication pattern using sockets

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 50

2. The Message-Passing Interface (MPI)
 Sockets were designed to communicate across networks using
general-purpose protocol stacks such as TCP/IP
 They were not designed for proprietary protocols developed for
high-speed interconnection networks; of course portability will
suffer
 MPI is designed for parallel applications and tailored for
transient communication
 MPI assumes communication takes place within a known group
of processes, where each group is assigned an identifier
(groupID)
 Each process within a group is also assigned an identifier
(processID)
 A (groupID, processID) identifies the source or destination of a
message, and is used instead of a transport-level address

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 51

Primitive Meaning

MPI_bsend Append outgoing message to a local send buffer (for

transient asynchronous communication)

MPI_send Send a message and wait until copied to local or remote

buffer; semantics are implementation dependent

MPI_ssend Send a message and wait until receipt starts (for

transient synchronous communication)

MPI_sendrecv Send a message and wait for reply; strongest form;

similar to RPC (synchronous)

MPI_isend Pass reference to outgoing message (not copying the

message), and continue (asynchronous)

MPI_issend Pass reference to outgoing message (not copying the

message), and wait until receipt starts (synchronous)

MPI_recv Receive a message; block if there are none

(synchronous)

MPI_irecv Check if there is an incoming message, but do not block

(asynchronous)
Some of the most intuitive message-passing primitives of MPI

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 52

 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
 Unlike Berkley sockets and MPI, message transfer may take
minutes instead of seconds or milliseconds
 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 53

Four combinations for loosely-coupled communications using queues

(a) both are executing during the transmission of a message

(b) the sender is executing, but the receiver is not
(c) the receiver can read the message while the sender is not
executing
(d) the system is storing and possibly transmitting even if both
are not executing
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 54
Poll Check a specified queue for messages, and remove the
first; never block; nonblocking variant of Get
Primitive Meaning
Notify Install a handler (by the receiver) to be called when a
message is put into the specified queue; usually a daemon

Basic interface to a queue in a message-queuing system

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 55

 Message Brokers
 How can applications understand the messages they receive
 Each receiver can not be made to understand message formats of
new applications
 Hence, in a message-queuing system conversations are handled
by message brokers
 A message broker converts incoming messages to a format that
can be understood by the destination application based on a set of
rules

TheDEPARTMENT
general organization of a message broker in a message-queuing system
OF COMPUTER SCIENCE CoSc 6003 56
 As an example, read about IBM’s WebSphere Message-
Queuing System; pages 152-157

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 57

 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

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 58

 The Challenge
 New applications
 Multimedia will be pervasive in few years (as graphics)
 Continuous delivery
 e.g., 30 frames/s (NTSC), 25 frames/s (PAL) for video
 Guaranteed Quality of Service
 Admission control
 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)
 Search
 Can we look at 100… videos to find the proper one?
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 59
 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; e.g., TCP provides byte-
oriented discrete data streams
 Stream-oriented communication provides facilities for the
exchange of time-dependent information (continuous media)
such as audio and video streams

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 60

 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,
called substreams, that must be synchronized; e.g., stereo audio,
video consisting of audio and video (may also contain subtitles,
translation to other languages, ...)
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 61
 Movie as a set of simple streams

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 62

 A stream can be considered as a virtual connection between a
source and a sink
 The source or the sink could be a process or a device
 Streaming means a user can listen (or watch) after the downloading
has started
 We can stream stored data or live data (compression, actually
encoding is required)

A general architecture for streaming stored multimedia data over a network

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 63
 Setting up a stream directly between two devices - live data

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 64

 The data stream can also be multicasted to several receivers
 If devices and the underlying networks have different capabilities,
the stream may be filtered, generally called adaptation (filtering?,
transcoding?)

An example of multicasting a stream to several receivers

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 65

 Quality of Service (QoS)
 Timing and other nonfunctional requirements are expressed as
Quality of Service requirements
 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
 Initial delay: maximum delay until a session has been setup
 Maximum end-to-end delay
 Maximum delay variance or jitter
 Volume/bandwidth: the required throughput (bit rate) must be met (for
our previous example, 1920×1080x3x25 = 155,520,000 = 155,520
MBps or 1,244,160 Mbps - uncompressed)
 Reliability: a given level of loss of data must not be exceeded
 Quality of perception: highly subjective

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 66

 Enforcing QoS
 The underlying system offers a best-effort delivery service
 However, the Internet also provides mechanisms such as
differentiated services which categorizes packets into many
classes; for example, it has an expedited class to inform the
router to forward a packet with absolute priority
 In addition, a distributed system can help to improve QoS
 Three methods: buffering, forward error correction, and
interleaving frames
1. Buffering - Client Side
 Buffer (store) flows on the receiving side (client machine) before
delivery (playback)
 It smoothes jitter (for audio and video on demand since jitter is
the main problem) - does not affect reliability or bandwidth,
increases delay

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 67

 How long to buffer?
2. Forward Error Correction - Client Side
 Packets may be lost
 Retransmission is not applicable for time-dependent data
 The overhead for forward error correction may be high

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 68

3. Interleaving Frames - Server Side
 A single packet may contain multiple audio and video frames
 If such a packet is lost, there will be a large gap during play back
 Hence, the idea is to distribute the effect of a packet loss over
time
 But, a larger buffer is required at the receiver/client
 For example, to play the first four frames, four packets need to be
delivered and stored

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 69

 The effect of packet loss in (a) non interleaved transmission and
(b) interleaved transmission

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 70

 Stream Synchronization
 How to maintain temporal relations between streams

 Examples: lip synchronization or a slide show enhanced with

audio
 Two approaches

1. Explicitly by operating on the data units of simple streams; the

responsibility of the application (not good for applications to do
it)

The principle
DEPARTMENT of explicitSCIENCE
OF COMPUTER synchronization
CoSc 6003on the level of data units 71
2. Through a multimedia middleware that offers a collection of
interfaces for controlling audio and video streams as well as
devices such as monitors, cameras, microphones, ...

The principle of synchronization as supported by high-level interfaces

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 72

 4.6 Multicast Communication
 Multicasting: delivery of data from one host to many destinations;
for instance for multimedia applications
 A one-to-many relationship
1. Application-Level Multicasting
 Nodes are organized into an overlay network (a network which
is built on top of another network) and information is
disseminated to its members (routers are not involved as in
network-level routing)
 How to construct the overlay network
 Nodes organize themselves as a tree with a unique path
between two pairs of nodes or
 Nodes organize into a mesh network and there will be
multiple paths between two nodes; adv: robust
2. Gossip-Based Data Transmission
 Use epidemic protocols where information is propagated among
a collection of nodes without a coordinator
DEPARTMENT OF COMPUTER SCIENCE CoSc 6003 73
 Thank You

DEPARTMENT OF COMPUTER SCIENCE CoSc 6003