Communication

Chapter 2 Communication 1

Communication

Chapter 2


Communication

Layered protocolso Usual networking approach (client/server)

Remote Procedure Call (RPC)o Hide message passing details (client/server)

Remote Method Invocation (RMI)o Improved RPC (client/server)


Communication

Message-Oriented Communicationso Message Passing Low level, efficiento Message-Oriented Middleware (MOM) Non

client/server Streams

o Continuous flow subject to timing constraints


Layered Protocols

OSI reference modelo Each layer provides service to layer aboveo Implementation of service can change


Layer Services

Transport layero Logical connection between hostso Reliable communication between hosts

Network layero Route packet thru network

Data link layero Get packet over each hop

Physical layero Put the bits on the “wire”


Layered Protocols

Layered messageo Add headers when msg sent (down protocol stack)o Peel the onion when msg received (up the protocol

stack)


Data Link Layer

Communication at data link layero Above, A tries to send msgs 0 and 1 to B


Network Layer On a LAN

o Have a shared mediao Put the packet out, recipient picks it

up On a WAN

o Have point-to-point communicationo Many possible routeso Finding best route is difficult


Transport Layer UDP for unreliable delivery

o Better performance possible with UDP TCP for reliable delivery

o May be easier to build app with TCP


Client-Server TCP

Transactional TCPNormal TCP


Middleware Protocols

Reference model for middleware based distributed communication


What is Middleware? Logically at application layer General purpose protocols Independent of an application We’ll distinguish between

o High level application ando Middleware


Middleware Example Often, must authenticate users

o Require users prove identity Spse you build authentication

system Any app can use your auth system Your authentication “application”

o Is at application layer in OSI o Is also at middleware layer in our

view


Middleware Remainder of this chapter 4 middleware communication

serviceso RPCo RMIo Message oriented communicationo Streaming


Remote Procedure Call

Distributed systems can be built on explicit message passingo For example, send and receive

What’s wrong with this approach?o It’s not transparent to users

Why should we care?o Recall that transparency is one of primary

goals in distributed systems


Remote Procedure Call

RPC is a simple ideao Make remote operation seem like a (local)

procedure callo “All the great things are simple” Winston

Churchill Much better transparency compared to

primitive message passing Can we make remote operation seem

local?


Conventional Procedure Call

a) Stack before call to readb) Stack while called procedure is active

Consider C function: count = read(fd, buf, bytes)


Parameter Passing

Consider againo C function: count = read(fd, buf, bytes)

In C, parameters can beo Passed by value: byteso Passed by reference: the array buf

Usually not important whether pass by value or pass by reference is used

But it’s a big deal in RPC!o Since procedure will execute at remote

location


RPC between Client/Server

We say that this is synchronouso Since client waits for result


Stubs On client side, stub marshalls

parameters and send to servero Pack parameters into message(s)

On server side, stub converts to local procedure call, sends back results

Stubs increase transparency


Passing Value Parameters

Suppose add(i,j) returns i + j Remote computation via RPC


Client Stub

a) Procedureb) Stub marshalls params


Steps in RPC1. 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


Additional RPC Topics Doors

o Caller and sender on same machine Asynchronous RPC

o Client does something while server works on procedure

DCE RPCo Specific implementation of RPC


Doors

If client and server on same machine o Use interprocess communication (IPC)o More efficient than network protocols


The Doors

Doors are not to be confused with “The Doors”


Asynchronous RPC

a) Usual (synchronous) RPCb) Asynchronous RPC


Asynchronous RPC

Client and server interact via two asynchronous RPCs

More efficient, if applicable


DCE RPC

Distributed Computing Environment (DCE)

Read this section A couple of interesting items… DCE semantic options

o At-most-once no call done more than once, even if system crash

o Idempotent calls can be repeated multiple times (e.g., read)


DCE RPC

Client-to-server binding in DCE Note directory service


RMI Remote Method Invocation

o Distributed objects Objects hide internals

o Provides transparencyo Also desirable in distributed systems

RMI can increase transparency compared to RPC

Chapter 10 has real systems


Objects Object encapsulates data, the

state Object encapsulated methods,

operations on the data Methods are made available thru

well-defined interfaces In distributed environment

o Interface can be on one machine ando Corresponding object on another

machine


Distributed Objects

Interface on cliento Proxy like client stub in RPC

Object on servero Skeleton like server stub in RPC


Compile-time vs Runtime Compile-time objects

o Objects analogous to those in Java, C++

o Pluses: easy to implemento Minuses: depends on specific language

Runtime objectso Implementation is open, use adapter

(wrapper) to hide implementationo Plus and minus opposite of those

above


RMI and Parameter Passing

Makes sense to treat local and remote objects differentlyo Lots of overhead to remote objectso Pass by reference gets complicated


Java RMI Distributed objects are an integral

part of Javao Aims for high degree of transparencyo For example client proxy has same

interface as remote object There are subtle differences

between local and remote objects…


Java RMI Cloning

