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
1
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
2
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
3
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.
Server host
service request
a client process
a server process
a service
Client host
...

The Client-Server Paradigm, conceptual
20 februari 2006
Client-Server and Multicast Communication
4
Client-server, an overloaded term
client hosts
service request
a client process
a server process
server host
Server host
a service
...
...
Client host
The Client-Server Paradigm, conceptual
Client-Server Computing Paradigm
Client-Server System Architecture
Client hosts make use of services
provided on a server host.
20 februari 2006
Client processes (objects) make use of a service
provided by a server process (object) running on
a server host.
Client-Server and Multicast Communication
5
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 clientserver paradigm.
20 februari 2006
Client-Server and Multicast Communication
6
Place in the Internet Protocol Stack
20 februari 2006
Client-Server and Multicast Communication
7
20 februari 2006
Client-Server and Multicast Communication
8
A service session
A Session is an
interaction between the
server and one client.
start service
accept a client's
request for a session
conduct a session
with the client
20 februari 2006
Client-Server and Multicast Communication
9
The interprocess communications
and event synchronization
client

Typically, the
interaction of the client
and server processes
follows a requestresponse pattern.
server
request1
response 1
request2
response 2
requestn
response n
20 februari 2006
Client-Server and Multicast Communication
10
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
11
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.
ii.
iii.

how the service is to be located
the sequence of interprocess communication (dynamics)
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
12
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
13
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
14
Connectionless Server
A connectionless server accepts one request at a time
from any client, processes the request, and sends the
response to the requestor.
Connectionless Server
Clients
a request
a response
20 februari 2006
Client-Server and Multicast Communication
15
Software Engineering for a Network Service
client-side software
presentation logic
application logic
service logic
20 februari 2006
server-side software
application logic
service logic
Client-Server and Multicast Communication
16
Example protocol: daytime
Defined in RFC867
server
client
m
sequence diagram
data representation: text (character strings)
data format:
m : contains a timestamp, in a format such as
Wed Jan 30 09:52:48 2002
20 februari 2006
Client-Server and Multicast Communication
17
Daytime Protocol
client
server
m1
m2
sequence diagram
data representation: text (character strings)
data format:
m1; a null message - contents will be ignored.
m2 : contains a timestamp, in a format such as
Wed Jan 30 09:52:48 2002
20 februari 2006
Client-Server and Multicast Communication
18
Daytime Protocol Implementation
Sample 1 – using connectionless sockets:
DaytimeServer1.java
DaytimeClient1.java
20 februari 2006
Client-Server and Multicast Communication
19
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
20
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
21
Concurrent client sessions with EchoServer1
EchoServer1
client 1
client2
message
echo
message
echo
message
echo
message
echo
message
echo
20 februari 2006
Client-Server and Multicast Communication
22
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
23
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
24
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
25
The Basic Connection-Oriented Client-Server
Model
A client process at the head of the connection queue
server host
server process
the server connection queue
service
A client process that is connected to the server
20 februari 2006
Client-Server and Multicast Communication
26
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
27
Two consecutive client sessions with echo server2
EchoServer2
client 1
client2
message
echo
message
echo
message
echo
message
echo
message
echo
20 februari 2006
Client-Server and Multicast Communication
28
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
29
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
30
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.
A client process at the head of the connection queue
server host
concurrent server
process
the server connection queue
service
the main thread accepts connections
a child thread processes
the protocol for a
client process
A client process whose connection has been accepted
A client process whose connection has been accepted
20 februari 2006
Client-Server and Multicast Communication
31
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.
If S is iterative, then the time that S is occupied exclusively by each client is
Tc + Tp.
A client C must wait until the N-1 clients ahead of it before it gets the attention
of S. The wait time is (N-1)*(Tc+Tp). After which it takes Tc+Tp for its own
processing.
Hence the total latency for a client is N*(Tc+Tp)
If S is concurrent, then the time that S is occupied exclusively by each client is
Tc. The wait time is (N-1)*Tc. And the total latency for a client is N*Tc+Tp
20 februari 2006
Client-Server and Multicast Communication
32
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();
Connection
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();
20 februari 2006
acceptance
Protocol processing
Client-Server and Multicast Communication
33
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();
}
}
20 februari 2006
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
Client-Server and Multicast Communication
34
Connection-oriented Echo Server
try {
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);
20 februari 2006
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
… and Multicast Communication
Client-Server
35
Sequence diagram – EchoServer3
EchoServer3
EchoClient 1
EchoClient2
EchoServer3
thread 1
EchoServer3
thread 2
accept
connection
20 februari 2006
Client-Server and Multicast Communication
36
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
37
Concurrent Echo Server
See ConcurrentEchoServer.java
See EchoServerThread.java
20 februari 2006
Client-Server and Multicast Communication
38
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
39
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
40
Stateful server


