1

Higher Level Communication Models

 Remote Procedure Call (RPC)
 Message-Oriented Middleware (MOM)
 Data Streaming
 Multicasting

2
Remote Procedure Call (RPC)
 The first and most complete description of the RPC
concept was presented by Birrell and Nelson in 1984

 The most common framework for newer protocols and for

middleware

 Used both by operating systems and by applications

 NFS (Network File System) is implemented as a set of RPCs
 DCOM, CORBA, Java RMI, etc., are just RPC systems

3
Remote Procedure Call (RPC)
 A high-level network communication interface

 Based on the single-machine procedure call model.

 Client Request is formulated as a procedure call to a
function on the server.
 Server’s Reply is formulated as function return

4
Conventional Procedure Calls
 Initiated when a process calls a function or
procedure
 The caller is “suspended” until the called function
completes.
 Parameters & return address are pushed onto the
process stack.
 Variables local to the called function are pushed
onto the stack

5
Conventional Procedure Calls
 Control passes to the called function
 The called function executes, returns value(s)
either through parameters or in registers.
 The control is transferred back to caller via return
address
 The stack is popped.
 Calling function resumes executing

6
Remote Procedure Calls
 Basic operation of RPC parallels single-machine
procedure calling
 Caller process executes the remote call and is
suspended until called function completes and results
are returned.
 Parameters are passed to the machine where the
procedure will execute.
 When procedure completes, results are passed back to
the caller and the client resumes execution at that time.

7
Principle of RPC between a client and server program

8
RPC & Client-Server
 RPC forms the basis of most client-server systems.

 Clients formulate requests to servers as procedure

calls

 Access transparency is provided by the RPC

mechanism as opposed to send and receive
calls by programmer

9
RPC
 Stubs
 A client-side stub is a function that looks to the client as if it were a callable
function of the service
 same API as the service’s implementation of the function
 A service-side stub looks like a client calling the service
 The client program thinks it’s invoking the service
 but it’s calling the client-side stub
 The service program thinks it’s called by the client
 but it’s really called by the service-side stub
 The stubs send messages to each other to make the RPC happen
transparently

10
Client Stub Actions
 When an application makes an RPC, the client
stub does the following:
 Builds a message containing parameters and calls
local OS to send the message
 Packing parameters into a message is called
parameter marshalling.
 Stub procedure calls receive( ) to wait for a reply
(blocking receive primitive)

11
Transparency Using Stubs
 For procedure calls, control flows from
 Client application to client-side stub
 Client stub to server stub
 Server stub to server procedure
 For procedure return, control flows from
 Server procedure to server-stub
 Server-stub to client-stub
 Client-stub to client application

12
RPC – Issues
 What are semantics of parameter passing? Call-by-copy/restore

 Transport protocol (TCP/IP or UDP?)

 Format of complex data structures Byte Ordering

13
Communication
 Layered Protocols

 Remote Procedure Call (RPC)

 Message-Oriented Middleware (MOM)

 Data Streaming

 Multicasting

14
Communication
 Layered Protocols

 Remote Procedure Call (RPC)

 Message-Oriented Middleware (MOM)

 Data Streaming

 Multicasting

15
Stream-Oriented Communication
 Problem Statement

 In many situations, it does not matter when a

particular communication process takes place.

 But what if we are attempting to serve audio or video,

or a combination of both?

 Time dependent data such as audio/video can be

served using streams.

16
Continuous vs. Discrete Media
 Continuous Representation Media
 The temporal relationship between data items is
important to the meaning of the data.
 Examples include video and audio data

 Discrete Representation Media

 Not time dependent
 still images, text, executable

 Data Streams handle Continuous Media

 Data stream is a sequence of data units 17
Stream
 Common Characteristics
 Streams can be set up between two processes at different
machines, or directly between two different devices.
Combinations are possible as well.

 Streams are unidirectional.

 There is generally a single source, and one or more sinks. If

there are multiple sinks, the data stream is multicast to
several receivers.

18
Stream
 Transmission Modes
 Different timing guarantees with respect to data transfer:
 Asynchronous
 There are no timing constraints on when the data is to be delivered.
 E.g. discrete data streams (file transfer)

 Synchronous
 A maximum end-to-end delay for individual data packets is defined.
 E.g. communicating sensor-captured data

 Isochronous
 It is subject to a maximum and minimum end-to-end delay (bounded
jitter)
 E.g. distributed multimedia systems

