OS2-Sem 831, Rasool Jalili Communication Chapter 2.

OS2-Sem 831, Rasool Jalili

Communication

•Chapter 2

OS2-Sem 831, Rasool Jalili

IPC

• Inter-Process Communication is the heart of all DSs.

• Processes on different machines.

• Always based on low-level message passing.

• In this chapter:– RPC– RMI– MOM (Message Oriented MiddleWare)– Streams (due to the advent of Multimedia DSs)

OS2-Sem 831, Rasool Jalili

Layered Protocols (1)• Layers, interfaces, and protocols in the OSI model.

2-1

OS2-Sem 831, Rasool Jalili

Layered Protocols

• Protocol

– Connection Oriented

– Connectionless

• Protocol Stack

• Description of the layers, Unit of exchange.

OS2-Sem 831, Rasool Jalili

Layered Protocols (2)• A typical message as it appears on the network.

2-2

OS2-Sem 831, Rasool Jalili

Data Link Layer

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

2-3

OS2-Sem 831, Rasool Jalili

Transport Protocols

• Makes the underlying layers usable by the application layer.

• Provide a reliable or unreliable connection for the upper layer.

• UDP :: TCP

• RTP for real-time systems.

OS2-Sem 831, Rasool Jalili

Client-Server TCP

a) Normal operation of TCP.b) Transactional TCP.2-4

OS2-Sem 831, Rasool Jalili

Middleware Protocols• An adapted reference model for networked communication.

2-5

OS2-Sem 831, Rasool Jalili

RPC

• PC?

• R…………….PC?

• Simple idea

• Complexity in provision

OS2-Sem 831, Rasool Jalili

Conventional Procedure Calla) Parameter passing in a local procedure call: the

stack before the call to read Count = read (fd, buf, nbytes);

b) The stack while the called procedure is active

OS2-Sem 831, Rasool Jalili

Issues

• Calling Method?– Call by value– Call by reference– Call by Copy/Restore– Call by name

OS2-Sem 831, Rasool Jalili

Client and Server Stubs• Principle of RPC between a client and server program.

• The read stub is called on behalf of the real read procedure!

OS2-Sem 831, Rasool Jalili

Steps of a Remote Procedure Call1. Client procedure calls client stub in normal way2. Client stub builds message, calls local OS3. Client's OS sends message to remote OS4. Remote OS gives message to server stub5. Server stub unpacks parameters, calls server6. Server does work, returns result to the stub7. Server stub packs it in message, calls local OS8. Server's OS sends message to client's OS9. Client's OS gives message to client stub10. Stub unpacks result, returns to client

OS2-Sem 831, Rasool Jalili

Passing Value Parameters (1)• Steps involved in doing remote computation through RPC

• It works fine, while the scenario is simple and straightforward; but ….

2-8

OS2-Sem 831, Rasool Jalili

Passing Value Parameters (2)• Different character set standards (ASCII vs EBCDIC)• Little-Endian vs Big-Endian Architecture.

a) Original message on the Pentium (L. E.)b) The message after receipt on the SPARC (B. E.)c) The message after being inverted. The little numbers in

boxes indicate the address of each byte

OS2-Sem 831, Rasool Jalili

Parameter Specification and Stub Generation

• Both sides should agree on the content of passing data structures.

• Example in the next slide.

• The way a message including the parameters is interpreted is the main issue!!

• Client and server should agree on the representation of simple data structures.

• Agreement on the actual exchange of the messages (connection-oriented or connection-less)

OS2-Sem 831, Rasool Jalili

Parameter Specification and Stub Generation

a) A procedureb) The corresponding message.

c) Interface Definition Language compiling into client stub and server stub

OS2-Sem 831, Rasool Jalili

Extended RPC Models

• RPC becoming as de facto standard for comm. In DSs.

• Popularity due to simplicity.

• Two extensions– Doors– Async RPC.

OS2-Sem 831, Rasool Jalili

Doors

• Equivallent to RPC for processes located on the same machine.

• A door is a name for a procedure in the address space of a server process, called by colocated processes with the server.

• Idea was originally from the Spirit OS (1994)

• Same as LightWeight RPC.

• The server process must register a door before use (calling door-create)

OS2-Sem 831, Rasool Jalili

Doors• The principle of using doors as IPC mechanism.

OS2-Sem 831, Rasool Jalili

Asynchronous RPC (1)

a) The interconnection between client and server in a traditional RPCb) The interaction using asynchronous RPC

2-12

OS2-Sem 831, Rasool Jalili

Asynchronous RPC (2)

• A client and server interacting through two asynchronous RPCs

