Transcript Communication

Communication
Chapter 2
1
Layered Protocols (1)

Layers, interfaces, and protocols in the OSI model.
2
Layered Protocols (2)

A typical message as it appears on the network.
3
Data Link Layer

Discussion between a receiver and a sender in the data link
layer.
4
Client-Server TCP
5
Middleware Protocols

An adapted reference model for networked communication.
6
Remote Procedure Call

Remote Procedure Call (RPC)


Definition: Information can be transported from
the caller to the callee in the parameters and
can come back in the procedure result.
Problems




Calling and called procedures run on different
machine
Executed in different address spaces (more
complications)
Passing parameters and results (especially in
not identical or typos)
Machine crash or failure when execution
7
Conventional Procedure Call
fd: an integer indicating a file
 buf: an array  using call-by-copy/restore
 nbytes: how many bytes to read

a)
b)
Parameter passing in a
local procedure call: the
stack before the call to
read
The stack while the called
procedure is active
8
Client and Server Stubs

Put a different version of read in the client’s
library


Server-side equivalent of a client stub


Client stub
Server stub
Principle of RPC between a client and server program.
9
Steps of a Remote Procedure Call
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
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
10
Passing Value Parameters (1/2)

Parameter Marshaling


Packing parameters into a message
Steps involved in doing remote computation through RPC
11
Passing Value Parameters (2/2)

Problems

Different char. representations



Different math. representations


One’s complement vs. two’s complement
Data storing way



IBM mainframe: EBCDIC character code
IBM PC: ASCII character code
Intel Pentium: store numbers from right to left
Sun SPARC: from left to right
How to pass pointers & references
a) Original message on the
Pentium
b) The message after receipt on
the SPARC
c) The message after being
inverted. The little
numbers in boxes indicate
the address of each byte
12
Parameter Specification and Stub Generation
Defining the message format is one aspect
of an RPC protocol
 A standard of data structure representation
 An interface consists of a collection of
procedure that can be called by a client.


Interface: Interface Definition Language (IDL)
a)
b)
A procedure
The
corresponding
message.
13
Extended RPC Models

Performance Concern



RPC message exchange will cost a lot because they reside in different
machines.
IPC (local interprocess communication) can overcome this problem since
they are used in the same machine.
Doors



A generic name for a procedure in the address space of a server process
that can be called by processes colocated with the server.
A similar mechanism is called Lightweight RPC.
A registered door (registered to OS) can be made available to other
processes
Need OS support!!
14
Asynchronous RPC (1/2)
To overcome the drawback of RPC client’s
waiting.
 Asynchronous RPC can be made both either
concurrently.



Combining two asyn. RPCs is sometimes
referred to as a deferred synchronous RPC.
Note that “one-way RPCs” don’t need server
to reply an ACK back to the client.
15
Example: DCE RPC

DCE (Distributed Computing Environment)




Developed by the Open Software Foundation
(OSF)
A middleware system
Initially designed for UNIX, now in VMS and
Windows NT
Some famous services of the DCE





Distributed file service
Directory service
Security service
Distributed time service
DCE RPC enables a client to access a
remote service by simply calling a local
procedure.
16
Writing a Client and a Server


Using Interface Definition Language (IDL)
IDL files contain





type definitions, constant declarations, and information
needed to marshal parameters
Formal definition of what the procedures do
The syntax of the calls
Globally unique identifier for specified interface
Writing client/server DCE RPC (See next page)




First, using uuidgen program to generate a prototype IDL
file
Second, editing the IDL file, filling the names of the
procedures and their parameters.
Call IDL compiler to generate 3 files: the header file, the
client stub, and the server stub
Finally, programmer write the client and server code.
17
Writing a Client and a Server

The steps in writing a client and a server in DCE RPC.
18
Binding a Client to a Server

How a client can call a server


Server location announcement




