Introduction Inter Process Communication (IPC) is the heart of - PDF document

Lecturer: Hadi Salimi Lecturer: Hadi Salimi Distributed Systems Lab, School of Computer Engineering I Iran University of Science and Technology, U i i f S i d T h l 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 � …

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

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 � Communication is persistent C i ti i i t t � Communication is asynchronous

Remote Procedure Calls � In 1984, Barrel and Nelson, proposed the idea of Remote Procedure Calls (RPCs). � Allowing processes to call functions available on other machines. h � The RPC, has many challenges: Th RPC h h ll � 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.

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.

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 � The remote OS gives the message to the server stub. t OS i th t th t b � 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.

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.

Passing by Reference � What is the problem with passing pointers to a remote machine? � To emulate this call by reference, we should copy the whole array to a buffer and send it over the network. h l b ff d d h k � Is it a good idea? I i d id ? � What about a pointer to a big data structure, like a graph? � Wh t b t i t t bi d t t t lik h? Parameter Specification � The client and server should agree with the specification of messages. � This should be reached using h h ld b h d client and server stubs. � As you will see, client and server stub could be generated using a stub could be generated using a compiler.

Example: DCE RPC A Question � Why in a IDL, the input, output and input ‐ output parameters should be specified explicitly?

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.

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 stubs are valid for RMI too. t b lid f RMI t

Message Passing � RPC and RMI could provide transparency for communication challenge of distributed systems. � But unfortunately, the both sides should be executing at the same time. h � To solve this issue, the messaging technology could be T l hi i h i h l ld b helpful. Sockets � Primitives of a TCP/IP socket � Primitives of a TCP/IP socket.

Communication by Sockets � Communication using sockets Sockets � Pros: � Too simple � Are efficient � Cons: � Not too abstract � Lack most needs of today’s HPC environments � Are protocol specific A t l ifi

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

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 in a queue. The receiver will pick up the message as soon i Th i ill i k th as it become online. Message ‐ Queuing Model (1) � Loosely coupled communication by � Loosely coupled communication by means of message queues

Interface of MOMs � The basic primitives for a message queuing system Queue Level addressing � The scenario in which a process send a message to Th i i hi h d t another queue.

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: � Agree on a standard format d d f � Use a message broker

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.

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 of 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 continuous media this is valid. ti di thi i lid Stream Transmission � Asynchronous: � Data items are transmitted one after another and there are no further time constraints. f th ti t i t � File transmission � Synchronous: 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

Streams � Simple: � Consists only one sequence of data. � A non ‐ stereo audio stream � Complex: � Consists of several simple streams, called sub ‐ streams � Streams of video, sound, subtitle, etc. S f id d b i l General Architecture � General architecture of a data streaming system � General architecture of a data streaming system