Communication

Distributed Systems
LEEC (2005/06 2 Sem.)
Communication in Distributed Systems
Joo Paulo Carvalho
Universidade Tcnica de Lisboa / Instituto Superior Tcnico
Outline
Introduction
Communication Issues
Layered Models (the OSI Model and the Internet Suite
Protocol)
Middleware Protocols
Remote Procedure Calls
Client and Server Stubs

Marshalling and Parameter Passing
Extended RPC models
DCE RPC / SUN RPC
Remote Object Invocation

DCE Distributed-Object Model
Java RMI
Message Oriented Communication

Stream Oriented Communication
J.P. Carvalho
Sistemas Distribudos 2005/2006
Introduction
Absence of shared memory implies that communication

in Distributed Systems must be based on low level
message passing
If process A wants to communicate with process B:
1. A builds a message on its own address space;
2. A executes a system call that causes the OS to send
the message over the network to the machine where
process B is running;
3. Machine B OS receives the message and puts it to B
address space.
Unfortunately message passing can bring lots of
problems
J.P. Carvalho
Introduction (2)
Message Passing
Problems:
What if A uses ASCII character coding and B uses EBCDIC
character coding?
What if machine A represents a 0 using -5V, and machine B
represents a 0 using 0V?
What if machine A uses little endian notation to represent
numbers and B uses big endian?
What if the message is lost?
And so on
Agreements are needed at a variety of levels, ranging from the
low-level details of bit transmission to the high-level details of
how information is to be expressed
Solution: Layered Protocols (e.g. the OSI Model)
J.P. Carvalho
Communication Issues
Addressing (How is the server located?)
Hard-wired address
Machine address and process
address are known a priori
Broadcast-based
Server chooses address from a
sparse address space
Client broadcasts request
Can cache response for future
Locate address via name server
J.P. Carvalho
user
server
user
server
NS
user
server
Communication Issues (2)

Connection vs. Connectionless
Connection oriented:
Before exchanging data, the sender and the receiver
explicitly establish a connection (possibly negotiating
the protocol they will use);
The connection is released when all communication is
done;
E.g.: Telephone; ATM.
Connectionless:
No setup is needed in advance. The sender just
transmits the first message when its ready;
E.g.: e-mail, IP.
J.P. Carvalho

Sinchronicity: Blocking vs. Non-blocking
Blocking communication (synchronous)
Send blocks the sender process until message is
actually sent
Receive blocks the receiver process until
message is actually received
Non-blocking communication (asynchronous)
Send returns immediately and sender process
continues
Receive does not block the receiver
J.P. Carvalho

Buffering
Unbuffered communication
Server must call Receive
before client can call Send
Buffered communication
Client Sends to a mailbox
Server Receives from a
mailbox
J.P. Carvalho
user
server
user
server

Reliability
J.P. Carvalho
reply
ACK
request
reply
Server
ACK
Server
User
request
User
Unreliable channel
Need acknowledgements
(ACKs)
Applications handle ACKs
ACKs for both request and
reply
Reliable channel
Reply acts as ACK for request
Reliable communication on
unreliable channels
Transport protocol handles lost
messages

To Push or Pull ?
Client-pull architecture
Clients pull data from servers by sending requests (e.g.,
HTTP)
Pro: stateless servers, failures are each to handle
Con: limited scalability
Server-push architecture
Servers push data to client (e.g., video streaming, stock
tickers)
Pro: more scalable
Con: stateful servers, less resilient to failure
J.P. Carvalho
10
OSI Model
ISO Open Systems Interconnection Reference Model:
Designed to allow open systems to communicate;

Protocols: Rules govern the format, contents and meaning of
messages sent and received.
Seven layers:
J.P. Carvalho
11
OSI Model (2)
When process A wants to communicate with process B, it builds a

message and passes it to the Application Layer
The Application Layer software adds a header to the front of the
message and passes it to the next lower layer
The process repeats until the lowest level, the Physical Layer, which
actually transmits the message over the network
J.P. Carvalho
12
OSI Model (3)
When the message arrives to the machine where process B is running,

it is passed upward, with each layer stripping of and examining its
own header
Information in the layer n header is used for the layer n protocol
Although the OSI reference model is widely used, the protocols it
defines are not
Protocols developed for the internet like TCP and IP are used instead
J.P. Carvalho
13
OSI Model Lower Level Protocols

