Communication Inter-process Communication is the heart of a Distributed System

Yüklə 0,82 Mb.
ölçüsü0,82 Mb.


  • Inter-process Communication is the heart of a Distributed System

  • Basic mechanisms are:

  • RPC

  • RMI

  • MOM

  • Streams

How to Communicate?

  • Problem: a process in machine A wants to communicate (an item) to a process in machine B

  • How is this done?

  • Build a message and send it through the network (cable) to the “other” side.

  • MANY things have to be agreed upon!

  • Voltage (0/1)? For bit representation..

  • Correctness of messages

  • Representation of numbers, strings, and data items(in different machines)

  • Etc.

Approach: OSI Layered Protocols

  • OSI Open System Interconnection Reference:

  • Layers, interfaces, and protocols in the OSI model.

Layered Protocols: as you dip into the layers you “add” more info

  • A typical message as it appears on the network.

OSI Model

  • Design for “Open System”: allows the communication of one system with another – possibly different one.

  • Open Systems are not exactly “Open” ; They are governed by a set of rules/regulations…

  • Protocols: formalization of these rules

  • Connection-oriented protocols

  • Connectionless protocols.

Physical Level

  • Mostly concerned with the transmission of 0/1s..

  • Voltage level

  • Rate of transmission

  • Network connectors (plugs)

  • Example:

  • RS232c (standard for serial communication).

Data Link Layer: frames & checksums

  • Discussion between a receiver and a sender in the data link layer.

Network Layer

  • Does the “routing” of packets..

  • Problem: shortest path is not always available!!

  • Even if it is available “routing” may opt for a different path? Why?

  • IP Internet Protocol (main representative of Network Layer)

  • An IP packet (frame) can be sent without any setup.

  • Virtual Path is gaining popularity (in ATM networks)

Transport Layer

  • Data will have to delivered to the other side

  • with no loss..

  • The job of the TL is exactly this!

  • Examples..

  • TCP (Transmission Control protocol)

  • UDP (Universal Datagram Protocol): almost similar to IP.

  • RTP (Real-Time Protocol)

Example: Client-Server TCP

  • Normal operation of TCP.

  • Transactional TCP (TCP for Transactions Suite)

High(-er) Level Protocols..

  • Session and Presentation Layer

    • Provides dialog facilities, keeps track of who is talking at this time, and provides synchronization if needed.
    • All these are useful into long transfers as precautions can be taken for the transmission of data.
  • Examples:

    • FTP (file transfer protocol)
    • HTTP (HyperText Transfer Protocol)

Example of Higher Level Protocols: Middleware Protocols

  • An adapted reference model for networked communication that may enforce the notion of “atomicity”

Communication of Processes-RPCs

  • [Birell & Nelson TOCS94]

  • When a process A in machine a calls a routine on machine B, the calling process A suspends and the execution of the called program in B takes place transparently..

  • Information is transported from caller to callee in the parameters and the result returns

  • No message passing is visible to the user.

  • Remote Procedure Call (RPC).

  • Idea: make a remote procedure call appear as a local one!

Conventional Procedure Call

Client and Server Stubs

  • The client stub works in a similar way to a usual system call (for instance read()).

  • The difference is that a different version (the client stub) is loaded into the frame stack.

  • This stub does not ask the OS to get any data on behalf of the process.

  • The stub packs the parameters into a single message and requests the message to be sent to the server.

  • When the msg arrives into the server, the OS of the server surrenders the msg to the server stub (server side equivalent).

Client and Server Stubs

  • Principle of RPC between a client and server program.

Steps of a Remote Procedure Call

  • Client procedure calls client stub in normal way

  • Client stub builds message, calls local OS

  • Client's OS sends message to remote OS

  • Remote OS gives message to server stub

  • Server stub unpacks parameters, calls server

  • Server does work, returns result to the stub

  • Server stub packs it in message, calls local OS

  • Server's OS sends message to client's OS

  • Client's OS gives message to client stub

  • Stub unpacks result, returns to client

Possible Issues

  • Passing parameters is always a problem..

  • Pass by value

  • Pass by reference

  • Call by copy/restore

  • Marshaling of parameters has to initially take place.

Passing Value Parameters

  • Steps involved in doing remote computation through RPC

Possible Problems with Passing Value Parameters

  • Original message on the Pentium (little Endian-number their bytes from right to left)

  • The message after receipt on the SPARC (big Endian-numbers the bytes from left to right)

  • The message after being inverted is not a general solution.

  • The little numbers in boxes indicate the address of each byte (need some type of deli-meter in order to understand the various representations involved)

  • integers and strings have to be handled differently!

Passing Reference Parameters

  • How are pointers being passed??

    • Generally difficult problem…
    • One solution is forbid passing of pointers all together (rather restrictive)
    • Some things can be done with arrays:
      • Copy the array into the message and send it over..
      • Call-by-reference is replaced by copy/restore..
      • If the stubs know whether the buffer is an Input parameter to the server or an output parameter to the client optimizations can be done.

Parameter Specification and Stub Generation

  • En example..

  • A procedure

  • The corresponding message.

Extensions of RPCs:Doors[Hamilton & Kougiouris 94]

Asynchronous RPC

  • The interconnection between client and server in a traditional RPC

  • The interaction using asynchronous RPC

Asynchronous RPC

  • A client and server interacting through two asynchronous RPCs

  • One-way RPCs

Distributed Computing Environment(DCE)

  • Idea: take a group of machines (running Unix, OS2, Windows etc) add a layer of software and then be able to run distributed applications without disturbing the running of existing applications!

  • Some basic services offered such as:

  • Distributed File Service (the worldwide file system)

  • Directory Service

  • Security Service

  • Distributed Time Service (why?)

Writing a Client and a Server

  • The steps in writing a client and a server in DCE RPC.

