20 februari 2006 client-server and multicast communication 1 rené de vries based on slides by m.l....
Post on 19-Dec-2015
215 views
TRANSCRIPT
20 februari 2006
Client-Server and Multicast Communication
1
Client-Server and Multicast Communication
René de Vries
Based on slides by M.L. Liu and M. van Eekelen
20 februari 2006 Client-Server and Multicast Communication 2
Overview Client Server Communication
Chapter 5: Liu
Introduction– Reviewing, usage and definitions
Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References
20 februari 2006 Client-Server and Multicast Communication 3
Introduction
The Client-Server paradigm is the most prevalent model for distributed computing protocols.
It is the basis of all distributed computing paradigms at a higher level of abstraction.
It is service-oriented, and employs a request-response protocol.
20 februari 2006 Client-Server and Multicast Communication 4
The Client-Server Paradigm
A server process, running on a server host, provides access to a service. A client process, running on a client host, accesses the service via the server process. The interaction of the process proceeds according to a protocol.
...
s e rvic e re que s t
a s e rve r pro c e s s
a c l ie nt pro c e s s
a s e rvic e
The C l i e nt-Se r ve r P ar adi g m , c o nc e ptual
Se r ve r ho s t
C l i e nt ho s t
20 februari 2006 Client-Server and Multicast Communication 5
Client-server, an overloaded term
...
s e rv e r h o s t
clie n t h o s t s
C lie n t h o s t s m a k e u s e o f s e rv ice spro v ide d o n a s e rv e r h o s t .
C l i e nt-Se r ve r Sys te m Ar c hi te c tur e..
.
s e rvic e r e que s t
a s e rve r pro c e s s
a c l ie nt pro c e s s
a s e rvic e
The C l i e nt-Se r ve r P ar adi g m , c o nc e ptual
Se r ve r ho s t
C l i e nt ho s t
C l i e nt-Se r ve r C o m puti ng P ar adi g m
C lie n t pro ce s s e s (o bje ct s ) m a k e u s e o f a s e rv icepro v ide d by a s e rv e r pro ce s s (o bje ct ) ru n n in g o na s e rv e r h o s t .
20 februari 2006 Client-Server and Multicast Communication 6
Client-server applications and services
An application based on the client-server paradigm is a client-server application.
On the Internet, many services are Client-server applications. These services are often known by the protocol that the application implements.
Well known client-server Internet services include HTTP, FTP, DNS, finger, etc.
User applications may also be built using the client-server paradigm.
20 februari 2006 Client-Server and Multicast Communication 9
A service session
s ta rt s e rv ice
a cce pt a c lie n t 'sre qu e s t fo r a s e s s io n
co n du ct a s e s s io nwith th e c lie n t
A Session is an interaction between the server and one client.
20 februari 2006 Client-Server and Multicast Communication 10
The interprocess communications and event synchronization
Typically, the interaction of the client and server processes follows a request-response pattern.
clie n t s e rv e r
re qu e s t 1
re qu e s t 2
re qu e s t n
re s po n s e 1
re s po n s e 2
re s po n s e n
20 februari 2006 Client-Server and Multicast Communication 11
Session IPC examples
The dialog in each session follows a pattern prescribed in the protocol specified for the service.
Daytime service [RFC867]:Client: Hello, <client address> here. May I have a timestamp
please.Server: Here it is: (time stamp follows)
World Wide Web session:Client: Hello, <client address> here. Server: Okay. I am a web server and I speak protocol HTTP1.0.Client: Great, please get me the web page index.html at the root of
your document tree.Server: Okay, here’s what’s in the page: (contents follows).
20 februari 2006 Client-Server and Multicast Communication 12
The Protocol for a Network Service
A protocol is needed to specify the rules that must be observed by the client and the server during the conducting of a service.i. how the service is to be locatedii. the sequence of interprocess communication (dynamics)iii. the representation and interpretation of data exchanged with
each IPC (signature)
On the Internet, such protocols are specified in the RFC-series.The Request For Comments (RFC) document series is a set of technical and organizational notes about the Internet (originally the ARPANET), beginning in 1969. Memos in the RFC series discuss many aspects of computer networking, including protocols, procedures, programs, and concepts, as well as meeting notes and opinions.
20 februari 2006 Client-Server and Multicast Communication 13
Locating the service
A mechanism must be available to allow a client process to locate a server for a given service.
A service can be located through the address of the server process, in terms of the host name and protocol port number assigned to the server process. This is the scheme for Internet services. Each Internet service is assigned to a specific port number. In particular, a well-known service such as ftp, HTTP, or telnet is assigned a default port number reserved on each Internet host for that service.
At a higher level of abstraction, a service may be identified using a logical name registered with a registry, the logical name will need to be mapped to the physical location of the server process. If the mapping is performed at runtime (that is, when a client process is run), then it is possible for the service’s location to be dynamic, or moveable.
20 februari 2006 Client-Server and Multicast Communication 14
Overview Client Server Communication
Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summery References
20 februari 2006 Client-Server and Multicast Communication 15
Connectionless Server
A connectionless server accepts one request at a time from any client, processes the request, and sends the response to the requestor.
a r eq u es t
a r es p o n s e
C o n n e ct io n le s s S e rv e r
C lie n t s
20 februari 2006 Client-Server and Multicast Communication 16
Software Engineering for a Network Service
pre s e n ta t io n lo g ic
a pplica t io n lo g ic
s e rv ice lo g ic
a pplica t io n lo g ic
s e rv ice lo g ic
c l i e nt -s i de s o ftw ar e
s e r ve r -s i de s o ftw ar e
20 februari 2006 Client-Server and Multicast Communication 17
Example protocol: daytime
clie n ts e rv e r
m
s e qu e n ce dia g ra m
da ta re pre s e n ta t io n : t e x t ( ch a ra cte r s t r in g s )da ta fo rm a t :m : co n ta in s a t im e s ta m p, in a fo rm a t s u ch a s W e d J a n 3 0 0 9 :5 2 :4 8 2 0 0 2
Defined in RFC867
20 februari 2006 Client-Server and Multicast Communication 18
Daytime Protocol
clie n t s e rv e r
m 2
s e qu e n ce dia g ra m
da ta re pre s e n ta t io n : t e x t ( ch a ra cte r s t rin g s )da ta fo rm a t :m 1 ; a n u ll m e s s a g e - co n te n ts will be ig n o re d.m 2 : co n ta in s a t im e s ta m p, in a fo rm a t s u ch a s W e d J a n 3 0 0 9 :5 2 :4 8 2 0 0 2
m 1
20 februari 2006 Client-Server and Multicast Communication 19
Daytime Protocol Implementation
Sample 1 – using connectionless sockets:
DaytimeServer1.java
DaytimeClient1.java
20 februari 2006 Client-Server and Multicast Communication 20
The getAddress and getPort Methods
Method (of DatagramPacket class)
Description
public InetAddress getAddress( )
Return the IP address of the remote host from a socket of which the datagram was received.
public int getPort( ) Return the port number on the remote host from a socket of which the datagram was received.
20 februari 2006 Client-Server and Multicast Communication 21
Connectionless Echo Server (advanced)
DatagramSocket ds = new DatagramSocket(port); while (true) { try { // create a new datagram packet byte[] buffer = new byte[MAXLEN]; DatagramPacket dp = new DatagramPacket(buffer, MAXLEN); ds.receive(dp); len = dp.getLength(); cAddr = dp.getAddress(); cPort = dp.getPort(); String s = new String(dp.getData(), 0, len); System.out.println(dp.getAddress() + " at port " + dp.getPort() + " says " + s); // create a datagram packet to send to client DatagramPacket theEcho = new DatagramPacket(buffer,len, cAddr, cPort); ds.send(theEcho); } // end try
… } // end while
20 februari 2006 Client-Server and Multicast Communication 22
Concurrent client sessions with EchoServer1
c lie n t2
m e s s a g e
e ch o
Ech o S e rv e r1 clie n t 1
m e s s a g e
m e s s a g e
m e s s a g e
e ch o
m e s s a g e
e ch o
e ch o
e ch o
20 februari 2006 Client-Server and Multicast Communication 23
Overview Client Server Communication
Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summary References
20 februari 2006 Client-Server and Multicast Communication 24
Connectionless vs. connection-oriented server
A connectionless server – Uses a connectionless IPC API (e.g., connectionless datagram
socket)– Sessions with concurrent clients can be interleaved.
A connection-oriented server – Uses a connection-oriented IPC API (e.g. stream-mode socket )– Sessions with concurrent clients can only be sequential unless the
server is threaded
20 februari 2006 Client-Server and Multicast Communication 25
Connection-Oriented Client-Server applications
In a connection-oriented client-server application:– The server is passive: it listens and waits for connection requests from
clients, and accepts one connection at a time.– A client issues a connection request, and waits for its connection to be
accepted.– Once a server accepts a connection, it waits for a request from the client.
– When a client is connected to the server, it issues a request and waits for the response.
– When a server receives a request, it processes the request and sends a response, then wait for the next request, if any.
– The client receives the response and processes it. If there are further
requests, the process repeats itself.
20 februari 2006 Client-Server and Multicast Communication 26
The Basic Connection-Oriented Client-Server Model
s e rv e r h o s t
s er v ic e
s er v er p r o c es s
A c lien t p r o c es s a t th e h ead o f th e c o n n ec tio n q u eu e
th e s er v er c o n n ec tio n q u eu e
A c lien t p r o c es s th a t is c o n n ec ted to th e s er v er
20 februari 2006 Client-Server and Multicast Communication 27
EchoServer2 (Connection-oriented) excerpt
ServerSocket myConnectionSocket = new ServerSocket(serverPort); while (true) { // forever loop MyStreamSocket myDataSocket = new MyStreamSocket (myConnectionSocket.accept( )); boolean done = false; while (!done) { message = myDataSocket.receiveMessage( ); if ((message.trim()).equals (endMessage)){
myDataSocket.close( ); done = true; } //end if else {
myDataSocket.sendMessage(message); } //end else } //end while !done } //end while forever
20 februari 2006 Client-Server and Multicast Communication 28
Two consecutive client sessions with echo server2
c lie n t2
m e s s a g e
e ch o
Ech o S e rv e r2 clie n t 1
m e s s a g e
m e s s a g e
m e s s a g e
e ch o
m e s s a g e
e ch o
e ch o
e ch o
20 februari 2006 Client-Server and Multicast Communication 29
Overview Client Server Communication
Introduction Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References
20 februari 2006 Client-Server and Multicast Communication 30
Concurrent, Connection-Oriented Server
A connection-oriented server services one client at a time.
If the duration of each client session is significant, then the latency or turnaround time of a client request becomes unacceptable if the number of concurrent client processes is large.
To improve the latency, a server process spawns a child process or child thread to process the protocol for each client. Such a server is termed a concurrent server, compared to an iterative server.
20 februari 2006 Client-Server and Multicast Communication 31
Concurrent, connection-oriented server - 2
A concurrent server uses its main thread to accept connections, and spawns a child thread to process the protocol for each client.
Clients queue for connection, then are served concurrently. The concurrency reduces latency significantly.
s e rv e r h o s t
s erv ic e
c o n c u r r en t s e r v er p r o c es s
A c lien t p r o c es s a t th e h ead o f th e c o n n ec tio n q u eu e
th e s erv er c o n n ec tio n q u eu e
A c lien t p r o c es s w h o s e c o n n ec tio n h as b een ac c ep ted
A c lien t p r o c es s w h o s e c o n n ec tio n h as b een ac c ep ted
th e m ain th r ead ac c ep ts c o n n ec tio n s
a c h ild th r ead p r o c es s esth e p r o to c o l f o r ac lien t p r o c es s
20 februari 2006 Client-Server and Multicast Communication 32
Connection-oriented server: latency analysis
For a given server S, let Tc be the expected time that S takes to accept a connection, Tp be the expected time S takes to process the protocol for a client, N be the expected number of concurrent clients requiring the service of S.
I f S is c o n c u r r en t, th en th e t im e th a t S is o c c u p ied ex c lu s iv e ly b y eac h c lien t isT c . T h e w ait t im e is ( N - 1 ) * T c . An d th e to ta l la ten c y f o r a c lien t is N * T c + T p
I f S is ite r a t iv e , th en th e t im e th a t S is o c c u p ied ex c lu s iv e ly b y eac h c lien t isT c + T p .A c lien t C m u s t w ait u n til th e N - 1 c lien ts ah ead o f it b ef o r e it g e ts th e a tten tio no f S . T h e w ait t im e is ( N - 1 ) * ( T c + T p ) . Af te r w h ic h it tak es T c + T p f o r its o w np r o c es s in g .Hen c e th e to ta l la ten c y f o r a c lien t is N * ( T c + T p )
20 februari 2006 Client-Server and Multicast Communication 33
Connection-oriented Daytime Server
… theServer = new ServerSocket(thePort);
p = new PrintWriter(System.out); try { p.println("Echo Server now in business on port " + thePort ); p.flush(); theConnection = theServer.accept(); // read a line from the client theInputStream = new BufferedReader (new InputStreamReader (theConnection.getInputStream())); p = new PrintWriter(theConnection.getOutputStream()); while (!done){ theLine = theInputStream.readLine(); if (theLine == null) done = true; else{ p.println(theLine); p.flush(); } } theConnection.close();
Protocol processing
Connection acceptance
20 februari 2006 Client-Server and Multicast Communication 34
Connection-oriented Concurrent DayTime Server ConcurrentDaytimeServer.java DaytimeServerThread.java
theServer = new ServerSocket(thePort); p = new PrintWriter(System.out); try { p.println("dayTime Server now in
business on port " + thePort ); p.flush(); while (true) { theConnection = theServer.accept(); daytimeServerThread theThread =
new daytimeServerThread(theConnection);
theThread.start(); } }
public class daytimeServerThread extends Thread { Socket theConnection;
public daytimeServerThread(Socket s) {
theConnection = s; } public void run() { try { PrintWriter p; p = new
PrintWriter(theConnection.getOutputStream()); p.println(new Date()); p.flush(); theConnection.close(); } catch (IOException e) { System.err.println(e); } } // end try} // end thread class
20 februari 2006 Client-Server and Multicast Communication 35
Connection-oriented Echo Server
public class echoServer {
public static void main(String[] args) {
ServerSocket theServer;
int thePort;
Socket theConnection;
PrintWriter p;
BufferedReader theInputStream;
String theLine;
boolean done = false;
…
theServer = new ServerSocket(thePort);
p = new PrintWriter(System.out);
try { theConnection = theServer.accept(); // read a line from the client theInputStream = new BufferedReader (new InputStreamReader
(theConnection.getInputStream()));
p = new PrintWriter(theConnection.getOutputStream());
while (!done){ theLine = theInputStream.readLine(); if (theLine == null) done = true; else { p.println(theLine); p.flush(); } // end if } //end while theConnection.close(); } // end try …
20 februari 2006 Client-Server and Multicast Communication 36
Sequence diagram – EchoServer3
ac c ep tc o n n ec tio n
E c h o Se r v e r 3
E c h o Se r v e r 3 t h r e a d 1
E c h o Se r v e r 3 t h r e a d 2
E c h o C lie n t 1E c h o C lie n t 2
20 februari 2006 Client-Server and Multicast Communication 37
Server Thread class template
class ServerThread implements Runnable { static final String endMessage = "."; MyStreamSocket myDataSocket; ServerThread(MyStreamSocket myDataSocket) { this.myDataSocket = myDataSocket; } public void run( ) { boolean done = false; String message; try { //add code here }// end try catch (Exception ex) { System.out.println("Exception caught in thread: " + ex); } } //end run} //end class
20 februari 2006 Client-Server and Multicast Communication 38
Concurrent Echo Server
See ConcurrentEchoServer.java
See EchoServerThread.java
20 februari 2006 Client-Server and Multicast Communication 39
Overview Client Server Communication
Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summary References
20 februari 2006 Client-Server and Multicast Communication 40
Stateful vs. stateless server
In actual implementation, a server may be– Stateless– Stateful– A hybrid, wherein the state data is distributed on both the
server-side and the client-side.
Which type of server is chosen is a design issue.
20 februari 2006 Client-Server and Multicast Communication 41
Stateful server
A stateful server maintains stateful information on each active client. Stateful information can reduce the data exchanged, and thereby the response
time.
...
s en d < f ile I D > , b lo c k 0
G E T f ile n am e
f ile I D
d ata f r o m b lo c k 0 o f f ile
s en d < f ile I D > , b lo c k 1
d a ta f r o m b lo c k 1 o f f ile
f ile I D
f ile p o sit io n
FTP s e r ve r
FTP C l i e n t
...
s en d n ex t b lo c k
G E T f ile n am e
r ead y
d ata f r o m b lo c k 0 o f f ile
s en d n ex t b lo c k
f ile I D f ile p o sit io n
FTP s e r ve r
FTP C l i e n t
d ata f r o m b lo c k 1 o f f ile
20 februari 2006 Client-Server and Multicast Communication 42
Stateful vs. Stateless server
Stateless server is straightforward to code. Stateful server is harder to code, but the state information maintained by the
server can reduce the data exchanged, and allows enhancements to a basic service.
Maintaining stateful information is difficult in the presence of failures.
...
s en d n ex t b lo c k
G ET f ile n am e
r ead y
d ata f r o m b lo c k 0 o f f ile
s en d n ex t b lo c k
f ile I D f ile p o sit io n
FTP s e r ve r
FTP C l i e n t
d ata f r o m b lo c k 1 o f f ile
d a ta is lo s t d u e to n e tw o r k f a ilu r e
c lien t r ec e iv es d a ta as b lo c k 0 o f f ile ;th e tr u e b lo c k 0 is m is s ed .
c lien t r es u b m its r eq u es t
20 februari 2006 Client-Server and Multicast Communication 43
State Data Storage
State data can be stored in a local variable in the run method of each thread. When each client is serviced by a separate thread, a local variable suffices as a storage for the state data.
Using local variables in a thread to store session state data is adequate for a network service server.
In complex network applications such as shopping carts, more complex mechanisms are needed for state data storage.
20 februari 2006 Client-Server and Multicast Communication 44
Overview Client Server Communication
Introduction Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References
20 februari 2006 Client-Server and Multicast Communication 45
A client can contact multiple servers
A process may require the service of multiple servers. For example, it may obtain a timestamp from a daytime server, data from a database server, and a file from a file server.
S 1 S 2 S 3
C lien t
20 februari 2006 Client-Server and Multicast Communication 46
Middleware
A process can serve as a intermediary, or middleware, between a client and a server.
S er v er
S er v er /C lien t
C lien t
20 februari 2006 Client-Server and Multicast Communication 47
Designing a Network Service
Because of its inherent complexity, network software is notoriously difficult to test.
Use the three-layered software architecture and modularize each layer on both the client and the server sides.
Use an incremental or stepwise approach in developing each module. Starting with stubs for each method, compile and test a module each time after you put in additional details.
Develop the client first. It is sometimes useful to employ an Echo server (to be introduced in the next section) which is known to be correct and which uses a compatible IPC mechanism to test the client independent of the server; doing so allows you to develop the client independent of the server.
Use diagnostic messages throughout each program to report the progress of the program during runtime.
Test the client-server suite on one machine before running the programs on separate machine.
20 februari 2006 Client-Server and Multicast Communication 48
Summary
You have been introduced to the client-server paradigm in distributed computing.
Topics covered include: The difference between the client-server system architecture and the client-server
distributed computing paradigm. Definition of the paradigm and why it is widely adopted in network services and
network applications. The issues of service sessions, protocols, service location, interprocess
communications, data representation, and event synchronization in the context of the client-server paradigm.
The three-tier software architecture of network applications: Presentation logic, application logic, and service logic.
Connectionless server versus connection-oriented server. Iterative server versus concurrent server and the effect on a client session. Stateful server versus stateless server. In the case of a stateful server: global state information versus session state
information.
20 februari 2006 Client-Server and Multicast Communication 49
References & Exercises
Deitel & Deitel“Java How to Program”
SUNJava reference pages java.sun.com
Liu“Distributed Computing - principles and applications”
Fred Halsall“Data communications, computer networks and open systems”
Selfstudy Exercises Chapter 5: Exercises 1, 2, 9, 12.a
20 februari 2006 Client-Server and Multicast Communication 51
Overview Multicast Communication
Chapter 6: Liu
Introduction– Definitions, Applications, Primitives and Characteristics.
Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References
Selfstudy Exercises Chapter 6: Exercises 1, 2
20 februari 2006 Client-Server and Multicast Communication 52
Unicast versus Multicast
sender receiver
One-to-one communication or unicast Group communication or multicast
20 februari 2006 Client-Server and Multicast Communication 53
Multicast
Broadcast is special kind of multicast Multicast applications:
– groupware– online conferences– interactive distance learning– online auction – services for fault tolerance– etc.
20 februari 2006 Client-Server and Multicast Communication 54
Multicast group
A process can join and leave a multicast group. Each process in a group (member) can send and receive messages. A message sent by any process in the group can be received by
each participating process in the group. For multicast operations, a naming scheme is needed to uniquely
identify a multicast group.
Example: online conferencing A group of processes interoperate using multicasting to exchange
audio, video, and/or text data.
In an application or network service which makes use of multicasting, a set of processes form a group, called a multicast group.
20 februari 2006 Client-Server and Multicast Communication 55
An Archetypal Multicast API
Primitive operations: Join – Join a specific multicast group.
– A member is entitled to receive all multicast addressed to the group. – A process is able to be a member of multiple multicast groups.
Send – Send a message to all members currently participating in a multicast group.
Receive –Receive messages sent to a multicast group. Leave – Leave a multicast group.
– This operation allows a member to stop participating in a multicast group. – Disables the reception of any multicast addressed to the left group (The
process may remain a member of other multicast groups).
20 februari 2006 Client-Server and Multicast Communication 56
Some Characteristics of Multicast services (i)
Runtime support of the multicast mechanism is responsible for delivering the message to each member in the multicast group.
As each participating process may reside on a separate host, the delivery of these messages requires the support of mechanisms running independently on those systems.
Due to factors such as failures of network links and/or network hosts, routing delays, and differences in software and hardware, the time between when a unicast message is sent and when it is received may vary among the recipient processes.
20 februari 2006 Client-Server and Multicast Communication 57
Some Characteristics of Multicast services (ii)
A message may not be received by one or more of the processes at all, due to errors and/or failures in the network, the machines, or the runtime support.
Some applications, such as video conferencing, can tolerate an occasional miss or misordering of messages, there are applications – such as database applications – for which such anomalies are unacceptable.
Employing a multicasting mechanism for an application, it is important that you choose one with the characteristics appropriate for your application. (Otherwise, you have to do it yourself !)
Some Characteristics of Multicast services (ii)
20 februari 2006 Client-Server and Multicast Communication 58
Classification of multicasting mechanisms (in terms of message delivery) (i)
Unreliable multicast: will make a good-faith attempt to deliver messages to
each participating process Arrival of the correct message at each process is not
guaranteed. Message sent by a process may be received by zero or
more processes. Messages can be received unordered.
20 februari 2006 Client-Server and Multicast Communication 59
Overview Multicast Communication
Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summery References
20 februari 2006 Client-Server and Multicast Communication 60
Classification of multicasting mechanisms (in terms of message delivery) (ii)
Reliable multicast: Guarantees that each message is eventually delivered to
each member. All messages will be delivered in a non-corrupted form
to all members. Only once delivered. No guarantees on ordering.
Unordered, FIFO, Causal, Atomic, …
20 februari 2006 Client-Server and Multicast Communication 61
Classification of reliable multicast – 1: unordered
Unordered multicast Safe delivery of each message No guarantee on the delivery order of the messages.
Example:- Processes P1, P2, and P3 have formed a multicast group and three messages, m1, m2, m3 have been sent to the group.- Delivery: 3! = 6 permutations (m1-m2-m3, m1-m3-m2, m2-m1-m3, m2-m3-m1, m3-m1-m2, m3-m2-m1 )- Note that it is possible for each participant to receive the messages in an order different from the orders of messages delivered to other participants.
20 februari 2006 Client-Server and Multicast Communication 62
Classification of reliable multicast – 2: FIFO
FIFO multicastGuarantees that the delivery of the messages is in FIFO (first-in-first-out) order or send-order multicast.
Example:
Suppose P1 sends messages m1, m2, and m3 in order, then
each process in the group is guaranteed to have those messages delivered in that same order: m1, m2, then m3.
20 februari 2006 Client-Server and Multicast Communication 63
A Note on FIFO multicast
Note that FIFO multicast places no restriction on the delivery order among messages sent by different processes. To illustrate the point, let us use a simplified example of a multicast group of two processes: P1 and P2. Suppose P1 sends messages m11 then m12, while P2 sends messages m21 then m22. Then delivery examples are:
m11-m12-m21-m22,
m11-m21-m12-m22,
m11-m21-m22-m12,
m21-m11-m12-m22
m21-m11-m22-m12
m21-m22-m11-m12.
20 februari 2006 Client-Server and Multicast Communication 64
Classification of reliable multicast – 3: Causal Order
Causal Order MulticastA multicast system is said to provide causal multicast if its message delivery satisfies the following criterion:
Let mi causes the occurrence of message mj.( mi -> mj ) Messages mi and mj are said to have a causal or happen-before
relationship. Then mi will be delivered to each process prior to mj. The happen-before relationship is transitory: if mi -> mj and mj ->
mk, then mi -> mj -> mk. A causal-order multicast system guarantees that these three
messages will be delivered to each member in the order of mi, mj, then mk.
20 februari 2006 Client-Server and Multicast Communication 65
Causal Order Multicast – example 1
Suppose three processes P1, P2, and P3 are in a multicast group. P1 sends a message m1, to which P2 replies with a multicast
message m2. Since m2 is triggered by m1, the two messages share a causal relationship of m1-> m2.
Suppose the receiving of m2 in turn triggers a multicast message m3 sent by P3, that is, m2-> m3.
Then three messages share the causal relationship of m1-> m2-> m3.
A causal-order multicast message system ensures that these three messages will be delivered to each of the three processes in the order of m1 - m2 - m3.
20 februari 2006 Client-Server and Multicast Communication 66
Causal Order Multicast – example 2
Suppose P1 multicasts message m1, to which P2 replies with a multicast message m2
Independently P3 replies to m1 with a multicast message m3. The three messages now share these causal relationships:
m1 -> m2 and m1 -> m3. A causal-order multicast system can delivery these message in
either of the following orders: m1- m2- m3
m1- m3- m2
Note: It is not possible for the messages to be delivered in any other permutation of the three messages, such as m2- m1- m3 or m3- m1- m2
20 februari 2006 Client-Server and Multicast Communication 67
Classification of reliable multicast – 4: Atomic Order
Atomic order multicast In an atomic-order multicast system, all messages are guaranteed
to be delivered to each participant in the exact same order. Note that the delivery order does not have to be FIFO or causal, but must be identical for each process.
Example:P1 sends m1, P2 sends m2, and P3 sends m3.
An atomic system will guarantee that the messages will be delivered to each process in only one of the six orders:
m1-m2- m3, m1- m3- m2, m2- m1-m3,
m2-m3-m1, m3-m1- m2, m3-m2-m1.
20 februari 2006 Client-Server and Multicast Communication 68
Overview Multicast Communication
Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References
20 februari 2006 Client-Server and Multicast Communication 69
The Java Basic Multicast API
At the transport layer, the basic multicast supported by Java is an extension of UDP (the User Datagram Protocol)
UDP is connectionless and unreliable. Java provides a set of classes which are closely related to
the datagram socket API classes that we looked at in Chapter 3.
20 februari 2006 Client-Server and Multicast Communication 70
The Java Basic Multicast API - 2
There are four major classes in the API, the first three of which we have already seen in the context of datagram sockets.
1. InetAddress: In the datagram socket API, this class represents the IP address of the sender or receiver. In multicasting, this class can be used to identify a multicast group.
2. DatagramPacket: As with datagram sockets, an object of this class represents an actual datagram; in multicast, a DatagramPacket object represents a packet of data sent to all participants or received by each participant in a multicast group.
20 februari 2006 Client-Server and Multicast Communication 71
The Java Basic Multicast API - 3
3. DatagramSocket: In the datagram socket API, this class represents a socket through which a process may send or receive data.
4. MulticastSocket : A MulticastSocket is a DatagramSocket, with additional capabilities for joining and leaving a multicast group. An object of the multicast datagram socket class can be used for sending and receiving IP multicast packets.
20 februari 2006 Client-Server and Multicast Communication 72
IP Multicast addresses
A multicast datagram is meant to be received by all members of a specific multicast group.
Each multicast datagram needs to be addressed to a multicast group instead of an individual member.
The Java multicast API uses the Internet Protocol (IP) multicast addresses for identifying multicast groups.
In IPv4a multicast group is specified by
(i) a class D IP address combined with
(ii) a standard UDP port number.
20 februari 2006 Client-Server and Multicast Communication 73
IP Multicast addresses - 2
Class D IP addresses are those with the prefix bit string of 1110, (224.0.0.0 to 239.255.255.255)
Excluding the four prefix bits, there are 32-4=28 remaining bits, resulting in an address space of 228; that is, approximate 268 million class D addresses are available, although the address 224.0.0.0 is reserved and should not be used by any application.
IPv4 multicast addresses are managed and assigned by the Internet Assigned Numbers Authority (IANA)
20 februari 2006 Client-Server and Multicast Communication 74
IP Multicast addresses - 3
An application which uses the Java multicast API must specifiy at least one multicast address for the application. To select a multicast address for an application, there are the following options:
1. Obtain a permanently assigned static multicast address from IANA: Permanent addresses are limited to global, well-known Internet applications, and their allocations are highly restricted.
2. Choose an arbitrary address, assuming that the combination of the random address and port number is not in use
3. Obtain a transient multicast address at runtime; such an address can be received by an application through the Session Announcement Protocol.
20 februari 2006 Client-Server and Multicast Communication 75
IP Multicast addresses - 4
Examples of assigned addresses:
224.0.0.1 All Systems on this Subnet 224.0.0.11 Mobile-Agents 224.0.1.23 XINGTV
224.0.1.84 jini-announcement224.0.1.85 jini-request 224.0.1.115 Simple Multicast 224.0.6.000-224.0.6.127 Cornell ISIS Project 224.0.7.000-224.0.7.255 Where-Are-You 224.0.8.000-224.0.8.255 INTV 224.0.9.000-224.0.9.255 Invisible Worlds 224.0.12.000-224.0.12.063 Microsoft and MSNBC 224.0.16.000-224.0.16.255 XingNet224.0.18.000-224.0.18.255 Dow Jones 224.0.19.000-224.0.19.063 Walt Disney Company 224.0.22.000-224.0.22.255 WORLD MCAST
224.2.0.0-224.2.127.253 Multimedia Conference Calls
20 februari 2006 Client-Server and Multicast Communication 76
IP Multicast addresses - 5
For our examples and exercises, we will make use of the static address 224.0.0.1, with an equivalent domain name ALL-SYSTEMS.MCAST.NET, for processes running on all machines on the local area network, such as those in your laboratory; alternatively, we may use an arbitrary address that has not been assigned, such as a number in the range of 239.*.*.* (for example, 239.1.2.3).
In the Java API, a MulticastSocket object is bound to a port address such as 3456, and methods of the object allows for the joining and leaving of a multicast address such as 239.1.2.3
20 februari 2006 Client-Server and Multicast Communication 77
Joining a multicast group
To join a multicast group at IP address m and UDP port p,
a MulticastSocket object must be instantiated with p,
then the object’s joinGroup method can be invoked specifying the address m:
// join a Multicast group at IP address 239.1.2.3 and port 3456 InetAddress group =
InetAddress.getByName("239.1.2.3"); MulticastSocket s = new MulticastSocket(3456); s.joinGroup(group);
20 februari 2006 Client-Server and Multicast Communication 78
Sending to a multicast group
A multicast message can be sent using syntax similar with the datagram socket API.
String msg = "This is a multicast message."; InetAddress group =
InetAddress.getByName("239.1.2.3");
MulticastSocket s = new MulticastSocket(3456);
s.joinGroup(group); // optional
DatagramPacket hi = new
DatagramPacket(msg.getBytes( ), msg.length( ),group, 3456);
s.send(hi);
20 februari 2006 Client-Server and Multicast Communication 79
Receiving messages sent to a multicast group
A process that has joined a multicast group may receive messages sent to the group using syntax similar to receiving data using a datagram socket API.
byte[] buf = new byte[1000];
InetAddress group =
InetAddress.getByName("239.1.2.3"); MulticastSocket s = new MulticastSocket(3456); s.joinGroup(group);
DatagramPacket recv =
new DatagramPacket(buf, buf.length);
s.receive(recv);
20 februari 2006 Client-Server and Multicast Communication 80
Leaving a multicast group
A process may leave a multicast group by invoking the leaveGroup method of a MulticastSocket object, specifying the multicast address of the group.
s.leaveGroup(group);
20 februari 2006 Client-Server and Multicast Communication 81
Overview Multicast communication
Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References
20 februari 2006 Client-Server and Multicast Communication 82
Setting the “time-to-live”
The runtime support for a multicast API often employs a technique known as message propagation, whereby a packet is propagated from a host to a neighboring host in an algorithm which, when executed properly, will eventually deliver the message to all the participants.
Under some anomalous circumstances, however, it is possible that the algorithm which controls the propagation does not terminate properly, resulting in a packet circulating in the network indefinitely.
20 februari 2006 Client-Server and Multicast Communication 83
Setting the “time-to-live” - 2
Indefinite message propagation causes unnecessary overhead on the systems and the network.
To avoid this occurrence, it is recommended that a “time to live” parameter be set with each multicast datagram.
The time-to-live (ttl) parameter, when set, limits the count of network links or hops that the packet will be forwarded on the network.
20 februari 2006 Client-Server and Multicast Communication 84
Setting the “time-to-live” - 3
String msg = "Hello everyone!";
InetAddress group = InetAddress.getByName("224.0.0.1"); MulticastSocket s = new MulticastSocket(3456); s.setTimeToLive(1); // set time-to-live to 1 hop – a count
// appropriate for multicasting to local hosts
DatagramPacket hi = new DatagramPacket(msg.getBytes( ), msg.length( ),group, 3456);
s.send(hi);
The value specified for the ttl must be in the range 0 <= ttl <= 255; an IllegalArgumentException will be thrown otherwise.
20 februari 2006 Client-Server and Multicast Communication 85
Setting the “time-to-live” - 4
The recommended ttl settings are:
0 if the multicast is restricted to processes on the same host 1 if the multicast is restricted to processes on the same subnet 32 if the multicast is restricted to processes on the same site 64 if the multicast is restricted to processes on the same region 128 if the multicast is restricted to processes on the same continent 255 if the multicast is unrestricted
20 februari 2006 Client-Server and Multicast Communication 86
Multicast program examples
Example1:– Example1Sender– Example1Receiver
Example2– Example2SenderReceiver– ReadThread
20 februari 2006 Client-Server and Multicast Communication 87
Reliable Multicast API
the Java basic Multicast API provides unreliable multicast
The Java Reliable Multicast Service (JRM Service) provides the capabilities for a receiver to repair multicast data that are lost or damaged, as well as security measures to protect data privacy.
The Totem system, developed by the University of California, Santa Barbara, “provides reliable totally ordered delivery of messages to processes within process groups on a single local-area network, or over multiple local-area networks interconnected by gateways.”
TASC’s Reliable Multicast Framework (RMF) provides reliable and send ordered (FIFO) multicast.
20 februari 2006 Client-Server and Multicast Communication 88
Summary - 1
Unicast vs. multicast. An archetypal multicast API must provide operations for joining, leaving,
sending, and receiving. Basic multicast is connectionless and unreliable; A reliable multicast system ensures delivery. Reliable multicasts can be
further categorized by the order of message delivery they support:Unordered multicast may deliver the messages to each participant in any order.
FIFO multicast preserves the order of messages sent by each host.
Causal multicast preserves causal relationships among the messages.
Atomic multicast delivers the messages to each participant in the same order. IP multicast addressing uses a combination of a Class D address and a UDP port
number. A multicast application may use a static Class D address, a transient address obtained at run time, or an arbitrary unassigned address.
20 februari 2006 Client-Server and Multicast Communication 89
Summary - 2
The Java basic multicast API provides unreliable multicast. A MulticastSocket is created with the specification of a port number. The joinGroup and leaveGroup methods of the MulticastSocket class, a subclass of DatagramSocket, can be invoked to join or leave a specific multicast group; and the send and receive methods can be invoked to send and receive a multicast datagram. The DatagramPacket class is also needed to create the datagrams.
There are existing packages that provide reliable multicast, including the Java Reliable Multicast Service (JRM Service).