o Cloning a local object results in exact copyo Only server can clone remote objecto In Java, proxies not clonedo So must bind (again) to cloned object

Can declare method to be synchronizedo Ensures access to data is serialized

Blockingo Clients blocked


Java RMI Read the details A preview of Chapter 5… Spse multiple clients want to access a

method on server (method is synchronized)o Block all but one client lots of overheado Block at the server what if client crashes?

Java restricts blocking to proxieso Simplifies thingso But then can’t prevent simultaneous access

of remote objects simply by synchronized


Message-Oriented Comm.

RPC and RMI enhance transparency

But RPC and RMI are “inherently synchronous”

Consider an email system whereo Messages stored on email servers

when in transit and before reado Stored locally after read

Example of persistent communication



In email exampleo Sender need not continue executing

after sending msgo Receiver need not be executing when

msg sent Comparable to the Pony Express! The more things change, the more

they stay the same…


Pony Express

Persistent comm and the Pony Express


Transient and Asynchronous

Transiento Msg is stored only as long as sender

and receiver are aliveo If msg can’t be delivered, discard it

Asynchronouso Sender does not wait for response

before continuing Recall persistent and synchronous Four possible combinations…


Examples Transient asynchronous

o UDP Transient synchronous

o Synchronous RPC Persistent asynchronous

o email Persistent synchronous

o Msg can only be stored at receiving host


Persistence and Synchronicity

a) Persistent asynchronous communicationb) Persistent synchronous communication



c) Transient asynchronous communicationd) Receipt-based transient synchronous

communication



e) Delivery-based transient synchronous communication at message delivery

f) Response-based transient synchronous communication


Message-Oriented Comm. Message-oriented systems take

transient asynchronous as baselineo Like UDP

But persistence sometimes neededo Especially if geographically

distributedo Network or process failures likely

Message passing like transport layer



Transiento Berkeley socketso Message Passing Interface (MPI)

Persistento Message queuing model, MOMo Message brokers


Berkeley Sockets

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

ConnectActively attempt to establish a connection

Send Send some data over the connection

Receive Receive some data over the connection

Close Release the connection


Berkeley Sockets

Connection-oriented communication pattern using sockets

Note “synchronization point”


Message-Passing Interface (MPI)

A few (of the many) MPI primitives Emphasis here is on efficiency Big parallel machines use 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


Message-Passing Interface (MPI)

Transient asynchronous: MPI_bsend Transient synchronous: MPI_ssend “Stronger” form of synchronous: MPI_sendrecv Many more possibilities (read the book…)

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


Message Queuing Persistent

o Message-Queuing Systems or MOM Insert msgs into queues

o Delivered via a series of serverso Can be delivered even if server downo No guarantee msg will be deliveredo No assurance msg will be read, etc.

For systems where communications takes minutes instead of milliseconds


Message-Queuing Model

Loosely-coupled communications using queues


Message-Queuing Model

Simple interface to message-queuing systemo Put is non-blockingo Get blocks only if queue is emptyo Poll is non-blocking form of Get

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.


Message-Queuing System

Addressing in message-queuing system


Message-Queuing System

Routing in message-queuing system


Message Brokers

Message broker in message-queuing system

Translates between msg formats


Example: IBM MQSeries

Read it


Streams Other methods based on more-or-

less independent units of datao Timing does not affect correctness

In multimedia, timing is criticalo Audio and videoo Can tolerate loss, but not “jitter”

Temporal relationship is important


Stream Transmission Modes

Asynchronous transmission modeo Data sent one after anothero No other timing constraints

Synchronous transmission modeo Max end-to-end delay for each unit

Isochronous transmission modeo Max and min end-to-end delay


Stream

Stream from process to process Stream can be viewed as a virtual connection

between source and sink


Stream

Stream sent directly between two devices


Stream

Multicasting a stream Different requirements for receivers?


Specifying QoS

A flow specification

Characteristics of the Input Service Required

Maximum data unit size (bytes)Token bucket rate (bytes/sec)Toke 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


Specifying QoS

A token bucket algorithm Don’t want bucket to be empty of

overflowing Then can feed out at precise time intervals


Setting Up a Stream

RSVP for resource reservation Purpose is to try to insure QoS Highly dependent on data link layer


Synchronization

Explicit synchronization for data units Read and write incoming stream units App is responsible for sync., only low-level utilities


Synchronization

Synchronization supported by high-level interfaces A middleware approach


Summary Communication is a fundamental

issue in distributed systems Networking overview RPC

o Goal is transparency RMI

o Transparency and objects RPC and RMI are synchronous


Summary Recall

o Synchronous block until msg delivered (or until response received)

o Asynchronous sender continues immediately after sending

o Persistent msg stored until delivered

o Transient msg delivered now or never


Summary Message-Oriented Communication

o Message passing For transient asynchronous (MPI) Good for big parallel machines

o Message-oriented middleware (MOM) Designed for persistent asynchronousStreams

Streamso Primarily for video and audioo Temporal relationship is critical

Documents

Communication