[PDF] - Introduction Inter Process Communication (IPC) is the heart of PDF Document

SLIDE 1

Lecturer: Hadi Salimi Lecturer: Hadi Salimi Distributed Systems Lab, School of Computer Engineering I U i i f S i d T h l Iran University of Science and Technology, hsalimi@iust.ac.ir

Introduction

Inter‐Process Communication (IPC) is the heart of

distributed systems.

The underlying technology to support communication is

the network technology. the network technology.

Unlike simple passing of data packets on a network,

p p g p distributed systems need more advanced communication styles, such as:

Remote Procedure Calls (RPCs) Remote Procedure Calls (RPCs) Message Passing (MOMs) Streaming …

SLIDE 2

Layered Protocols

Due to the lack of shared memory, communication in

distributed systems is performed using message passing.

It means:

A process prepares its data in a buffer Then it executes a system call. And the same for the receiver.

Many agreements need to communicate:

From the way data is expresses From the way data is expresses. … To the voltage for representing 0 or 1.

g p g

ISO OSI

Layers, interfaces, and protocols in the OSI model

SLIDE 3

Layered Protocols

A typical message as it appears on the network A typical message as it appears on the network

Types of Communication

Consider a e‐mail system Take the whole system as a middleware C i ti i i t t

Communication is persistent Communication is asynchronous

SLIDE 4

Remote Procedure Calls

In 1984, Barrel and Nelson, proposed the idea of Remote

Procedure Calls (RPCs).

Allowing processes to call functions available on other

h machines. Th RPC h h ll

The RPC, has many challenges:

Processes run on different address spaces. Platforms may differ Platforms may differ. …

Example

Consider a case which is a call to a function:

Count = read(fd , buf , nbytes) f f y

The simply reads a file fd into a buffer. nbytes show that how many buffers has been read. See the status of stack after this call.

SLIDE 5

Stack State

The stack after calling the read procedure.

Any comments about the order of parameters?

y p

Parameter Passing

Some parameters the previous example are passed by

value and some by reference.

In addition, some languages use call by copy/restore. Do

you know what is it? you know what is it?

They are important for C programmers.

y p p g

They are important for RPC designers as well. In addition, different languages use different calling

styles styles.

SLIDE 6

Steps

The client procedure calls the client stub in the normal way. The client stub builds a message and calls the local operating

system.

The client’s OS sends the message to the remote OS. Th

t OS i th t th t b

The remote OS gives the message to the server stub. The server stub unpacks the parameters and calls the server. The server does the work and returns the result to the stub

The server does the work and returns the result to the stub.

The server stub packs it in a message and calls its local OS. The server’s OS sends the message to the client’s OS.

g

The client’s OS gives the message to the client stub. The stub unpacks the result and returns to the client.

Stubs

A RPC should seem like an ordinary call to users. Client and server stubs bring this transparency for users Client and server stubs bring this transparency for users. This example is a synchronous communication.

SLIDE 7

Parameter Passing

The client stub should pack the parameters and send

them to the sever.

Passing Parameters

A big challenge in parameter

passing is the different representation of words on different machines.

See what happens in passing See what happens in passing

two words from a Pentium architecture to SPARC.

SLIDE 8

Passing by Reference

What is the problem with passing pointers to a remote

machine?

To emulate this call by reference, we should copy the

h l b ff d d h k whole array to a buffer and send it over the network. I i d id ?

Is it a good idea? Wh t b

t i t t bi d t t t lik h?

What about a pointer to a big data structure, like a graph?

Parameter Specification

The client and server should

agree with the specification of messages. h h ld b h d

This should be reached using

client and server stubs.

As you will see, client and server

stub could be generated using a stub could be generated using a compiler.

SLIDE 9

Example: DCE RPC A Question

Why in a IDL, the input, output and input‐output

parameters should be specified explicitly?

SLIDE 10

Asynchronous RPC

There is no need to block the client, when no result is

going to be returned. Traditional RPC Asynchronous RPC

Deferred Synchronous RPC

In many cases, the server returns a result, but the client

cannot wait it.

This could happen using two asynchronous calls.

SLIDE 11

Client Server Binding in DCE

Client‐Server Binding in DCE

RMI