It is necessary that the server be registered and prepared to
accept incoming calls.
1. Locate the server’s machine
2. Locate the server (i.e., the correct process) on that machine.
The client needs to know an endpoint, (also known as port)
which is used by the server’s OS to distinguish incoming
messages for diff. processes.
In DCE, a table of (server, endpoint)-pairs is maintained on
each server machine by a process called DCE daemon.

Client-to-server
binding in DCE.
19
Remote Object Invocation





Object encapsulates data, called the state, and the
operations on those data called methods.
Methods are made available through an interface.
The interface and the objects can be placed in different
machine.
Client binds to a distributed object (DO), an implementation
of the object’s interface, called a proxy.
Skeleton, a server stub, used to unmarshal invocation
requests to proper method invocations at the object’s
interface at the server.
20
Compile-time vs. Runtime Objects


A class is a description of an abstract type in terms
of a module with data elements and operations on
that data.
Compile-time



Runtime



Advantage: easy to build distributed app.
Drawbacks: the dependency on a particular PL.
Advantage: distributed objects had been written.
It’s easy to constructing distributed app. by using objects
in different language.
Persistent and Transient Objects


Persistent objects are alive on the server all the time.
Transient objects exist only as long as the server manages
the object.
21
Binding a Client to an Object
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
(a)
Distr_object* obj_ref;
Local_object* obj_ptr;
obj_ref = …;
obj_ptr = bind(obj_ref);
obj_ptr -> do_something();
//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
(b)
a)
b)
(a) Example with implicit binding using only global references
(b) Example with explicit binding using global and local references
22
Static vs. Dynamic RMI

Remote Method Invocation (RMI)

Static invocation



The interfaces of an object are known when the client
application is being developed
If interfaces change, the client application must be
recompiled.
Dynamic invocation



invoke(object, method, input_parameters,
output_parameters);
object: distributed object; method: method to be
invoked; input_para: data structure; output_para: data
structure
has been known
For example
 Static: fobject.append(int)
 Dynamic: invoke(fobject, id(append), int)
returns an id for the method append
23
Parameter Passing

The situation when passing an object by reference or by
value.
2-18
24
The DCE Distributed-Object Model
a)
b)
Distributed dynamic objects in DCE.
Distributed named objects
25
Persistence and Synchronicity in Communication (1)

General organization of a communication system in which
hosts are connected through a network
2-20
26
Persistence and Synchronicity in Communication (2)

Persistent communication of letters back in the days of the
Pony Express.
27
Persistence and Synchronicity in Communication (3)
a)
b)
Persistent asynchronous communication
Persistent synchronous communication
2-22.1
28
Persistence and Synchronicity in Communication (4)
2-22.2
c)
d)
Transient asynchronous communication
Receipt-based transient synchronous communication
29
Persistence and Synchronicity in Communication (5)
e)
f)
Delivery-based transient synchronous communication at
message delivery
Response-based transient synchronous communication
30
Berkeley Sockets (1)

Socket primitives for TCP/IP.
Primitive
Meaning
Socket
Create a new communication endpoint
Bind
Attach a local address to a socket
Listen
Announce willingness to accept connections
Accept
Block 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
31
Berkeley Sockets (2)

Connection-oriented communication pattern using sockets.
32
The Message-Passing Interface (MPI)
MPI is used in local communication system
 Socket, in contrast with MPI, has two
drawbacks



Wrong level of abstraction by supporting send
and receive primitives.
Using general protocol stacks, TCP/IP
Socket is not suitable for COWs (Cluster of
Workstations) or MPPs (Massively Parallel
Processors)
 MPI is designed for parallel applications
 MPI use (groupID, processID) to replace
TCP/IP.

33
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_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
34
Message-Queuing Model (1/2)