Physical Layer
Concerned with transmitting the 0s and 1s:

How many volts to represent 0 and 1?
How many bits to send per second?
Size and shape of the connector plugs;
Protocols deal with standardizing the electrical, mechanical and
signaling interfaces (e.g. RS-232-C standard)
Data Link Layer
Group the bits into numbered frames and introduce checksums

If the receiver detects an error in the checksum asks for a retransmission
of the frame
Network Layer
Choose the best path to reach the destination (routing)

E.g.1: IP (Internet Protocol), the most widely used network protocol
(connectionless)
E.g.2: virtual channel ATM
(connection oriented)
J.P. Carvalho
14
OSI Model Transport Protocols

Transport Layer
Guarantee a reliable connection, i.e., guarantee that a message is not lost

Messages to be sent are divided into smaller, numbered, more
manageable packets
Received message packets are assembled in the proper order
Discussion in the Transport layer header concerns which packets of a
message have been sent, which have been received, which should be
retransmitted, etc.
Reliable Transport connections can be built on top of connection
oriented or connectionless network services
TCP (Transmission Control Protocol) is the Internet transmission
protocol (although not an OSI model protocol, is the de facto standard)
Other protocols:
UDP (Universal Datagram Protocol), connectionless transport
protocol
RTP (Real-Time Protocol), supports real-time data transfer
(although not guaranteeing data delivery)
J.P. Carvalho
15
OSI Model Transport Protocols

Transport Layer Client-Server TCP
Client-Server interaction in Distributed Systems is often done using the

transport protocols of the underlying network, namely TCP
TCP is reliable but introduces considerably overhead (especially in
reliable networks such as LANs)
Solution: Transactional TCP (T/TCP)
a) TCP
b) T/TCP
J.P. Carvalho
16
OSI Model Higher Level Protocols

Session Layer
Provides dialog control (who is currently talking) and synchronization

facilities. Usually not important and not used in the Internet protocol
Presentation Layer
Is concerned with the meaning of the bits (e.g., structured info like
peoples name, address, etc.)
Application Layer
Intended for standard network applications like e-mail, file transfer and
terminal emulation
Currently is the container for all the applications that do not fit into one
of the underlying layers
In the OSI Model there is not a clear distinction between applications,

application-specific protocols and general use protocols, and the Internet
protocol suite groups all the higher level layers into a single one. In
these models,
virtually all distributed
systems are just applications 17
J.P. Carvalho
Middleware consists of applications that obviously belong to the

Application Layer. However, middleware contains many generalpurpose protocols that warrant their own layer.
Several Middleware protocols, will be studied later throughout the
course (e.g., authentication protocols, commit protocols, etc.)
J.P. Carvalho
18
Middleware Communication Services

J.P. Carvalho
19

Goal: Remote Procedure Calls (RPC) make distributed
computing look like centralized computing
RPC allow remote services to be called as local procedures
(concealing the use of send and receive)
Transparency with regard to location, implementation and
language
Issues:
How to pass parameters;
Bindings;
Semantics in face of errors.
Two classes:
Integrated into the programming language
Separate from the programming language
J.P. Carvalho
20
Conventional Procedure Call

e.g.: count = read(fd, buf, nbytes)
a) Parameter passing in a local
procedure call: the stack
before the call to read
b) The stack while the called

procedure is active
Local procedure parameter passing:

Call-by-value;
J.P. Carvalho
Call-by-reference (arrays, complex data structures).
21
RPC (2)
Client and Server Stubs
Principle of RPC between a client and server program

[Birrell&Nelson 1984]
Client Stub: a routine that automatically replaces the local
procedure and calls the remote procedure
Server stub: a routine that transforms requests received over the
network into local procedure calls
J.P. Carvalho
22
RPC (3)
Client and Server Stubs (cont.)
Client makes procedure call (just like a local procedure call) to