Like RPC, Remote Method Invocation (RMI) is a special

calling between distributed objects.

Some languages such as Java, support this feature. The same techniques described for RPC, such as IDLs and

t b lid f RMI t stubs are valid for RMI too.

SLIDE 12

Message Passing

RPC and RMI could provide transparency for

communication challenge of distributed systems.

But unfortunately, the both sides should be executing at

h the same time. T l hi i h i h l ld b

To solve this issue, the messaging technology could be

helpful.

Sockets

Primitives of a TCP/IP socket Primitives of a TCP/IP socket.

SLIDE 13

Communication by Sockets

Communication using sockets

Sockets

Pros:

Too simple Are efficient

Cons:

Not too abstract Lack most needs of today’s HPC environments

A t l ifi

Are protocol specific

SLIDE 14

MPI

The need for a hardware and platform independent

programming interface, led to standardization of Message Passing Interface or MPI Passing Interface or MPI.

In this standard, each process could be represented by a

In this standard, each process could be represented by a tuple, namely, (GroupId , ProcessId)

This standard includes more than 100 primitives for:

Scattering data Gathering dada Gathering dada Getting the group id …

MPI Primitives

Some basic primitives of MPI

SLIDE 15

Message Queuing

They provide support for persistent communication. The underlying middleware is usually called a Message

Oriented Middleware or MOM.

The simple idea is to put the message for another process

i Th i ill i k th in a queue. The receiver will pick up the message as soon as it become online.

Message‐Queuing Model (1)

Loosely coupled communication by Loosely coupled communication by

means of message queues

SLIDE 16

Interface of MOMs

The basic primitives for a message queuing system

Queue Level addressing

Th i i hi h d t

The scenario in which a process send a message to

another queue.

SLIDE 17

General Architecture

General architecture of a message queuing system with

g q g y routers

Message Brokers

An important application area of message‐queuing

systems is integrating new and legacy applications.

It needs they have the same message format. Two approaches could be applied: d d f

Agree on a standard format Use a message broker

SLIDE 18

Message Brokers

General organization of a message broker used in message

g g g queuing systems.

Some Notes

The idea of message queuing systems has long been used

in email systems.

But there are differences:

In email systems routing is generally left out In addition, they are aimed at providing direct support for

end users end users. There are special features in message queue systems that

There are special features in message queue systems that there is no need for them in email systems, such as message priorities or guaranteed message delivery.

SLIDE 19

Data Streams

There are forms of communication in which timing plays a

crucial role.

As an example, suppose that an audio stream should be

transferred through a communication channel.

Playing out in a different rate, will produce and incorrect version

f the original sound.

g

The same is true for a video clip in which at least 20‐25 frames

should be displayed in a second should be displayed in a second. For discrete media, i.e. images and text this is not true, but for

ti di thi i lid continuous media this is valid.

Stream Transmission

Asynchronous:

Data items are transmitted one after another and there are

f th ti t i t no further time constraints.

File transmission

Synchronous:

There is always a maximum end‐to‐end delay. Sensor Data or DSMSs

Isochronous:

Data transfer is subject to a ma imum and minimum dela Data transfer is subject to a maximum and minimum delay,

also referred t as bounded delay (jitter).

Audio and video streams

SLIDE 20

Streams

Simple:

Consists only one sequence of data. A non‐stereo audio stream

Complex:

Consists of several simple streams, called sub‐streams

S f id d b i l

Streams of video, sound, subtitle, etc.

General Architecture

General architecture of a data streaming system General architecture of a data streaming system

SLIDE 21

QoS Parameters

Properties for Quality of Service:

The required bit rate at which data should be transported. The maximum delay until a session has been set up The maximum end‐to‐end delay The maximum end‐to‐end delay. The maximum delay variance, or jitter. The maximum round‐trip delay.

Enforcing QoS

No one can guarantee a specific QoS on internet. So, the underlying systems offer only a best‐effort delivery

y g y y y service.

Marking outgoing packets by priorities Packet dropping policies for network congestion control. Using buffers for continuous data delivery.

SLIDE 22

Data buffering

U i b ff d ji

Using buffer to reduce jitter.

Enforcing QoS

h ff f k l i ( ) i l d i i

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

and (b) interleaved transmission