Also called as Message-Oriented Middleware (MOM)
Intermediate-term storage capacity for messages,
without requiring either the sender or receiver to
be active during message transmission.
Difference with Berkeley socket and MPI
Applications communicate by inserting messages in
specific queues.
A queue can be read only by its associated
application, but it is also possible for multiple
applications to share a single queue.
Loosely-coupled communication
Like the Internet e-mail system
Allow a process to install a handler as a callback
function, which is automatically invoked whenever
a message is put into the queue.
35
Message-Queuing Model (2/2)

Four combinations for loosely-coupled communications using
queues.
36
Message-Queuing Model (2)

Basic interface to a queue in a message-queuing system.
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.
Notify
Install a handler to be called when a message is put into the specified queue.
37
General Architecture of a Message-Queuing System (1/3)

The relationship between queue-level addressing and
network-level addressing.
38
General Architecture of a Message-Queuing System (2/3)

Source queue



Destination queue


Local to the receiver
Queue manager


Local to the sender
On the same machine or on a machine nearby
such as on the same LAN.
Interacts directly with the application that is
sending or receiving a message
Relays

Special queue managers that operate as routers
39
General Architecture of a Message-Queuing System (3/3)

The general organization of a message-queuing system with
routers.
40
Message Brokers





The problem of integrating existing and new applications into
a single, coherent distributed information system.
Acts as an application-level gateway
To convert incoming messages to a format that can be
understood by the destination application.
Simple as a reformatter for messages.
The general organization of a message broker in a messagequeuing system.
41
Example: IBM MQSeries

General organization of IBM's MQSeries message-queuing
system.
42
Channels

Some attributes associated with message channel agents.
Attribute
Description
Transport type
Determines the transport protocol to be used
FIFO delivery
Indicates 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
43
Message Transfer (1)

The general organization of an MQSeries queuing network
using routing tables and aliases.
44
Message Transfer (2)

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
Primitives available in an IBM MQSeries MQI
45
Data Stream (1/3)

Continuous media


Discrete media


The temporal relationships between different data items
are fundamental to correctly interpreting what the data
actually means.
The temporal relationships between different data items
are not fundamental to correctly interpreting the data.
Data stream

Nothing but a sequence of data units.
46
Data Stream (2/3)

Asynchronous transmission mode


Synchronous transmission mode


The data item in a stream are transmitted one after the
other, but there are no further timing constraints on when
transmission of items should take place.
There is a maximum end-to-end delay defined for each
unit in a data stream
Isochronous transmission mode


It is necessary that data units are transferred on time.
Data transfer is subject to a maximum and minimum endto-end delay, also referred to as bounded (delay) jitter.
47
Data Stream (3/3)

Simple stream


Complex stream



Consists of only a single sequence of data
Consists of several related simple stream, called
substreams.
Main problem with multicast streaming is when the
receivers have different requirements with respect
to the quality of the stream.
Filter
48
Streams and Quality of Service (QoS)

Quality of Service (QoS)


Flow specification


Time-dependent (and other nonfunctional)
requirements are generally expressed as
Bandwidth requirements, transmission rates,
delays, etc.
Token bucket algorithm

How the stream will shape its network traffic
49
Specifying QoS
Characteristics of the Input
Service Required
maximum
Loss
data unit size (bytes)
Token bucket rate (bytes/sec)
Toke bucket size (bytes)
Maximum transmission rate (bytes/sec)

sensitivity (bytes)
Loss interval (sec)
Burst loss sensitivity (data units)
Minimum delay noticed (sec)
Maximum delay variation (sec)
Quality of guarantee
A flow specification.
50
Setting Up a Stream

Resource reSerVation Protocol (RSVP)




A transport-level control protocol for enabling resource
reservation in network routers.
Does not interpret the flow specification
Receiver-initiated QoS protocol
In fact, to make RSVP work, the RSVP process will
have to translate the QoS parameters of its flow
specifications into things that make sense to the
data link layer.
51
Synchronization Mechanisms (1)

The principle of explicit synchronization on the level data
units.
52
Synchronization Mechanisms (2)

The principle of synchronization as supported by high-level
interfaces.
2-41
53