Transcript Chapter_2

Communication
Inter-process Communication is the heart
of a Distributed System
Basic mechanisms are:
•RPC
•RMI
•MOM
•Streams
1
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!
1.
2.
3.
4.
Voltage (0/1)? For bit representation..
Correctness of messages
Representation of numbers, strings, and data items(in different
machines)
Etc.
2
Approach: OSI Layered Protocols
2-1
OSI Open System Interconnection Reference:
Layers, interfaces, and protocols in the OSI model.
3
Layered Protocols: as you dip into the layers
you “add” more info
2-2
A typical message as it appears on the network.
4
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.
5
Physical Level
Mostly concerned with the transmission of 0/1s..
• Voltage level
• Rate of transmission
• Network connectors (plugs)
Example:
RS232c (standard for serial communication).
6
Data Link Layer: frames & checksums
2-3
Discussion between a receiver and a sender in the data link layer.
7
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)
8
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)
9
Example: Client-Server TCP
2-4
a)
b)
Normal operation of TCP.
Transactional TCP (TCP for Transactions Suite)
10
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)
– TELNET, SSH
11
Example of Higher Level Protocols:
Middleware Protocols
2-5
An adapted reference model for networked communication
that may enforce the notion of “atomicity” 12
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!
13
Conventional Procedure Call
a)
b)
Parameter passing in a local procedure call: the stack before the
call to read (from main() )
14
The stack while the called procedure is active
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).
15
Client and Server Stubs
Principle of RPC between a client and server program.
16
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
17
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.
18
Passing Value Parameters
2-8
Steps involved in doing remote computation through RPC
19
Possible Problems with Passing Value Parameters
a)
b)
c)
d)
e)
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)
20
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.
21
Parameter Specification and Stub Generation
•In order to hide the details of RPC some conventions (protocol)
between theClient and the Servers have to be established..
•Representations (formats) of int, float, double, char, etc have to be
•Be agreed upon.
En example..
•
A procedure
•
The corresponding message.
RPC protocols can be established with IDL specs (that are compiled
Into client/server stubs…)
22
Extensions of RPCs:Doors[Hamilton & Kougiouris 94]
•What if caller/callee are in the same machine?? (classic IPC problem)
•Door is a generic name for a procedure in the address space of a server
process & can be called by processes colocated with the server.
•Requires support from the local OS.
Plus: allows the use of procedure
calls mechanism for a distributed
system.
Minus: developers still need to be
aware whether a call is done
locally or remotely
23
Asynchronous RPC
2-12
a)
b)
The interconnection between client and server in a
traditional RPC
24
The interaction using asynchronous RPC
Asynchronous RPC
2-13
• A client and server interacting through two asynchronous RPCs
• One-way RPCs
25
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:
1.
2.
3.
4.
Distributed File Service (the worldwide file system)
Directory Service
Security Service
Distributed Time Service (why?)
26
Writing a Client and a Server
2-14
The steps in writing a client and a server in DCE RPC.
27
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!).
28
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)
29
Binding a Client to a Server
2-15
Client-to-server binding in DCE.
•Example: a client wants to bind to a video server that is locally
known as /local/multimedia/video/movies
•DCE semantics
•Default: at-most-once operation
•Otherwise: idempotent (done with the help of IDL)
•a remote Procedure call can be called a number of times.
30
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.
31
Distributed Objects
2-16
•
•
•
•
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.
32
33
34
Implicit/Explicit Binding of
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 objPref;
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)
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)
35
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?
36
Parameter Passing in RMI
There are subtleties with RMI invocation (more so than with RPCs)
References to remote/local objects are handled differently
•When invoking a method with an object reference as parameter
•Reference is copied and passed as a value parameter only when
it refers to a remote object
•When the reference is made on a local (client) object, the object
is copies as a whole and passed along with the invocation
Passing an object by reference or by value.
37
Message Oriented Communication
•RPCs & RMIs hide communication element of the interaction
•In general both RPCs & RMIs are blocking
•An alternative to those is communication based on messages
•General organization for message-oriented communication is shown below
38
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
39
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).
40
Possible Combinations(sync/async-persi/transi)
2-22.1
a)
b)
Persistent asynchronous communication
Persistent synchronous communication(msg actually delivered to
the receiving site)
41
Combos
2-22.2
c)
d)
Transient asynchronous communication (examples are UDP,
asynchronous RPCs)
Receipt-based transient synchronous communication
42
Combos
e)
f)
Delivery-based transient synchronous communication at
message delivery
Response-based transient synchronous communication
(RPCs & RMIs mostly adhere to this type of
communication).
43
Berkeley Sockets
A socket is a communication endpoint to which the
application from which can read data from or write data to.
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
Socket primitives for TCP/IP.
44
How Berkeley SocketsWork
Connection-oriented communication pattern using sockets.
45
The MPI Interface
•MPI designed for parallel application programs
(transient communication)
•Communication happens among a group of known processes.
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
Some of the most intuitive message-passing primitives of MPI.
46
Message-Queuing Systems
•Offer intermediate storage capacity for msgs
•Good for transferring bulky message (in seconds) than simple
messages (usually in milliseconds).
•Important: sender is provided with the guarantee that her message
will ultimately be inserted in the recipient’s queue.
•Servers/receivers can execute completely independent of each other
Four combinations for loosely-coupled communications using queues. 47
Message-Queuing Model: calls
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.
Basic interface to a queue in a message-queuing system.
48
General Architecture of a Message-Queuing System
• source queues, destination queues
• database of queue names
• queuing layer
The relationship between queue-level addressing and
network-level addressing.
49
General Architecture of a Message-Queuing System
•Relays can be good (in a messaging system)
•Usually the queue-to-location mapping is managed statically
•Otherwise, routers have to be used (in this case, relays can be
used to build scalable messaging systems).
2-29
The general organization of a message-queuing system with routers.
50
Message Brokers
•Brokers are used to convert to various message types.
•For example convert message from X.400 to Internet messages
•The database can handle many such conversion rules.
The general organization of a message broker in a message51
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
52
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.
53
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)
54
Data Streams
•Simple stream: single sequence of data
•Complex stream: consists of several related simple streams
(known as substreams)
•A stream is often considered a (virtual) connection
between a source and a sink.
Setting up a stream between two processes across a network.
55
Data Streams with Direct Connection
between Source and Sink
Setting up a stream directly between two devices.
56
What if the sink is a multiparty?
The data stream is multicast to several (receivers) sinks.
• Receivers may have different requirements
• Filters have to be attached…
57
Specifying QoS
Time-dependent requirements are collectively known
as Quality of Service (QoS) requirements.
How one could define such a QoS? .. Via a flow spec
Characteristics of the Input
•maximum data unit size (bytes)
•Token bucket rate (bytes/sec)
•Toke bucket size (bytes)
•Maximum transmission rate
(bytes/sec)
Service Required
•Loss sensitivity (bytes)
•Loss interval (sec)
•Burst loss sensitivity (data units)
•Minimum delay noticed (sec)
•Maximum delay variation (sec)
•Quality of guarantee
A flow specification.
58
Partridge’s Model expressed with a Token Bucket Algorithm
•This model specifies how the stream will shape its network traffic
•Idea: tokens appear in the network at a constant rate.
•When the bucket fills, tokens are dropped.
•Each time the application wants to pass N bytes removes N/k tokens
from the bucket (each token represents k bytes).
The principle of a token bucket algorithm.
59
Setting Up a Stream- RSVP Protocol
The basic organization of RSVP for resource reservation in a
distributed system.
60
Synchronization Mechanisms
•Complex Streams have to be synchronized..
•How is this done?
The principle of explicit synchronization on the level data units.
61
Synchronization Mechanisms
Multimedia Middleware offers a collection of interfaces
• interfaces control audio/video streams
• control devices such as mics, cameras, monitors
• each device/stream has its own interface (used to write
synchronization handlers).
The principle of synchronization as supported by high-level interfaces.
62