the client stub
Server is written as a standard procedure
Stubs take care of packaging arguments and sending messages
J.P. Carvalho
23
RPC (4)
Steps of a Remote Procedure Call
1. Client procedure calls client stub in normal way
2. Client stub builds message, calls local OS
3. Client's OS sends message to remote OS
4. Remote OS gives message to server stub
5. Server stub unpacks parameters, calls server
6. Server does work, returns result to the stub
7. Server stub packs it in message, calls local OS
8. Server's OS sends message to client's OS
9. Client's OS gives message to client stub
10. Stub unpacks result, returns to client
J.P. Carvalho
24
RPC (5)
Example: Passing parameters on a RPC
2-8
J.P. Carvalho
25
RPC (6)
Marshalling and Parameter Passing
Marshalling: Transform parameters into a byte stream (aka parameter packaging)
Problem: different machines have different data formats (e.g. Intel uses little
endian, SPARC uses big endian)
Solution: Use a standard representation (e.g. external data representation
XDR)
Parameter Passing
Call-by-value parameters:
Pass a copy to the client stub
Call-by-reference parameters (pointers):
If parameter points to a well-defined data structure, pass a copy to the
client stub and the server stub passes a pointer to the local copy. Then the
server returns the altered structure which replaces the client one
Problem: What about data structures containing pointers?
Solution:
Prohibit, or:
Chase pointers over network (implies additional communication
between server and client).
J.P. Carvalho
26
RPC(7)
Parameter Specification and Stub Generation
RPCs require that both sides must follow the same protocol. The
caller and the callee must:
Agree on the format of the messages they exchange;
Follow the same steps when, for example, passing complex
data structures;
Agree on the representation of simple data structures (e.g.,
integers, chars, booleans, etc., and internal data
representation);
Agree on the actual exchange of messages (e.g., use a
connection oriented protocol, like TCP/IP, or a
connectionless like UDP).
After protocol definition, Stubs must be implemented:
IDL Interface Definition Language
IDL considerably simplifies RPC based client-server
applications
J.P. Carvalho
27
RPC(8)
E.g.: Parameter Specification
a)
b)
A procedure
The corresponding message
J.P. Carvalho
28
RPC(9)
Binding: How does a client locate a server?
Use Bindings
Server
Export server interface during initialization
Send name, version no, unique identifier, handle (address) to
binder
Client
First RPC: send message to binder to import server interface
Binder: check to see if server has exported interface
Return handle and unique identifier to client
Exporting and importing binders incurs overheads
Binder can be a bottleneck
Use multiple binders
Binder can do load balancing
J.P. Carvalho
29
Lightweight RPCs
Lightweight RPCs
RPC between processes running on the same machine

Allow transparent inter-process communication (replace shared
memory/pipes/queues/ etc.) while avoiding RPC inherent
overhead
Lightweight RPC execution:
1. Push arguments onto stack
2. Trap to kernel
3. Kernel changes memory map of client to server address space
4. Client thread executes procedure (OS upcall)
5. Thread traps to kernel upon completion
6. Kernel changes the address space back and returns control to
client
Called doors in Solaris
J.P. Carvalho
30
Lightweight RPCs
DOORS
Which RPC to use? Run-time bit allows stub to choose between

LRPC and RPC
J.P. Carvalho
31
Other RPC Models

Asynchronous RPC
Request-reply often not needed (e.g.: procedure does not
returns any argument):
Server can reply as soon as request is received and
execute procedure later
Deferred-synchronous RPC
Client needs a reply but cant wait for it; server sends reply
via another asynchronous RPC (i.e., communication uses two
asynchronous RPCs)
One-way RPC
Client does not even wait for an ACK from the server
Limitation: reliability not guaranteed (client does not know if
procedure was executed by the server).
J.P. Carvalho
32
Asynchronous RPC
a)
b)
The interaction between client and server in a traditional

RPC
The interaction using asynchronous RPC
2-12
J.P. Carvalho
33
Deferred Synchronous RPC

A client and server interacting through two
asynchronous RPCs
2-13
J.P. Carvalho
34
Case Study: DCE RPC

DCE (Distributed Computing Environment)
Developed by the Open Software Foundation (OSF), originally for

Unix systems
Uses a client-server model
Adopted for Microsofts distributed computing base system
When installed over an existing OS, DCE software allows running
distributed applications without disturbing non-distributed
applications
Clients and Servers can be highly independent from each other (e.g.:
can run in different hardware platforms, client can be written in Java
and server in C or vice-versa)
Services:
DFS Distributed File Service (worldwide file system that
provides a transparent way to access any file in the system)
Directory Service (system resource location)
Security Service
Distributed Time Service (synchronization)
At-most-once default semantics. Alternative: idempotent
J.P. Carvalho
35
DCE RPC (2)

