20 februari 2006 Client-Server and Multicast Communication 1 René de Vries Based on slides by M.L....

20 februari 2006

Client-Server and Multicast Communication

1


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


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.


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


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 .


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.


Place in the Internet Protocol Stack


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.


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


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).


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.


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.



Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summery References


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


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


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


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


Daytime Protocol Implementation

Sample 1 – using connectionless sockets:

DaytimeServer1.java

DaytimeClient1.java


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.


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


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



Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summary References


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


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.


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


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


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



Introduction Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References


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.


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


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 )


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


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


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 …


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


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


Concurrent Echo Server

See ConcurrentEchoServer.java

See EchoServerThread.java



Introduction Connectionless client-server topology Connection oriënted client-server topology Iterative and concurrent servers Stateful and Stateless servers Notes and Summary References


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.


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



f ile I D f ile p o sit io n

FTP s e r ve r

FTP C l i e n t



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.

...


G ET f ile n am e

r ead y



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 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


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.



Introduction Connectionless client-server topology Connection oriënted client-server topology Concurrent servers Stateful and Stateless servers Notes and Summary References


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


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


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.


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.


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


50

Multicast Communication


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


Unicast versus Multicast

sender receiver

One-to-one communication or unicast Group communication or multicast


Multicast

Broadcast is special kind of multicast Multicast applications:

– groupware– online conferences– interactive distance learning– online auction – services for fault tolerance– etc.


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.


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).


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.


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)


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.



Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summery References


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, …


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.


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.


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.


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.


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.


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


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.



Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References


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.


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.


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.


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.


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)



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.



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



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


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);


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);


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);


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);


Overview Multicast communication

Introduction Classification of Multicast services Programming the JAVA multicast API Remarks and Summary References


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.


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.



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.



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


Multicast program examples

Example1:– Example1Sender– Example1Receiver

Example2– Example2SenderReceiver– ReadThread


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.


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.


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 1 René de Vries Based on slides by M.L....

Documents

Transcript of 20 februari 2006 Client-Server and Multicast Communication 1 René de Vries Based on slides by M.L....