2-13

OS2-Sem 831, Rasool Jalili

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

2-14

OS2-Sem 831, Rasool Jalili

Binding a Client to a Server• Client-to-server binding in DCE.

2-15

OS2-Sem 831, Rasool Jalili

Performing an RPC

• The whole scenario!

• Semantics– At-most-once operation

• Idempotency

OS2-Sem 831, Rasool Jalili

Remote Object Invocation• OO technology in centralized systems.

• Promoting the idea if RPC to the OO technology.

• Proxy as the server deleagate == Client stub.

• Skeleton == server stub

• The object state is normally not distributed remote object instead of distributed object

OS2-Sem 831, Rasool Jalili

Distributed Objects• Common organization of a remote object with

client-side proxy.

2-16

OS2-Sem 831, Rasool Jalili

Binding a Client to an Object

a) (a) Example with implicit binding using only global referencesb) (b) Example with explicit binding using global and local references

Distr_object* obj_ref; //Declare a systemwide object referenceobj_ref = …; // Initialize the reference to a distributed objectobj_ref-> do_something(); // Implicitly bind and invoke a method

(a)

Distr_object objPref; //Declare a systemwide object referenceLocal_object* obj_ptr; //Declare a pointer to local objectsobj_ref = …; //Initialize the reference to a distributed objectobj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxyobj_ptr -> do_something(); //Invoke a method on the local proxy

(b)

OS2-Sem 831, Rasool Jalili

Object References

• Endpoint and registration

• Failure and object migration need to invalidate all bindings by clients.

• Location Server

• Static RMI and invocation :: Interfaces of an object is known to the client before compilation.

• Dynamic invocation.

OS2-Sem 831, Rasool Jalili

Parameter Passing• The situation when passing an object by reference or by value.

2-18

OS2-Sem 831, Rasool Jalili

The DCE Distributed-Object Modela) Distributed dynamic objects in DCE.

b) Distributed named objects

OS2-Sem 831, Rasool Jalili

Message-Oriented Communication

• Sometimes both RPC and RMI is not appropriate

• Synchronous nature of RPC and RMI!

Messaging.

OS2-Sem 831, Rasool Jalili

Persistence and Synchronicity in Communication (1)

• General organization of a communication system in which hosts are connected through a network

2-20

OS2-Sem 831, Rasool Jalili

Persistence and Synchronicity in Communication (2)• Persistent communication of letters back in the

days of the Pony Express.

OS2-Sem 831, Rasool Jalili

Persistence and Synchronicity in Communication (3)

a) Persistent asynchronous communication

b) Persistent synchronous communication

2-22.1

OS2-Sem 831, Rasool Jalili

Persistence and Synchronicity in Communication (4)

c) Transient asynchronous communicationd) Receipt-based transient synchronous communication

2-22.2

OS2-Sem 831, Rasool Jalili

Persistence and Synchronicity in Communication (5)

e) Delivery-based transient synchronous communication at message deliveryf) Response-based transient synchronous communication

OS2-Sem 831, Rasool Jalili

Berkeley Sockets (1)• Socket primitives for TCP/IP.

Primitive Meaning

Socket Create a new communication endpoint

Bind Attach a local address to a socket

ListenAnnounce willingness to accept connections

AcceptBlock caller until a connection request arrives

Connect Actively attempt to establish a connection

Send Send some data over the connection

Receive Receive some data over the connection

Close Release the connection

OS2-Sem 831, Rasool Jalili

Berkeley Sockets (2)

• Connection-oriented communication pattern using sockets.

OS2-Sem 831, Rasool Jalili

The Message-Passing Interface (MPI)

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

MPI_bsend Append outgoing message to a local send buffer

MPI_sendSend a message and wait until copied to local or remote buffer

MPI_ssend Send a message and wait until receipt starts

MPI_sendrecv Send a message and wait for reply

MPI_isend Pass reference to outgoing message, and continue

MPI_issendPass reference to outgoing message, and wait until receipt starts

MPI_recv Receive a message; block if there are none

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

OS2-Sem 831, Rasool Jalili

Message-Queuing Model (1)• Four combinations for loosely-coupled

communications using queues.

2-26

OS2-Sem 831, Rasool Jalili

Message-Queuing Model (2)• Basic interface to a queue in a message-queuing system.

Primitive Meaning

Put Append a message to a specified queue

GetBlock until the specified queue is nonempty, and remove the first message

PollCheck a specified queue for messages, and remove the first. Never block.

NotifyInstall a handler to be called when a message is put into the specified queue.

OS2-Sem 831, Rasool Jalili

General Architecture of a Message-Queuing System (1)