Writing a Client and a Server in DCE:
Generate Interface Definition File

Compile using DCE IDL compiler
Each stub is generated with a
global unique ID
Write client and
server code
Compile
Link stubs and code
J.P. Carvalho
36
DCE RPC (3)

Binding a Client to a Server in DCE
J.P. Carvalho
37
Case Study: SUNRPC

SUNRPC
One of the most widely used RPC systems

Developed for use with NFS
Built on top of UDP or TCP
TCP: stream is divided into records
UDP: max packet size < 8912 bytes
UDP: timeout plus limited number of retransmissions
TCP: return error if connection is terminated by server
Multiple arguments marshaled into a single structure
At-least-once semantics if reply received, at-least-zero semantics if
no reply. With UDP tries at-most-once
Use SUNs eXternal Data Representation (XDR)
Big endian order for 32 bit integers, handle arbitrarily large data
structures
J.P. Carvalho
38
SUN RPC (2)

Rpcgen: generating stubs
Q_xdr.c: do XDR conversion
J.P. Carvalho
39
SUN RPC (3)

Binder: Port Mapper
Server start-up: create port

Server stub calls svc_register to register prog. #, version # with local
port mapper
Port mapper stores prog #, version #, and port
Client start-up: call clnt_create to locate server port
Upon return, client can call procedures at the server
J.P. Carvalho
40
RPC: Failure Semantics

Client unable to locate server: return error
Lost request messages: simple timeout mechanisms
Lost replies: timeout mechanisms
Make operation idempotent
Use sequence numbers, mark retransmissions
Server failures: did failure occur before or after operation?
At least once semantics (SUNRPC)
At most once (DCE default)
No guarantee
Exactly once: desirable but difficult to achieve
J.P. Carvalho
41
RPC: Failure Semantics(2)

Client failure: what happens to the server computation?
Referred to as an orphan
Extermination: log at client stub and explicitly kill
orphans
Overhead of maintaining disk logs
Reincarnation: Divide time into epochs between failures
and delete computations from old epochs
Gentle reincarnation: upon a new epoch broadcast, try to
locate owner first (delete only if no owner)
Expiration: give each RPC a fixed quantum T; explicitly
request extensions
Periodic checks with client during long computations
J.P. Carvalho
42

RPCs applied to objects, i.e., instances of a class
Class: object-oriented abstraction; module with
data and operations
Separation between interface and implementation
Interface resides on one machine, implementation
on another
Remote Object Invocation support system-wide object
references (Distributed Objects)
Object references can be used as parameters
J.P. Carvalho
43
Remote Object Invocation(2)

Distributed Objects
When a client binds to a distributed object, load the interface

(proxy) into client address space
Proxies are analogous to stubs
Server stub is referred to as a skeleton
J.P. Carvalho
44

Proxies and Skeletons
Proxy: client stub equivalent
Maintains server ID, endpoint, object ID
Sets up and tears down connection with the server
[Java:] does serialization of local object
parameters
In practice, can be downloaded/constructed on the
fly by using an implementation handle in the object
reference that the client can dynamically load when
binding to the remote object
Skeleton: server stub equivalent
Does deserialization and passes parameters to
server and sends result to proxy
J.P. Carvalho
45

Binding a Client to an Object
E.g.1: Implicit binding using only global references
Distr_object* obj_ref;
obj_ref = ;
obj_ref-> do_something();
//Declare a systemwide object reference

// Initialize the reference to a distributed object
// Implicitly bind and invoke a method
E.g.2: Explicit binding using global and local references

Distr_object objPref;
Local_object* obj_ptr;
obj_ref = ;
obj_ptr = bind(obj_ref);
obj_ptr -> do_something();
J.P. Carvalho
//Declare a systemwide object reference

//Declare a pointer to local objects
//Initialize the reference to a distributed object
//Explicitly bind and obtain a pointer to the local proxy
//Invoke a method on the local proxy
46

Parameter Passing
Less restrictive than RPCs.

Supports system-wide object references
All objects (local or remote) can be passed by reference
Problem: remote invocation is inefficient in what concerns
referencing small objects, such as integers or booleans
Solution [Java]: pass local objects by value (pass a copy of the
object), pass remote objects by reference
J.P. Carvalho
47
DCE Distributed-Object Model

a)
b)
Distributed dynamic objects in DCE.