19
Specifying QoS

The principle of a token bucket algorithm

20
Specifying QoS
Before

After

21
Enforcing QoS –
Distributed Systems Solutions

Using buffers to reduce jitter

22
Enforcing QoS –
Distributed Systems Solutions
 IP best-effort service means that packets may be lost
 Forward Error Correction techniques (FEC)
 Encode outgoing packets in such a way that only k out of n
received packets are enough to reconstruct k correct packets
 Since single packet may contain multiple audio and video frames, a
receiver may perceive a large gap when a packet is lost

23
Enforcing QoS –
Distributed Systems Solutions
 Solution

Interleaved Transmission
Note: Requires larger receiving buffer. Thus imposes larger start delay
24
Distribution of Synchronization
Mechanisms
 Example:
 MPEG (Motion Picture Experts Group) standard for compressing
video and audio
 Continuous and discrete streams can be merged into a single stream
 First, each stream is turned into a stream of packets that carry a
timestamp based on a 90 kHz system clock
 These streams are subsequently multiplexed into a program stream
 The receiving side de-multiplexes the stream using the timestamps
of each packet as the basic mechanism for inter-stream
synchronization

25
Communication
 Layered Protocols

 Remote Procedure Call (RPC)

 Message-Oriented Middleware (MOM)

 Data Streaming

 Multicasting

26
Application-Level Multicasting
 Nodes are organized into an overlay network
 Network routers are not involved into the group
membership.
 Therefore, routing may not be optimal.

 Two approaches for construction of overlay

networks
 Tree: a unique overlay path between every pair of nodes
 Mesh network: multiple paths exists between every pair
of nodes

27
Application-Level Multicasting (Example)
 Constructing a multicast tree in Chord
The node that wants to start a multicast
session generates a multicast identifier
mid (a random 60-bit key) and then
looks up succ(mid) node which becomes
a root of the multicast tree

When a node P wants to join the tree, it

executes LOOKUP(mid) which will
route the request to join the multicast
group mid from P to succ(mid)

28
Application-Level Multicasting (Example)

29
Application-Level Multicasting

 The quality of the application-level multicast tree is

measured in terms of following metrics:
✔ Link Stress
 defined for each link; counts how many times a packet crosses
the same physical link
✔ Stretch (Relative Delay Penalty – RDP)
 Ratio in delay between ALM-level path and network-level path

✔ Link Cost
 global metric related to minimizing the aggregated link costs

30
Epidemic Protocols
 Epidemic protocols, as infectious diseases, rapidly
propagate information
 The goal is to infect all nodes with new information as fast as
possible
 Assumption
 New data can be distinguished from the old data, for example by
being time-stamped or versioned
 Nodes are also said to spread updates
 If a node holds data that is willing to spread to other nodes, it is
infected
 A node that has not yet seen this data is called susceptible
 An updated node which is not willing or able to spread the data is
said to be removed

31
Epidemic Protocols
 Anti-Entropy Model

 Node P picks Q at random and subsequently exchanges

updates with Q using one of the following
 P only pushes its own updates to Q
 P only pulls in new updates from Q
 P and Q send updates to each other (i.e., a push-pull approach)

32
Epidemic Protocols
 Push-based approach does not work well when many nodes
are infected
 the probability of each infected one selecting a susceptible node is
relatively small
 Pull-based approach works much better when many nodes
are infected
 Spreading is triggered by the susceptible nodes and chances are
large that such a node will contact an infected node to pull in the
new data
 Push-Pull remains the best strategy
 to propagate a single update to all nodes takes O(log(N)) rounds
where N is the number of nodes in the system – fast and scalable
propagation

33
Gossip-based Data Dissemination
 If server P has just been updated for data item x, it contacts
an arbitrary other server Q and tries to push the update to
Q
 If Q has already been updated by another server, P may
lose interest in spreading the update any further, say with
probability 1/k (i.e., P becomes removed)
 Gossiping is really effective in rapidly spreading the
updates

34
Communication
 Layered Protocols

 Remote Procedure Call (RPC)

 Message-Oriented Middleware (MOM)

 Data Streaming

 Multicasting

35