• Messages are put in local queues and got from local queues.

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

OS2-Sem 831, Rasool Jalili

General Architecture of a Message-Queuing System (2)

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

2-29

OS2-Sem 831, Rasool Jalili

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

• The broker acts as an application level gateway to convert the format of

incoming msgs to be understood by the destination applications, eg. records

• E-mail as a known msging system

OS2-Sem 831, Rasool Jalili

• General organization of IBM's MQSeries message-queuing system.

• Used to access and manipulate large scale databses: finanace

• Queues are managed by ques managers; Each queue manager is responsible for removing msgs from its send queue and forward to other queue managers.

• A queue manager (QM) is responsible to pick up incoming msgs from the underlying net and store in the appropriate input Q.

• QMs are connected(pairwise) through msg channels.

• A msg channel is a reliable uni-directional transport-level connection between a sending and a receiving QM.

• Each end os a msg channel is managed by a MCA (msg chnl Agnt)

OS2-Sem 831, Rasool Jalili

Example: IBM MQSeries-2•

2-31

OS2-Sem 831, Rasool Jalili

Channels• Some attributes associated with message channel agents.

Attribute Description

Transport type Determines the transport protocol to be used

FIFO deliveryIndicates that messages are to be delivered in the order they are sent

Message length

Maximum length of a single message

Setup retry count

Specifies maximum number of retries to start up the remote MCA

Delivery retries

Maximum times MCA will try to put received message into queue

OS2-Sem 831, Rasool Jalili

Message Transfer (1)• The general organization of an MQSeries queuing network using

routing tables and aliases.

OS2-Sem 831, Rasool Jalili

Message Transfer (2)

Primitives available in an IBM MQSeries MQI (MQ Interface)

Primitive Description

MQopen Open a (possibly remote) queue

MQclose Close a queue

MQput Put a message into an opened queue

MQget Get a message from a (local) queue

OS2-Sem 831, Rasool Jalili

Stream-Oriented Communication• Till now, focus was on exchanging one or more

independent and complete units of info.• However, consider an audio stream, CD quality

is also required the original sound has been sampled at 44100 Hz a sample in each 1/44100 Sec is required to re-produce the original sound.

• Time-dependent and continuoud media is required :: Temporal relationship between data items are crucial.

OS2-Sem 831, Rasool Jalili

Data Stream (1)• Setting up a stream between two processes across a network.

• Data stream is a sequence of data units.

OS2-Sem 831, Rasool Jalili

Transmission Modes

• Async Trans Mode: Sending regardless of time

• Synch Trans Mode: There is a max end-to-end delay for each unit: Sensor info!

• Isochronous Trans Mode: Data units should be transferred on time:: A max and min end-to-end delay (bounded jitter).

OS2-Sem 831, Rasool Jalili

Data Stream (2)• Setting up a stream directly between two devices.

2-35.2

OS2-Sem 831, Rasool Jalili

Data Stream (3)• An example of multicasting a stream to several receivers.

OS2-Sem 831, Rasool Jalili

QoS

• Time-Dependent requirement:: QoS

• Next slide as a sample QoS specification

• Formulation based on the token bucket algorithm

• Basic idea is that tokens are generated at a constant rate.

• Token is a fixed # of bytes, an application is allowed to pass to the network.

OS2-Sem 831, Rasool Jalili

Specifying QoS (1)

• A flow specification.

Characteristics of the Input Service Required

•maximum data unit size (bytes)•Token bucket rate (bytes/sec)•Token bucket size (bytes)•Maximum transmission rate (bytes/sec)

•Loss sensitivity (bytes)•Loss interval (sec)•Burst loss sensitivity (data units)•Minimum delay noticed (sec)•Maximum delay variation (sec)•Quality of guarantee

OS2-Sem 831, Rasool Jalili

QoS• Loss sensitivity (bytes)• Loss interval (sec)• Burst loss sensitivity (data units): how many consequtive

data items may be lost• Minimum delay noticed (sec): how long the network can

delay the delivery of a data item before the receiver notices.• Maximum delay variation (sec): Maximum tolerated jitter• Quality of guarantee

OS2-Sem 831, Rasool Jalili

Specifying QoS (2)

• The principle of a token bucket algorithm.

OS2-Sem 831, Rasool Jalili

Setting Up a Stream• The basic organization of RSVP (resource reSerVation Protocol)

for resource reservation in a distributed system.

OS2-Sem 831, Rasool Jalili

Synchronization Mechanisms (1)

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

OS2-Sem 831, Rasool Jalili

Synchronization Mechanisms (2)

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

2-41