Binding a Client to a Server

  • A client can call a server as long as the server is registered and ready to accept calls!

  • Registration makes possible that the client can locate the server and bind to it.

  • Server location is down into two steps:

  • Locate the server’s machine

  • Locate the server (ie, the correct process on that machine!).

Binding of Clients and Servers

  • In order to achieve the step (2) the port for the service needs to be known.. (or endpoint)

  • Ports are used by servers as different entry points to different procedure calls.

  • In DCE there is a daemon (DCE Daemon) that makes this look up between (server, endpoint)

  • The server also registers with a directory machine(name of machine and IP number)

Binding a Client to a Server

  • Client-to-server binding in DCE.

Remote Object Invocation

  • Object-Oriented Technology (CORBA, DCOM) is another way to develop distributed applications.

  • RPCs could be applied to those frameworks as well.

  • Object::

    • Encapsulates data
    • Methods (operations on data)
    • Methods are available via interfaces
    • The differentiation between object & interfaces is critical as far as Distributed Systems concerns.
    • Interface can be on one machine – Object on another.

Distributed Objects

  • Common organization of a remote object with client-side proxy.

  • Proxy = client stub ; Skeleton = Server Stub

  • The state of such distributed objects is NOT distributed!

  • A real-distributed object should be one that is physically distributed across multiple machines.

Implicit/Explicit Binding of a Client to an Object

  • An example with implicit binding using only global references

  • An example with explicit binding using global and local references (the client first calls a a special function that binds the object before the client can invoke the object’s methods)

Types of Remote Method Invocation (RMI)

  • Static Invocation

    • Interfaces of an object are know when client application is being developed.
  • Dynamic Invocation

    • Be able to compose a methods invocation at run time!
    • invoke(object, method, in_params, out_params)
    • Example: append an integer int to a file object fobject for which the object provides the method append
      • Static: fobejct.append(int)
      • Dynamic: invoke(fobject, id(append), int) where id returns an identifier for the method append.
      • Dynamic Invocation: when is it useful?

Parameter Passing in RMI

  • Passing an object by reference or by value.

Message Oriented Communication

Example: Mail-Server

  • Every host is connected to one mail-server (can think of it as being the “comm” server of the picture in the previous slide).

  • A client interface allows users to get access to the messages (located on the mail servers).

  • When a user submits an message, the host forwards the message its corresponding mail server.

  • Mail servers forward/delete messages.

  • Such a system is an example of persistent communication

Mail-servers follow the Pony Express Model

  • Persistence has to do with the fact that the mail is stored as long as it takes to deliver it..

  • Transient Communication: if a message cannot be delivered

  • to the next server/destination is discarded (typical of the transport

  • layer – corresponds to store-and-forward router).

Possible Combinations(sync/async-persi/transi)

  • Persistent asynchronous communication

  • Persistent synchronous communication(msg actually delivered to the receiving site)


  • Transient asynchronous communication (examples are UDP, asynchronous RPCs)

  • Receipt-based transient synchronous communication


  • Delivery-based transient synchronous communication at message delivery

  • Response-based transient synchronous communication (RPCs & RMIs mostly adhere to this type of communication).

Berkeley Sockets

  • Socket primitives for TCP/IP.

How Berkeley SocketsWork

  • Connection-oriented communication pattern using sockets.

The MPI Interface

  • Some of the most intuitive message-passing primitives of MPI.

Message-Queuing Systems

  • Four combinations for loosely-coupled communications using queues.

Message-Queuing Model: calls

  • Basic interface to a queue in a message-queuing system.

General Architecture of a Message-Queuing System

  • The relationship between queue-level addressing and network-level addressing.

General Architecture of a Message-Queuing System

  • The general organization of a message-queuing system with routers.

Message Brokers

  • The general organization of a message broker in a message-queuing system.

Stream-Oriented Communication

  • Thus far, communication as long as it happens correctly is all we mind. Timing of this communication was not the issue.

  • Timing is important in certain types of communication …

    • CD quality audio transmission ( 16bit samples at 44,1kHz)
    • Video streams

Streams - Definitions

  • Information Representation

    • Text with ASCII/Unicode
    • Images with GIF/JPEG
    • Audio Streams with 16bit samples using PCM
  • Continuous (Representation) Media: temporal relationship among the different data items are fundamental to interpret what the data means.

    • Motion requires 30-40 msec per image (if represented as a sequence of images).
  • Discrete(Representation) Media: temporal relations among data items are not of essence

    • Representations of text, still-images, code, files, etc.

Data Streams

  • Data stream: a sequence of data units

  • Timing is essential into continuous data streams.

  • Asynchronous Transmission Mode

    • Data are xmited one after the other with no “timing” strings attached.
  • Synchronous Transmission Mode

    • There is a maximum end-to-end delay defined for every unit in the data stream.
  • Isochronous Transmission Mode

    • Data have to be transferred on time
    • There are minimum and maximum end-to-end delay (jitter)

Data Streams

  • Setting up a stream between two processes across a network.

Data Streams with Direct Connection between Source and Sink

  • Setting up a stream directly between two devices.

What if the sink is a multiparty?

  • Receivers may have different requirements

  • Filters have to be attached…

Specifying QoS

  • A flow specification.

Partridge’s Model expressed with a Token Bucket Algorithm

  • The principle of a token bucket algorithm.

Setting Up a Stream- RSVP Protocol

  • The basic organization of RSVP for resource reservation in a distributed system.

Synchronization Mechanisms

  • The principle of explicit synchronization on the level data units.

Synchronization Mechanisms

  • The principle of synchronization as supported by high-level interfaces.

Yüklə 0,82 Mb.

Dostları ilə paylaş:

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2020
rəhbərliyinə müraciət

    Ana səhifə