Distributed named objects
J.P. Carvalho
48
Java RMI
Java Remote Method Invocation
Server
Defines interface and implements interface methods
Server program
Creates server object and registers object with
remote object registry
Client
Looks up server in remote object registry
Uses normal method call syntax for remote methods
Java tools
Rmiregistry: server-side name server
Rmic: uses server interface to create client and server
stubs
J.P. Carvalho
49
Java RMI(2)
Synchronization
Java supports Monitors (serializes accesses to objects):

synchronized objects
How does this work for remote objects? Options:
Block at server
Can synchronize across multiple proxies
Problem: what if the client crashes while blocked?
Option not used in Java RMI
Block at proxy (client)
Need to synchronize clients at different machines
Explicit distributed locking necessary (distributed
synchronization will be studied in a few weeks)
Java uses proxies for blocking
No protection for simultaneous access from different clients
Applications need to implement distributed locking
J.P. Carvalho
50
Java RMI(3)
Remote object invocation
Distinction between local and remote objects is hardly visible

(system-wide object references are possible due to the use of a Java
Virtual Machine at both client and server sides)
Any parameter that can be marshaled (i.e. serializable) can be passed
as a parameter to a RMI. Proxies can be serialized. Exceptions are
platform dependent objects like file descriptors, sockets, etc.
When a remote object is invocated and objects are used as
parameters:
Local objects are passed by value (pass a copy of the object)
Remote objects are passed by reference (pass the proxy or
instructions on how to implement the proxy)
J.P. Carvalho
51

RPC and RMI enhance transparency in Distributed
Systems, but can only be used when it is assumed that the
receiver is executing at the time the request is issued.
Likewise, the synchronous nature of RPC and RMI, by
which a client is blocked until its request is processed is
not always adequate.
Solution:
Message oriented communication
In order to understand the various alternatives in message
oriented communication, one must approach the concepts
of
Persistence
Synchronicity
J.P. Carvalho
52
Message Oriented Communication (2)

General organization of a message oriented
communication system in which hosts are connected
through a network
2-20
J.P. Carvalho
53
Persistence
Persistent communication
Messages are stored until communication with next
receiver is possible
Examples: email, pony express
J.P. Carvalho
54
Transient Communication
Transient communication (the opposite of persistent
communication)
Message is stored only so long as sending/receiving
application are executing
Discard message if it cant be delivered to next
server/receiver
Example: transport-level communication services offer
transient communication
Example: Typical network router discard message if
it cant be delivered next router or destination
J.P. Carvalho
55
Synchronicity
Asynchronous communication
Sender continues immediately after it has submitted the
message
Need a local buffer at the sending host
Synchronous communication
Sender blocks until message is stored in a local buffer at
the receiving host or actually delivered to the receiver
Variant: block until receiver processes the message
Six combinations of persistence and synchronicity
J.P. Carvalho
56
Persistence and Synchronicity Combinations

a)
b)
Persistent asynchronous communication (e.g., email)

Persistent synchronous communication
2-22.1
J.P. Carvalho
57
Persistence and Synchronicity Combinations (2)

c)
d)
Transient asynchronous communication (e.g., UDP)

Receipt-based transient synchronous communication
J.P. Carvalho
58
Persistence and Synchronicity Combinations (3)

e)
f)
Delivery-based transient synchronous communication at message

delivery (e.g., asynchronous RPC)
Response-based transient synchronous communication (RPC)
J.P. Carvalho
59
Message-oriented Transient Communication

Many distributed systems are built on top of simple
message-oriented model
E.G: Berkeley sockets
Socket: a communication endpoint to which an
application can write data to be sent to the network,
or where an application can read incoming data
J.P. Carvalho
60
Message-oriented Transient Comm. (2)