A stateful server maintains stateful information on each active client.
Stateful information can reduce the data exchanged, and thereby the response
time.
FTP se rve r
FTP se rve r
FTP C l i e nt
FTP C l i e nt
file ID
file ID file posit ion
file posit ion
GET file name
file ID
send <file ID>, block 0
data from block 0 of file
send <file ID>, block 1
data from block 1 of file
...
20 februari 2006
GET file name
ready
send next block
data from block 0 of file
send next block
data from block 1 of file
...
Client-Server and Multicast Communication
41
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.
FTP se rve r
FTP C lie nt
file ID file position
GET file name
ready
send next block
data from block 0 of file
send next block
data from block 1 of file
...
20 februari 2006
data is lost due to network failure
client resubmits request
client receives data as block 0 of file;
the true block 0 is missed.
Client-Server and Multicast Communication
42
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
43
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
44
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.
S1
S2
S3
Client
20 februari 2006
Client-Server and Multicast Communication
45
Middleware
A process can serve as a intermediary, or middleware,
between a client and a server.
Server
Server/Client
Client
20 februari 2006
Client-Server and Multicast Communication
46
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
47
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
48
References & Exercises




Deitel & Deitel
“Java How to Program”
SUN
Java 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
49
Multicast Communication
20 februari 2006
Client-Server and Multicast
Communication
50
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
51
Unicast versus Multicast
sender
receiver
One-to-one communication or unicast
20 februari 2006
Group communication or multicast
Client-Server and Multicast Communication
52
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
53
Multicast group
In an application or network service which makes use of multicasting,
a set of processes form a group, called a 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.
20 februari 2006
Client-Server and Multicast Communication
54
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
55
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
56
Some Characteristics of Multicast services (ii)
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 !)
20 februari 2006
Client-Server and Multicast Communication
57
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
58
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
59
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
60
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
61
Classification of reliable multicast – 2: FIFO
FIFO multicast
Guarantees 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
62
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
63
Classification of reliable multicast – 3: Causal Order
Causal Order Multicast
A 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
64
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
65
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
66
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
67
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
68
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
69
The Java Basic Multicast API - 2
1.
2.
There are four major classes in the API, the first three
of which we have already seen in the context of
datagram sockets.
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.
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
70
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
71
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
72
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
73
IP Multicast addresses - 3
1.
2.
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:
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.
Choose an arbitrary address, assuming that the
combination of the random address and port number is not
in use
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
74
IP Multicast addresses - 4
Examples of assigned addresses:
224.0.0.1
224.0.0.11
224.0.1.84
224.0.1.85
224.0.1.115
224.0.6.000-224.0.6.127
224.0.7.000-224.0.7.255
224.0.8.000-224.0.8.255
224.0.9.000-224.0.9.255
224.0.12.000-224.0.12.063
224.0.16.000-224.0.16.255
224.0.18.000-224.0.18.255
224.0.19.000-224.0.19.063
224.0.22.000-224.0.22.255
224.2.0.0-224.2.127.253
20 februari 2006
All Systems on this Subnet
Mobile-Agents 224.0.1.23 XINGTV
jini-announcement
jini-request
Simple Multicast
Cornell ISIS Project
Where-Are-You
INTV
Invisible Worlds
Microsoft and MSNBC
XingNet
Dow Jones
Walt Disney Company
WORLD MCAST
Multimedia Conference Calls
Client-Server and Multicast Communication
75
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
76
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
77
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
78
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
79
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
80
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
81
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
82
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
83
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
84
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
85
Multicast program examples

Example1:
–
–

Example1Sender
Example1Receiver
Example2
–
–
Example2SenderReceiver
ReadThread
20 februari 2006
Client-Server and Multicast Communication
86
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
87
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
88
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).
20 februari 2006
Client-Server and Multicast Communication
89