Berkeley Socket Primitives
Primitive
Socket
Meaning
Create a new communication endpoint
Bind
Attach a local address to a socket (IP + port #)
Listen
Announce willingness to accept connections
Accept
Block caller until a connection request arrives
Connect
Actively attempt to establish a connection
Write
Send some data over the connection
Read
Receive some data over the connection
Close
Release the connection
J.P. Carvalho
61
Sockets are designed for network communication (e.g., TCP/IP)

Support simple send/receive primitives
Socket abstraction is not suitable for protocols in clusters of workstations
or massively parallel systems
The need of an interface with more advanced primitives led to a large
number of incompatible proprietary libraries and protocols
The need for a standard hardware independent interface led to the:
Message-passing interface (MPI)
Hardware independent
Designed for parallel applications (uses transient communication)
Key idea: communication between groups of processes
Each endpoint is a (groupID, processID) pair
MPI primitives implement the most relevant transient/synchronicity
combinations
J.P. Carvalho
62

MPI Primitives
Primitive
Meaning
MPI_bsend
Append outgoing message to a local send buffer
MPI_send
Send 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_issend
Pass 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
J.P. Carvalho
63
Message-oriented Persistent Comm.

Message queuing systems
Support asynchronous persistent communication
Intermediate storage for message while
sender/receiver are inactive
Example application: email
Communicate by inserting messages in queues
Sender is only guaranteed that message will be
eventually inserted in recipients queue
No guarantees on when or if the message will be
read
Loosely coupled communication
J.P. Carvalho
64
Message-oriented Persistent Comm.(2)

Message-Queuing Model
Primitive
Meaning
Put
Append a message to a specified queue
Get
Block until the specified queue is nonempty, and remove the first
message
Poll
Check a specified queue for messages, and remove the first. Never
block.
Install a handler to be called when a message is put into the

Notify
J.P. Carvalhospecified queue. Sistemas Distribudos 2005/2006
65
Message-oriented Persistent Comm.(3)

General message-queuing systems vs. e-mail
E-mail aims at providing direct support for the end users (this is why
groupware is often based on e-mail systems)
General purpose message-queuing systems are set up to enable persistent
based communication between all kinds of processes. Therefore they
should also provide:
Guaranteed message delivery;
Message priorities;
Logging facilities;
Efficient multicasting;
Load balancing;
Fault tolerance;
Etc.
E.g.: IBM MQSeries
J.P. Carvalho
66
Message-oriented communication implies request-response and can only

be used when communication speed does not affect correctness
But timing is crucial in certain forms of communication. Solution:
Examples: audio and video (continuous media)

30 frames/s video => images must be displayed in the correct order
AND a frame must be displayed every 33ms
Characteristics
Use data streams (supported by, e.g., Unix pipes or TCP/IP
connections)
Isochronous communication
Data transfers have a maximum bound on end-to-end delay
(bounded jitter)
Push mode: no explicit requests for individual data units beyond the
first play request
J.P. Carvalho
67
Stream Oriented Communication (2)

Stream Oriented Communication (cont.)
Stream: a virtual connection between a source (process) and
a sink (a process or a device)
Streams can be:
Simple;
Complex (several related time dependent substreams, e.g.
stereo audio; movie image and movie sound).
Streams can have:
Single sink;
Multiple sinks (multicast streaming).
J.P. Carvalho
68

Single sender and receiver
One sender, Multiple receivers
J.P. Carvalho
69

Specifying Quality of Service (QoS)
Time-dependence and other requirements are specified as Quality of

Service requirements:
Requirements and guarantees from the underlying system (e.g.: describe what
is needed from the underlying DS and network to ensure that the temporal
relationships in a stream can be preserved)
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)
Maximum Loss Rate (bytes/time unit)

Burst loss sensitivity (data units)
Minimum delay noticed (sec)
Maximum delay variation (sec)
Quality of guarantee
Application specifies workload and requests a certain service quality

Problem: How does the application/user knows its own requirements?
Carvalho
70
AJ.P.
contract
is issued between
the application and the system

Specifying QoS: Token Bucket
Token buckets are used to specify how the stream will shape its network traffic
Parameters (rate r, burst b, token size k )
Rate is the average rate tokens are added to bucket, burst is the maximum
number of packets that can arrive simultaneously, k is the token size in bytes
Each time the application wants to pass a data unit of size N to the network, it
will have to remove at least N/k tokens from the bucket
Implements a relatively constant rate while allowing sporadic bursts
J.P. Carvalho
71

Setting Up a Stream: RSVP (Resource Reservation Protocol)
Transport level control protocol for enabling resource reservations in network

routers
Receiver initiated QoS protocol
Receivers send reservation requests along the path to the sender
RSVP process receives and stores the specification parameters, checks if there are
available resources and checks if receiver has permission to make the reservation
J.P. Carvalho
72

Stream Synchronization
Goal: maintain temporal relations between streams

Synchronization types:
Between a discrete stream and a continuous stream (e.g.: a slide show
where each slide starts playing music)
Between continuous streams (e.g.: synchronize sound and image
streams lip sync, stereo audio)
E.g. CD-quality audio stream: 16 bit samples with sampling freq =
44100Khz; synchronization between streams should take place every
23s
Synchronization Mechanisms
Monitor programs that check streams at relevant instants and adjust rate
if necessary
Multimedia middleware systems offer a collection of interfaces to control
and synchronize streams
J.P. Carvalho
73
Bibliography
1. Tannenbaum, A., Steen, M., Distributed Systems: Principles and Paradigms,
Prentice-Hall International, 2002, Chapter 2.
2. Tannenbaum, A., Computer Networks, Prentice-Hall International, 3rd ed.,
1996.
3. Birrell, A. and Nelson, B., Implementing RPCs, ACM Transactions on
Computer Systems, Vol. 2, No. 1, Pages 39-59, February 1984
4. Bershad, B., Anderson, T., Lazowska, E., and Levy, H., Lightweight Remote
Procedure Call, Proceedings of the 12th ACM Symposium on Operating
Systems Principles, Operating Systems Review, Vol. 23, No. 5, Pages 12-113,
December 1989
5. Sun RPC documentation
http://www.ocaml-programming.de/packages/documentation/rpc/
http://www.cc.gatech.edu/classes/cs4431_99_winter/rpc.html
http://www.pk.org/rutgers/notes/buzz/l-04.html
6. Java RMI documentation
http://java.sun.com/products/jdk/rmi/reference/docs/index.html
http://java.sun.com/j2se/1.3/docs/guide/rmi/
http://tns-www.lcs.mit.edu/manuals/java-api-1.1beta2/guide/rmi/
J.P. Carvalho
74

Communication

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Communication

Hochgeladen von

Copyright:

Verfügbare Formate

Distributed Systems

LEEC (2005/06 2 Sem.)

Communication in Distributed Systems

Joo Paulo Carvalho

Universidade Tcnica de Lisboa / Instituto Superior Tcnico

Remote Procedure Calls

Client and Server Stubs

Remote Object Invocation

Message Oriented Communication

Sistemas Distribudos 2005/2006

Absence of shared memory implies that communication

Sistemas Distribudos 2005/2006

Sistemas Distribudos 2005/2006

Sistemas Distribudos 2005/2006

Communication Issues (2)

Sistemas Distribudos 2005/2006

Communication Issues (3)

Sistemas Distribudos 2005/2006

Communication Issues (4)

Sistemas Distribudos 2005/2006

Communication Issues (5)

Sistemas Distribudos 2005/2006

Communication Issues (6)

Sistemas Distribudos 2005/2006

Designed to allow open systems to communicate;

Sistemas Distribudos 2005/2006

OSI Model (2)

When process A wants to communicate with process B, it builds a

Sistemas Distribudos 2005/2006

OSI Model (3)

When the message arrives to the machine where process B is running,

Sistemas Distribudos 2005/2006

OSI Model Lower Level Protocols

Concerned with transmitting the 0s and 1s:

Data Link Layer

Group the bits into numbered frames and introduce checksums

Choose the best path to reach the destination (routing)

OSI Model Transport Protocols

Guarantee a reliable connection, i.e., guarantee that a message is not lost

Sistemas Distribudos 2005/2006

OSI Model Transport Protocols

Client-Server interaction in Distributed Systems is often done using the

Sistemas Distribudos 2005/2006

OSI Model Higher Level Protocols

Provides dialog control (who is currently talking) and synchronization

In the OSI Model there is not a clear distinction between applications,

Middleware consists of applications that obviously belong to the

Sistemas Distribudos 2005/2006

Middleware Communication Services

Remote Procedure Calls

Sistemas Distribudos 2005/2006

Remote Procedure Calls

Sistemas Distribudos 2005/2006

Conventional Procedure Call

b) The stack while the called

Local procedure parameter passing:

Principle of RPC between a client and server program

Sistemas Distribudos 2005/2006

Client makes procedure call (just like a local procedure call) to

Sistemas Distribudos 2005/2006

Sistemas Distribudos 2005/2006

Sistemas Distribudos 2005/2006

Sistemas Distribudos 2005/2006

Sistemas Distribudos 2005/2006