cs2307_mnl

http://francisxavier.ac.in

FRANCIS XAVIER ENGINEERING COLLEGE

TIRUNELVELI – 627003

[ISO 9001: 2008 CERTIFIED INSTITUTION]

DEPARTMENT OF COMPUTER SCIENCEAND ENGINEERING

Year : 2014 – 2015 (ODD SEM)

Semester : V

PREPARED BY

J. DOULAS, AP/CSE

S.U.SOWMIYA, AP/CSE

CS 2307 – NETWORKS LAB


INDEX

EX.No Date Name of the Experiment Marks Sigmature

1. Implementation of ECHO Server using

Socket Programming

2. Implementation of Socket Programming

using UDP

3. Implementation of Socket programming

using TCP

4. Program for Remote Procedure Call using

Remote Command Execution

5.

Implementation of RMI

6. Simulation of Sliding window Protocols

7.

Implementation of ARP

8. Implementation of RARP

9a.

Study of Network Simulator-NS 2

9b.

Network Simulator Glomosim

10.

Simulation of Dynamic Routing Protocol


Ex. No.1

Date:

IMPLEMENTATION OF ECHO SERVER USING

SOCKET PROGRAMMMING

Abstract:

The Echo server simply receives data from its client and echoes it back. The Echo server

is a well-known service that clients can rendezvous with on port 7.EchoClient creates a socket

thereby getting a connection to the Echo server. It reads input from the user on the standard input

stream, and then forwards that text to the Echo server by writing the text to the socket. The

server echoes the input back through the socket to the client. The client program reads and

displays the data passed back to it from the server:

Aim:

To implement the echo server using Socket Programming.

Algorithm:

1.Create two programs one for the server side and one for the client side

2.In the server side, create a server socket.

3.The return value of the accept() method is assigned to a new socket created.

4.Send the input received from the client at the server side back to the client.

5.In the client side, create a socket to connect to the server.

6.Create the object of DataInputStream to accept input from the server

7.Display the input received from the server.

8.Type ―quit‖ at the client side to finish execution of both the programs.

9.Stop.


PROGRAM:

ECHOSERVER:

import java.io.*;

import java.net.*; public class echoserver {

public static void main(String args[])throws IOException {

ServerSocket ss=new ServerSocket(500); Socket s=ss.accept(); System.out.println("Server is ready");

DataInputStream dis=new DataInputStream(s.getInputStream()); PrintStream p=new PrintStream(s.getOutputStream());

while(true) { String t=dis.readLine();

if(t==null) break;

System.out.println(t); p.println(t); }

} }


PROGRAM:

ECHO CLIENT:

import java.io.*;

import java.net.*; public class echoclient {


InetAddress obj=InetAddress.getLocalHost(); Socket s=new Socket(obj,500); DataInputStream dis=new DataInputStream(s.getInputStream());

PrintStream p=new PrintStream(s.getOutputStream()); System.out.println("TYPE YOUR MESSAGE TO SERVER AND TYPE QIUT

TO EXIT"); while(true) {

String t=new DataInputStream(System.in).readLine(); if(t.equals("quit"))

{ p.close(); System.exit(0);

} else

{ p.println(t); t=dis.readLine();

System.out.println(t); }

} } }


OUTPUT:

ECHO SERVER:

C:\Documents and settings\STUDENT> d:

D:\>cd D:\jdk1.6.0\bin

D:\jdk1.6.0\bin>javac echoserver.java

Note: echoserver.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java echoserver

Server is ready A MESSAGE FROM CLIENT TO SERVER

D:\jdk1.6.0\bin>

ECHO CLIENT:



D:\jdk1.6.0\bin>javac echoclient.java

Note: echoclient.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java echoclient

TYPE YOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT A MESSAGE FROM CLIENT TO SERVER

A MESSAGE FROM CLIENT TO SERVER

quit

D:\jdk1.6.0\bin>


OUTPUT:

ECHO SERVER: C:\Documents and settings\STUDENT> d:





Server is ready CLIENT TO SERVER

D:\jdk1.6.0\bin>

ECHO CLIENT: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac echoclient.java Note: echoclient.java uses or overrides a deprecated API.

Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java echoclient TYPE YOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT

CLIENT TO SERVER

CLIENT TO SERVER

Quit

D:\jdk1.6.0\bin>


OUTPUT:

ECHO SERVER:






Server is ready MESSAGE

D:\jdk1.6.0\bin>

ECHO CLIENT:



D:\jdk1.6.0\bin>javac echoclient.java

Note: echoclient.java uses or overrides a deprecated API.

Note: Recompile with -deprecation for details. D:\jdk1.6.0\bin>java echoclient

TYPE YOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT

MESSAGE

MESSAGE

Quit D:\jdk1.6.0\bin>


RESULT

Thus the java program to implement the echo server using Socket Programming was

written and executed successfully.


Ex. No.2

Date:

Implementation of Socket Programming using UDP.

Abstract:

The User Datagram Protocol (UDP) is one of the core members of the Internet protocol

suite. With UDP, computer applications can send messages, in this case referred to as datagrams,

to other hosts on an Internet Protocol(IP) network without prior communications to set up special

transmission channels or data paths.UDP uses a simple transmission model with a minimum of

protocol mechanism.It has no handshaking dialogues.

Aim:

To implement socket programming using UDP.

Algorithm:

1.Create two programs one for the server side(udpserver.java) and one for the client

side(udpclient.java).

2.Create an instance of Datagramsocket and an instance of Datagram packet in the server.

3.Receive the packet from the client using Datagram socket’s receive method.

4.Get data from the Datagram packet and print it.

5.Get the message using getBytes() to send to client.

6.Send the packet to the client side using Datagram Socket’s send command.

7.At the client first the packet is sent and then received using Datagram Socket’s send

and receive method after creation of an instance of Datagram socket.

8.A message ―quit‖ is sent from the client to end both the sessions.


PROGRAM:

UDPSERVER:

import java.io.*; import java.net.*;

public class udpserver {

public static void main(String args[])throws IOException { InetAddress obj=InetAddress.getLocalHost();

DatagramSocket ds=new DatagramSocket(600); System.out.println("Server is ready");

DataInputStream dis=new DataInputStream(System.in); while(true) {

byte c[]=new byte[100]; DatagramPacket dp2=new DatagramPacket(c,c.length);

ds.receive(dp2); String t=new String(dp2.getData()); if(t.trim().toLowerCase().equals("quit"))

{ ds.close();

dis.close(); System.exit(0); }

else {

for(int i=0;i<dp2.getLength();i++) System.out.print((char)dp2.getData()[i]); System.out.println();

t=dis.readLine(); byte b[]=t.getBytes();

DatagramPacket dp1=new DatagramPacket(b,b.length,obj,200); ds.send(dp1); }

} }

}


PROGRAM:

UDP CLIENT: import java.io.*;

import java.net.*; public class udpclient {


InetAddress obj=InetAddress.getLocalHost(); DatagramSocket ds=new DatagramSocket(200); DataInputStream dis=new DataInputStream(System.in);

System.out.println("TYPE YOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT");

while(true) { String t=dis.readLine();

if(t.equals("quit")) {

byte c[]=t.getBytes(); DatagramPacket dp2=new DatagramPacket(c,c.length,obj,600); ds.send(dp2);

ds.close(); dis.close();

System.exit(0); } else

{ byte c[]=t.getBytes();

DatagramPacket dp2=new DatagramPacket(c,c.length,obj,600); ds.send(dp2); }

byte b[]=new byte[100]; DatagramPacket dp1=new DatagramPacket(b,b.length);

ds.receive(dp1); for(int i=0;i<dp1.getLength();i++) System.out.println((char)dp1.getData()[i]);

System.out.println(); }

} }


OUTPUT:

UDP SERVER: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac udpserver.java

Note: udpserver.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java udpserver

Server is ready S

E R

V E R

Quit

D:\jdk1.6.0\bin>

UDP CLIENT: C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin D:\jdk1.6.0\bin>javac udpclient.java

Note: udpclient.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java udpclient

TYPE YOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT SERVER

q u

i t

quit

D:\jdk1.6.0\bin>


OUTPUT:

UDP SERVER:




Note: udpserver.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java udpserver

Server is ready

o

u t

quit

UDP CLIENT: C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin

D:\jdk1.6.0\bin>javac udpclient.java

Note: udpclient.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.



out q

u i t

quit

D:\jdk1.6.0\bin>


OUTPUT:

UDP SERVER:

C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin


Note: udpserver.java uses or overrides a deprecated API.


D:\jdk1.6.0\bin>java udpserver Server is ready

f r

o m

quit

UDP CLIENT: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac udpclient.java Note: udpclient.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.



from

q u i

t quit

D:\jdk1.6.0\bin>


RESULT

Thus the java program to implement socket programming using UDP was written and executed successfully.


Ex. No.3

Date:

Implementation of Socket Programming using TCP

Abstract:

The Transmission Control Protocol (TCP) is one of the core protocols of the Internet

protocol suite (IP), and is so common that the entire suite is often called TCP/IP. TCP provides

reliable, ordered, error-checked delivery of a stream of octets between programs running on

computers connected to a local area network, intranet or the public Internet. It resides at the

transport layer. TCP provides a connection oriented service, since it is based on connections

between clients and servers. TCP provides reliability. When a TCP client send data to the server,

it requires an acknowledgement in return. If an acknowledgement is not received, TCP

automatically retransmit the data and waits for a longer period of time.

TCP is instead a byte-stream protocol, without any boundaries at all.

Aim:

To implement socket programming using TCP/IP.

Algorithm:

1.Create two programs one for the server side(tcpserver.java) and one for the client

side(tcpclient.java).

2.In the server side, create a server socket.

3.The return value of accept is assigned to a new socket created.

4.Create the object of DataInputStream to accept input from the client.

5.Display the input received from the client.

6.In the client side, create a socket to connect to the server.

7.Create the object of DataInputStream to accept input from the server.

8.Display the input received from the server.

9.Type ―quit‖ at the client side to finish execution of both the programs.

10.Stop.


PROGRAM:

TCP CLIENT: import java.io.*;

import java.net.*; public class tcpclient {

public static void main(String args[]) throws IOException {

InetAddress obj=InetAddress.getLocalHost(); Socket s=new Socket(obj,500); DataInputStream dis=new DataInputStream(s.getInputStream());

PrintStream p=new PrintStream(s.getOutputStream()); System.out.println("TYPE TOUR MESSAGE TO SERVER AND TYPE QUIT

TO EXIT.."); while(true) {

String t=new DataInputStream(System.in).readLine(); if(t.equals("quit"))

{ p.close(); System.exit(0);

} else

{ p.println(t); t=dis.readLine();

System.out.println(t); }

} } }


PROGRAM:

TCP SERVER:

import java.io.*; import java.net.*; public class tcpserver

{ public static void main(String args[]) throws IOException

{ ServerSocket ss=new ServerSocket(500); Socket s=ss.accept();

System.out.println("SERVER IS READY..."); DataInputStream dis=new DataInputStream(s.getInputStream());

PrintStream p=new PrintStream(s.getOutputStream()); while(true) {

String t=dis.readLine(); if(t==null)

break; System.out.println(t); t=new DataInputStream(System.in).readLine();

p.println(t); }

} }


OUTPUT:

TCP SERVER:



D:\jdk1.6.0\bin>javac tcpserver.java

Note: tcpserver.java uses or overrides a deprecated API.

Note: Recompile with -deprecation for details. D:\jdk1.6.0\bin>java tcpserver

SERVER IS READY...

A MESSAGE FROM TCP CLIENT TO TCPSERVER...

A REPLY MESSAGE FROM TCP SERVER TO TCP CLIENT: SERVER GOT THE MESSAGE AND STARTED PROCESSING

D:\jdk1.6.0\bin>

TCP CLIENT:


D:\jdk1.6.0\bin>javac tcpclient.java

Note: tcpclient.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java tcpclient

TYPE TOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT.. A MESSAGE FROM TCP CLIENT TO TCPSERVER...

A REPLY MESSAGE FROM TCP SERVER TO TCP CLIENT: SERVER GOT THE MESSAGE AND STARTED PROCESSING

Quit

D:\jdk1.6.0\bin>


OUTPUT:

TCP SERVER: C:\Documents and settings\STUDENT> d:



Note: tcpserver.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java tcpserver

SERVER IS READY... Computer

Network

D:\jdk1.6.0\bin>

TCP CLIENT: C:\Documents and settings\STUDENT> d:





TYPE TOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT.. Computer

Network

Quit

D:\jdk1.6.0\bin>


OUTPUT:

TCP SERVER:




Note: tcpserver.java uses or overrides a deprecated API.

Note: Recompile with -deprecation for details. D:\jdk1.6.0\bin>java tcpserver

SERVER IS READY...

Server

Ready

D:\jdk1.6.0\bin>

TCP CLIENT: C:\Documents and settings\STUDENT> d:





TYPE TOUR MESSAGE TO SERVER AND TYPE QUIT TO EXIT.. Server

Ready

Quit

D:\jdk1.6.0\bin>


RESULT

Thus the java program to implement socket programming using TCP/IP was written and executed successfully.


Ex. No.4

Date:

Program for Remote Procedure Call using Remote Command

Execution

Abstract:

RPC is a powerful technique for constructing distributed, client-server based applications.

It is based on extending the notion of conventional, or local procedure calling, so that the called

procedure need not exist in the same address space as the calling procedure. The two processes

may be on the same system, or they may be on different systems with a network connecting

them. By using RPC, programmers of distributed applications avoid the details of the interface

with the network. The transport independence of RPC isolates the applicatio n from the physical

and logical elements of the data communications mechanism and allows the application to use a

variety of transports. An RPC is analogous to a function call. Like a function call, when an RPC

is made, the calling arguments are passed to the remote procedure and the caller waits for a

response to be returned from the remote procedure. The client makes a procedure call that sends

a request to the server and waits. The thread is blocked from processing until either a reply is

received, or it times out. When the request arrives, the server calls a dispatch routine that

performs the requested service, and sends the reply to the client. After the RPC call is completed,

the client program continues. RPC specifically supports network applications.

Aim:

To create a program for Remote Procedure Call

Algorithm:

1.Start.

2.Create a server socket at the server side.

3.Create a socket at the client side and the connection is set to accept by the server socket

using the accept() method.

4.In the client side the command to be executed is given as input.

5.The command is obtained using the readLine() method of Buffer Reader.

6.Get the runtime object of the runtime class using getruntime().

7.Execute the command using the exec() method of runtime.

8.stop.


PROGRAM:

RCSERVER: import java.net.*;

import java.io.*; class rcserver {

public static final int port=8086; public static void main(String args[])throws IOException

{ ServerSocket s=new ServerSocket(port); Runtime r=Runtime.getRuntime();

System.out.println("started"+s); try

{ Socket ser=s.accept(); try

{ System.out.println("connection started"+ser);

BufferedReader in=new BufferedReader(new InputStreamReader(ser.getInputStream())); PrintWriter out=new PrintWriter(new BufferedWriter(new

OutputStreamWriter(ser.getOutputStream())),true); String str=in.readLine();

out.println(str); Process p=r.exec(str); }

finally {

System.out.println("closing"); ser.close(); }

} finally

{ s.close(); }

} }


PROGRAM:

RCCLIENT: import java.net.*;

import java.io.*; class rcclient {


InetAddress adr=InetAddress.getLocalHost(); System.out.println("adr="+adr); Socket ser=new Socket(adr,8086);

try {

System.out.println("ser"+ser); BufferedReader in=new BufferedReader(new InputStreamReader(System.in)); PrintWriter pw=new PrintWriter(new BufferedWriter(new

OutputStreamWriter(ser.getOutputStream())),true); System.out.println("Enter a command to be executed remotely");

String str=in.readLine(); pw.println(str); }

finally {

System.out.println("closing"); ser.close(); }

} }


OUTPUT:

RCSERVER:


D:\jdk1.6.0\bin>javac rcserver.java

D:\jdk1.6.0\bin>java rcserver

startedServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8086]

connection startedSocket[addr=LAB3-13/10.0.3.26,port=1059,localport=8086] closing

RCCLIENT: C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin

D:\jdk1.6.0\bin>javac rcclient.java

D:\jdk1.6.0\bin>java rcclient

adr=lab3-13/10.0.3.26

serSocket[addr=lab3-13/10.0.3.26,port=8086,localport=1059] Enter a command to be executed remotely

notepad

closing


OUTPUT:

RCSERVER:



D:\jdk1.6.0\bin>javac rcserver.java

D:\jdk1.6.0\bin>java rcserver


connection startedSocket[addr=LAB3-13/10.0.3.26,port=1059,localport=8086]

closing

RCCLIENT: C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin

D:\jdk1.6.0\bin>javac rcclient.java

D:\jdk1.6.0\bin>java rcclient

adr=lab3-13/10.0.3.26

serSocket[addr=lab3-13/10.0.3.26,port=8086,localport=1059] Enter a command to be executed remotely

notepad

closing


OUTPUT:

RCSERVER: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac rcserver.java D:\jdk1.6.0\bin>java rcserver


connection startedSocket[addr=LAB3-13/10.0.3.26,port=1059,localport=8086]

closing

RCCLIENT: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac rcclient.java D:\jdk1.6.0\bin>java rcclient

adr=lab3-13/10.0.3.26

serSocket[addr=lab3-13/10.0.3.26,port=8086,localport=1059]

Enter a command to be executed remotely

calc closing


RESULT Thus the java program to implement Remote Procedure Call using Remote Command

Execution was written and executed successfully.


Ex. No.5

Date:

Implementation of RMI

Abstract:

Remote Method Invocation (RMI) is a Java technology in which an object running in

Java Virtual Machine (JVM) could be invoked from another object running in a different JVM.

The technology provides a remote access of objects in Java programming language. The RMI

technology consists of a server and a client. The server usually creates remote objects and binds

these objects to the rmiregistry allowing the objects to be accessed remotely. The client would

connect to the server and get one or more remote reference and then invoke the methods on the

remote objects. The RMI technology wraps the underlying communication and hence the

developer only needs to code the business logic, instead of worrying about the communication

between the client and the server.Remote objects are objects that could be called across JVMs.

An object becomes remote by implementing a remote interface. The implemented remote

interface should extend the java.rmi.Remote interface and all the methods declared in the

interface should throw the exception java.rmi.RemoteException.RMI passes a remote stub for a

remote object.

Aim:

To create a program for the implementation of RMI.

Algorithm:

1.Write an interface program with method AddServerIntf that finds the sum of 2 values.

2.Write an Implementation program to define the AddServerIntf with a method

AddServerImpl method.

3.Write a server program rmiserver in which the instance of the implementation is

created.

4.Create a register by issuing the ―start rmiregistry‖ command at the command prompt.

5.Compile using the rmi compiler the implementation program for creation of the stub

and skeleton.

6.Bind the implementation object to the registry and name it.


7.Write a client program in which the inputs of two values are obtained from the

command line and the result is diaplayed.

8.Stop.

PROGRAM:

SERVER: import java.rmi.*;

import java.net.*; public class AddServer

{ public static void main(String args[]) {

try {

AddServerImpl AddServerImpl=new AddServerImpl(); Naming.rebind("AddServer",AddServerImpl); }

catch(Exception e) {

System.out.println("Exception"+e); } }

}


CLIENT:

import java.rmi.*; public class addClient

{ public static void main(String[] args) {

try {

String addserverURL="rmi://"+args[0]+"/addserver"; addserverinf addserverinf=(addserverinf)Naming.lockup(addserverURL); System.out.println("The First Number is="+args[1]);

double d1=Double.valueOf(args[1]).doubleValue(); Sytem.out.println("The Second Number is="+args[2]);

double d2=Double.valueOf(args[2]).doubleValue(); System.out.println("The Sum of the number is ="+addserverinf.add(d1,d2)); }

catch(Exception e) {

System.out.println(e); } }

}

INTERFACE: import java.rmi.*; public interface AddServerIntf extends Remote

{ double add(double d1,double d2)throws RemoteException;

}

IMPLEMENTATION:

import java.rmi.*; import java.rmi.server.*; public class AddServerImpl extends UnicastRemoteObject implements AddServerIntf

{ public AddServerImpl()throws RemoteException

{ }

public double add(double d1,double d2)throws RemoteException {

return d1+d2;


} }

OUTPUT:

AT SERVER SIDE: C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin

D:\jdk1.6.0\bin>javac AddServerIntf.java

D:\jdk1.6.0\bin>javac AddServerImpl.java

D:\jdk1.6.0\bin>rmic AddServerImpl

D:\jdk1.6.0\bin>javac AddServer.java D:\jdk1.6.0\bin>start rmiregistry

D:\jdk1.6.0\bin>java AddServer

AT CLIENT SIDE:


D:\jdk1.6.0\bin>javac AddClient.java

Note: AddClient.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java AddClient

Enter the first number: 12 Enter the second number

232 The sum is244.0


OUTPUT:

AT SERVER SIDE:




D:\jdk1.6.0\bin>javac AddServerImpl.java D:\jdk1.6.0\bin>rmic AddServerImpl

D:\jdk1.6.0\bin>javac AddServer.java

D:\jdk1.6.0\bin>start rmiregistry


AT CLIENT SIDE: C:\Documents and settings\STUDENT> d:




D:\jdk1.6.0\bin>java AddClient Enter the first number:

12 Enter the second number 253

The sum is265.0


OUTPUT:

AT SERVER SIDE:




D:\jdk1.6.0\bin>javac AddServerImpl.java

D:\jdk1.6.0\bin>rmic AddServerImpl D:\jdk1.6.0\bin>javac AddServer.java

D:\jdk1.6.0\bin>start rmiregistry


AT CLIENT SIDE: C:\Documents and settings\STUDENT> d:




D:\jdk1.6.0\bin>java AddClient Enter the first number:

72 Enter the second number

132 The sum is204.0


RESULT Thus the java program to create a program for the implementation of RMI was written and executed successfully.


Ex. No.6

Date:

Simulation of Sliding Window Protocols.

Abstract:

A sliding window protocol is a feature of packet-based data transmission protocols

Conceptually, each portion of the transmission (packets in most data link layers, but bytes in

TCP) is assigned a unique consecutive sequence number, and the receiver uses the numbers to

place received packets in the correct order, discarding duplicate packets and identifying missing

ones.By placing limits on the number of packets that can be transmitted or received at any given

time, a sliding window protocol allows an unlimited number of packets to be communicated

using fixed-size sequence numbers. The term "window" on transmitter side represents the logical

boundary of the total number of packets yet to be acknowledged by the receiver. The receiver

informs the transmitter in each acknowledgment packet the current maximum receiver buffer

size (window boundary).

Aim:

To create a program for the simulation of sliding window protocols.

Algorithm:

1.Initialize all variables.

2.Get the socket to send the string from sender to receiver.

3.Give the data as input.

4.The sliding window will send as many data as the sending window size to the receiver

and wait for the acknowledgement.

5.Once it receives the acknowledgment from the receiver it sends the next set of data.

6.Steps 3 and 4 are repeated as long as the input data is sent and acknowledgement is

received.

7.Once it sends the first set of data it is ready to send the next input string.

8.Type ―quit‖ to end the session.

9.Stop.


PROGRAM:

SLIDING WINDOW SENDER:

import java.io.*;

import java.net.*; public class SWsender

{ public static void main(String args[])throws IOException {

int SWS=8; int LAR=0;

int LFS=0; ServerSocket ss=new ServerSocket(500); Socket s=ss.accept();

System.out.println("Type your Message..."); DataInputStream dis=new DataInputStream(s.getInputStream());


int i=0,j=0; String t=new DataInputStream(System.in).readLine();

if(t.trim().toLowerCase().equals("quit")) { p.println(t);

System.exit(0); }

char c[]=new char[100]; c=t.toCharArray(); int sent=1;

while(i<t.length()) {

while(i<t.length()&&i<SWS*sent) { if(LFS-LAR<=SWS)

{ p.println(c[i]);

LFS++; System.out.println("sent="+c[i++]+"Successfully"); }

} while(j<t.length()&&j<SWS*sent)

{ String t1=dis.readLine();

System.out.println(t1);


j++; LAR++;

} sent++;

System.out.println(); } }

}

}

SLIDING WINDOW RECEIVER:

import java.io.*; import java.net.*;

public class SWreceiver { public static void main(String args[])throws IOException

{ int RWS=8;

int LAF=0; int LFR=0; InetAddress obj=InetAddress.getLocalHost();

Socket s=new Socket(obj,500); DataInputStream dis=new DataInputStream(s.getInputStream());


int i=0; while(i<RWS)

{ String t; if(LAF-LFR<=RWS)

{ t=dis.readLine();

if(t.equals("QUIT")) System.exit(0); System.out.println("received"+t+"Successfully");

LFR++; p.println("Acknowledgement for"+t);

LAF++; } i++;

} System.out.println();

}


} }

OUTPUT:

AT SERVER SIDE: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac SWsender.java

Note: SWsender.java uses or overrides a deprecated API.

Note: Recompile with -deprecation for details. D:\jdk1.6.0\bin>java SWsender

Type your Message...

HAI sent=H Successfully

sent=A Successfully sent=I Successfully

Acknowledgement for H Acknowledgement for A

Acknowledgement for I

AT RECEIVER SIDE: C:\Documents and settings\STUDENT> d: D:\>cd D:\jdk1.6.0\bin

D:\jdk1.6.0\bin>javac SWreceiver.java

Note: SWreceiver.java uses or overrides a deprecated API.



D:\jdk1.6.0\bin>java SWreceiver

Received H Successfully Received A Successfully Received I Successfully

OUTPUT:







WORK sent=W Successfully

sent=OSuccessfully sent=R Ruccessfully

sent=K Ruccessfully Acknowledgement for W

Acknowledgement for O Acknowledgement for R

Acknowledgement for K

AT RECEIVER SIDE: C:\Documents and settings\STUDENT> d:



D:\jdk1.6.0\bin>javac SWreceiver.java Note: SWreceiver.java uses or overrides a deprecated API.


D:\jdk1.6.0\bin>java SWreceiver Received W Successfully

Received O Successfully Received R Successfully

Received R Successfully

OUTPUT:







TRY sent=T Successfully

sent=R Successfully sent=Y Successfully

Acknowledgement for T Acknowledgement for R

Acknowledgement for Y


AT RECEIVER SIDE:



D:\jdk1.6.0\bin>javac SWreceiver.java Note: SWreceiver.java uses or overrides a deprecated API.


D:\jdk1.6.0\bin>java SWreceiver Received T Successfully

Received R Successfully Received Y Successfully

RESULT Thus the java program to implement simulation of Sliding Window was written and executed successfully.


Ex. No.7

Date:

Implementation of ARP .

Abstract:

ARP basically maps IP address with the MAC address or hardware address. For the

successful data transfer the software searches the corresponding MAC address of the destination

in the cache. If it founds, it returns the MAC address to sender but if it doesn't then it broadcast

the IP address on the LAN. The matching IP address machine replies directly to the sender. In

this way it works. For broadcasting, the software call functions or procedures (which act as

machines in the LAN) and sends ARP request in a particular format.

Aim:

To create a program for the implementation of ARP.

Algorithm:

1.Establish connection between the server and the client.

2.Read the IP address from the standard input.

3.The IP address is searched in the file and corresponding MAC address is displayed

4.If not found, an error is displayed.

5.Stop.


PROGRAM:

ARP: import java.net.*;

import java.io.*; import java.lang.*; import java.util.*;

class arp {

public static void main(String args[])throws Exception { int flag=0;

File f=new File("arp.txt"); FileInputStream fis=new FileInputStream(f);

InputStreamReader isr=new InputStreamReader(fis); BufferedReader br=new BufferedReader(isr); String str=br.readLine();

System.out.print("Enter IP Address"); String mac=new DataInputStream(System.in).readLine();

while(str!=null) { StringTokenizer st=new StringTokenizer(str,":");

String s=st.nextToken(); if(s.equals(mac))

{ System.out.println("The MAC Address is"+st.nextToken()); flag=1;

break; }

str=br.readLine(); } if(flag==0)

System.out.println("No such IP Exists"); }

}


OUTPUT: C:\Documents and settings\STUDENT> d:


D:\jdk1.6.0\bin>javac arp.java Note: arp.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details.

D:\jdk1.6.0\bin>java arp

Enter IP Address 127.0.0.5 The MAC Address is 12-32-45-0-0-1

D:\jdk1.6.0\bin>java arp Enter IP Address 213.0l.0.5

No such IP Exists


OUTPUT:



D:\jdk1.6.0\bin>javac arp.java Note: arp.java uses or overrides a deprecated API.


D:\jdk1.6.0\bin>java arp Enter IP Address 125.0.0.5 The MAC Address is 12-32-45-0-0-1


Enter IP Address 217.0l.0.5 No such IP Exists


OUTPUT:



D:\jdk1.6.0\bin>javac arp.java Note: arp.java uses or overrides a deprecated API.


D:\jdk1.6.0\bin>java arp Enter IP Address 129.0.0.5 The MAC Address is 12-32-45-0-0-1


Enter IP Address 203.0l.0.5 No such IP Exists


RESULT Thus the java program to implementation of ARP was written and the output was executed successfully.


Ex. No.8

Date:

Implementation of RARP .

Abstract:

RARP is Reverse Address Resolution Protocol that determines source network address (IP address) from source data link address MAC (Media Access Control) address. RARP is used

to determine system’s own IP address when it comes up. When system boots it sends a RARP request which contains its own layer 2(Data link layer) MAC address to Ethernet broadcast address. RARP server in the subnet which contains the mapping table from MAC address to IP

address responds to such requests with corresponding IP address. RARP is used in Ethernet, Fiber Distributed-Data Interface (FDDI) and Token Ring LANs. DHCP (Dynamic Host

Configuration Protocol) is modern implementation of RARP, Which allocates IP address dynamically when system comes up. Thus IP address can be reused if it is no longer needed.

Aim:

To create a program for the implementation of ARP.

Algorithm:

1.Establish connection between the server and the client.

2.Read the MAC address from the input

3.The MAC address Is searched in the file and the corresponding IP address is displayed.

4.If not found an error in the search file and hence display the error.

5.Stop.


PROGRAM:

RARP:

import java.net.*; import java.io.*; import java.util.*;

class rarp {

public static void main(String args[])throws Exception { int flag=0;

File f=new File("rarp.txt"); FileInputStream fis=new FileInputStream(f);

InputStreamReader isr=new InputStreamReader(fis); BufferedReader br=new BufferedReader(isr); String str=br.readLine();

System.out.println("Enter MAC Address :");

String ip=new DataInputStream(System.in).readLine();

while(str!=null)

{ StringTokenizer st=new StringTokenizer(str,":"); String s=st.nextToken();

if(s.equals(ip))

{ System.out.println("The IP Address is"+st.nextToken()); break;

}

str=br.readLine(); if(flag==0)

System.out.println("No such IP Address exists");

}

}

}


OUTPUT:



D:\jdk1.6.0\bin>javac rarp.java

Note: rarp.java uses or overrides a deprecated API.


D:\jdk1.6.0\bin>java rarp

Enter MAC Address : 10-32-45-0-0-1

The IP Address is17.0.0.5


Enter MAC Address :

19-20-0-0-3-0 No such IP Address exists

No such IP Address exists No such IP Address exists


OUTPUT:










Enter MAC Address :

19-20-0-0-3-0 No such IP Address exists



OUTPUT:











No such IP Address exists



RESULT Thus the java program to implementation of RARP was created and the output was executed successfully.


Ex. No.9a

Date:

STUDY OF NETWORK SIMULATOR – NS2

Aim:

To study about the Network Simulator – NS2.

Introduction:

NS is a discrete event simulator targeted at networking research. NS provides subs tantial

support for simulation of TCP, routing and multicast protocols over wired and wireless networks.

A simulation is an imitation of some real thing, state of affairs, or process. The act of simulating something generally entails representing certain key characteristics or behaviour of a selected physical or abstract system.

Key issues in simulation include acquisition of valid source information about referent selection of key characteristics and behaviours, the use of simplifying approximations and assumptions within the simulation and fieldility and validity of the simulation

outcomes. NS is a public domain simulator boating a rich set of Internet protocols, including

terrestrial, wireless and satellite networks. NS began as a variant of the REAL network simulator in 1989 and has evolved

substantially over the past few years. In 1995 NS development was supported by DARPA

through the VINT project at LBL, Xerox PARC, UCB and USC/IS. NS – 2 is written in C++ and an Object Oriented version of Tcl called OTcl.

NS is constantly maintained and updated by its large user base and a small group of developers at ISI.

12.1 Network Animator – NAM:

Nam is a Tcl/TK based animation tool for viewing network simulation traces and real world packet traces. It is mainly intended as a companion animator to the NS simulator.

It supports topology layout, packet level animation, and various data inspection tools. Nam began at LBL. It has evolved substantially over the past few years. The nam

development effort was an ongoing collaboration with the VINT project.

Currently, it is being developed at ISI as part of the SAMAN and Conser projects. NS together with its companion, Nam form a very powerful set of tools for teaching

networking concepts.


NS contains all the IP protocols typically covered in undergraduate and most graduate courses, and many experimental protocols contributed by its ever-expanding users. With

nam, these protocols can Visualized as animations.

Below is the screenshot of a nam window where the most important functions are being explained.

12.2 Installing NS:

1. Requirements:

To build NS we need a computer and a C++ compiler. We develop NS on several kinks

of Unix (FreeBSD, LINUX, SunOS, Solaris), so it installs smoothest there, but it should run on a Posix- like computer, possibly with some thwacking.

NS also builds and runs under Windows.

Simple scenarios should run on reasonable machine, but very large scenarios benefit from large amounts of memory.

NS is fairly large. The allinonc package requires about 320MB of disk space to build. Building NS from pieces can save some disk space.

2. Downloading And Building NS:

NS requires a modestly up-to-date installation of Tcl/TK (with header files), and two additional packages: tclcl and otcl.


TCL (Tools Command Language) is a very powerful but easy to learn dynamic programming language, suitable for a very wide range of uscs, including web and

desktop applications, networking, administration, testing and many more. TK is a graphical user interface toolkit. TK is the standard GUI not only for Tcl, but also

for many other dynamic languages, and can produce rich, native applications that run unchanged across Windows, Mac OS X, Linux and more.

Most OS installations do not come with full Tcl/TK installations or with these other

packages, so we will most likely need to install several packages.

Windows Specific Instructions:

NS runs on windows platforms using Cygwin emulation.

Cygwin is a Linux- like environment for Windows. It consists of two parts:

A DLL (cygwin1.dll), which acts as a Linux API emulation layer providing substantial Linux API functionality.

A Collection of tools, which provide Linux look and feel.

12.3 Protocols Supported By NS2:

A lot almost all variants of TCP, several forms of multicast, wired networking, several

adhoc routing protocols and propagation models (but not cellular phones), data diffusion, satellite, and other stuff.

12.4 Documentation:

Core Documentation

NS Manual (formerly called ―NS Notes and Documentation‖)

The NS Manual (formerly known as NS Notes and Documentation) is the main source of documentation. It is available in three formats.

Formats:

NS Manual html format. NS Manual gzip’ed postscript format. NS Manual pdf format.

Functionality In Both NS – 1 And NS – 2:

One-way TCP (Tahoe, Reno, Vegas, SACK). These do not include SYN/FIN packets. (The Vegas implementation has only limited validation).

Two-way Reno TCP (with SYN/FIN packets and two-way data flow).

RED queue management; CBQ (Class – Based Scheduling). Dynamic routing, dense-mode multicast routing.

The flow manager. Lossy links (different interface than NS-1). Two-way TCP.


Telnet sources.

Functionality In NS – 2 But Not In NS – 1:

Multi-path routing.

RTP (Real Time Protocol) Scheduling Algorithms:

SFQ (Stochastic Fair Queueing) FQ (Fair Queueing) DRR (Deficit Round Robin Scheduling)

SRM (Scalable Reliable Multicast) ―Centralized Multcast‖ for speeding up large-scale simulations.

Support for mobile hosts. (Link- layer, MAC, and shared channel modules have been implemented).

Some random bug fixes (TCP Transmit Timer Behavior).

12.5 Functions Of NS:

Education Uses

General information about using NS / nam for networking education. Web index of education scripts.

Contributed Code And Contributing Code

Contributed Modules.

How to contribute our NS code. Research using NS.

Parallel/Distributed NS (PDns) from the COMPASS research group at Georgia Tech.

Other Applications

Topology Generation for large simulations. Scenario generation in NS.

NS Network Emulation Capability.

12.6 How to start with NS2:

First of all, you need to create a simulator object. This is done with the command

set ns [new Simulator]

Now we open a file for writing that is going to be used for the nam trace data.

set nf [open out.nam w]

$ns namtrace-all $nf

The first line opens the file 'out.nam' for writing and gives it the file handle 'nf'. In the second

line we tell the simulator object that we created above to write all simulation data that is going to be relevant for nam into this file.The next step is to add a 'finish' procedure that closes the trace

file and starts nam.


proc finish {} {

global ns nf

$ns flush-trace

close $nf

exec nam out.nam &

exit 0

}

You don't really have to understand all of the above code yet. It will get clearer to you once you

see what the code does. The next line tells the simulator object to execute the 'finish' procedure after 5.0 seconds of simulation time.

$ns at 5.0 "finish"

You probably understand what this line does just by looking at it. ns provides you with a very simple way to schedule events with the 'at' command. The last line finally starts the simulation.

$ns run

You can actually save the file now and try to run it with 'ns example1.tcl'. You are going to get an error message like 'nam: empty trace file out.nam' though, because until now we haven't

defined any objects (nodes, links, etc.) or events. #Create a simulator object


#Open the nam trace file



#Define a 'finish' procedure

proc finish {} {

global ns nf

$ns flush-trace

#Close the trace file

close $nf

#Execute nam on the trace file

exec nam out.nam &

exit 0

}

# Insert your own code for topology creation

# and agent definitions, etc. here

#Call the finish procedure after 5 seconds simulation time

$ns at 5.0 "finish"

#Run the simulation

$ns run

Two nodes, one link

In this section we are going to define a very simple topology with two nodes that are connected by a link. The following two lines define the two nodes. (Note: You have to insert the code in this section before the line '$ns run', or even better, before the line '$ns at 5.0 "finish"').

set n0 [$ns node]


set n1 [$ns node]

A new node object is created with the command '$ns node'. The above code creates two nodes

and assigns them to the handles 'n0' and 'n1'. The next line connects the two nodes.

$ns duplex-link $n0 $n1 1Mb 10ms DropTail

This line tells the simulator object to connect the nodes n0 and n1 with a duplex link with the bandwidth 1Megabit, a delay of 10ms and a DropTail queue. Now you can save your file and start the script with 'ns example1.tcl'. nam will be started automatically and you should see an

output that resembles the picture below.

#Create a simulator object






proc finish {} {

global ns nf

$ns flush-trace


close $nf


exec nam out.nam &

exit 0

}

#Create two nodes

set n0 [$ns node]

set n1 [$ns node]

#Create a duplex link between the nodes


#Call the finish procedure after 5 seconds of simulation time

$ns at 5.0 "finish"

#Run the simulation

$ns run

Sending data


The next step is to send some data from node n0 to node n1. In ns, data is always being sent from one 'agent' to another. So the next step is to create an agent object that sends data from node n0,

and another agent object that receives the data on node n1.

#Create a UDP agent and attach it to node n0

set udp0 [new Agent/UDP]

$ns attach-agent $n0 $udp0

# Create a CBR traffic source and attach it to udp0

set cbr0 [new Application/Traffic/CBR]

$cbr0 set packetSize_ 500

$cbr0 set interval_ 0.005

$cbr0 attach-agent $udp0

These lines create a UDP agent and attach it to the node n0, then attach a CBR traffic generator

to the UDP agent. CBR stands for 'constant bit rate'. Line 7 and 8 should be self-explaining. The packet Size is being set to 500 bytes and a packet will be sent every 0.005 seconds (i.e. 200 packets per second). The next lines create a Null agent which acts as traffic sink and attach it to

node n1. set null0 [new Agent/Null]

$ns attach-agent $n1 $null0

Now the two agents have to be connected with each other. $ns connect $udp0 $null0

And now we have to tell the CBR agent when to send data and when to stop sending. Note: It's probably best to put the following lines just before the line '$ns at 5.0 "finish"'.

$ns at 0.5 "$cbr0 start"

$ns at 4.5 "$cbr0 stop"

This code should be self-explaining again. Now you can save the file and start the simulation again. When you click on the 'play' button in the nam window, you will see that after 0.5

simulation seconds, node 0 starts sending data packets to node 1. You might want to slow nam down then with the 'Step' slider.

Now you start some experiments with nam and the Tcl script. You can click on any

packet in the nam window to monitor it, and you can also click directly on the link to get some graphs with statistics. Try to change the 'packetsize_' and 'interval_' parameters in the Tcl script to see what happens. #Create a simulator object







proc finish {} {

global ns nf

$ns flush-trace


close $nf


exec nam out.nam &

exit 0

}

#Create two nodes

set n0 [$ns node]

set n1 [$ns node]

#Create a duplex link between the nodes










#Create a Null agent (a traffic sink) and attach it to node n1

set null0 [new Agent/Null]


#Connect the traffic source with the traffic sink

$ns connect $udp0 $null0

#Schedule events for the CBR agent




$ns at 5.0 "finish"

#Run the simulation

$ns run

The topology You will always have to create a simulator object, you will always have to start the simulation

with the same command, and if you want to run nam automatically, you will always ha ve to open a trace file, initialize it, and define a procedure which closes it and starts nam.

Now insert the following lines into the code to create four nodes. set n0 [$ns node]

set n1 [$ns node]

set n2 [$ns node]


set n3 [$ns node]

The following piece of Tcl code creates three duplex links between the nodes.




You can save and start the script now. You might notice that the topology looks a bit awkward in nam. You can hit the 're-layout' button to make it look better, but it would be nice to have some

more control over the layout. Add the next three lines to your Tcl script and start it again. $ns duplex-link-op $n0 $n2 orient right-down

$ns duplex-link-op $n1 $n2 orient right-up

$ns duplex-link-op $n2 $n3 orient right You will probably understand what this code does when you look at the topology in the nam

window now. It should look like the picture below.

The events

Now we create two UDP agents with CBR traffic sources and attach them to the nodes n0 and n1. Then we create a Null agent and attach it to node n3.




















The two CBR agents have to be connected to the Null agent. $ns connect $udp0 $null0

$ns connect $udp1 $null0 We want the first CBR agent to start sending at 0.5 seconds and to stop at 4.5 seconds

while the second CBR agent starts at 1.0 seconds and stops at 4.0 seconds.




$ns at 4.5 "$cbr0 stop" When you start the script now with 'ns example2.tcl', you will notice that there is more

traffic on the links from n0 to n2 and n1 to n2 than the link from n2 to n3 can carry. A simple calculation confirms this: We are sending 200 packets per second on each of the first two links

and the packet size is 500 bytes. This results in a bandwidth of 0.8 megabits per second for the links from n0 to n2 and from n1 to n2. That's a total bandwidth of 1.6Mb/s, but the link between n2 and n3 only has a capacity of 1Mb/s, so obviously some packets are being discarded. But

which ones? Both flows are black, so the only way to find out what is happening to the packets is to monitor them in nam by clicking on them.

Marking-flows Add the following two lines to your CBR agent definitions.

$udp0 set class_ 1

$udp1 set class_ 2

The parameter 'fid_' stands for 'flow id'.

Now add the following piece of code to your Tcl script, preferably at the beginning after the

simulator object has been created, since this is a part of the simulator setup.

$ns color 1 Blue

$ns color 2 Red

This code allows you to set different colors for each flow id.


Now you can start the script again and one flow should be blue, while the other one is red. Watch the link from node n2 to n3 for a while, and you will notice that after some time the distribution

between blue and red packets isn't too fair anymore

Monitoring a queue You only have to add the following line to your code to monitor the queue for the link from n2 to

n3.

$ns duplex-link-op $n2 $n3 queuePos 0.5

Start ns again and you will see a picture similar to the one below after a few moments.

You can see the packets in the queue now, and after a while yo u can even see how the

packets are being dropped, though (at least on my system, I guess it might be different in later or earlier releases) only blue packets are being dropped. But you can't really expect too much

'fairness' from a simple Drop Tail queue. Change the link definition for the link between n2 and n3 to the following line. $ns duplex-link $n3 $n2 1Mb 10ms SFQ

The queuing should be 'fair' now. The same amount of blue and red packets should be dropped.


Result:

Thus the basics of Network Simulator NS – 2 was studied.


Ex. No.9b

Date:

NETWORK SIMULATOR GLOMOSIM

AIM: To perform a detailed study on Network simulator GloMoSim.

GloMoSim:

GloMoSim stands for global mobile simulation.GloMoSim provides a scalable simulation

environment for wireless and wired network systems.GloMoSim currently supports protocols

for a purely wireless network.

Standard APIs will be used between the different simulation layers.This will allow

the rapid integration of models developed at different layers by different people.

NETWORK GRIDDING:

With network gridding a single entity can simulate network nodes in the system.A

separate data structure representing the complete state of each node is maintained within entity.Similarly we need to maintain the right level of abstraction.

The networh gridding technique means that we can increase the number of nodes in the system while maintaining the same number of entities in the simulation.

In GloMoSim, each entity represents a geographical area of simulation.

LAYERED STRUCTURE:

Most network are currently built using a layered approach that is similar to the OSI seven layer network architechture.The plan is to build GloMoSim using a similar layered approach.The protocols being stripped with the current library include the following.

GloMoSim layers are integrated into a single entity.Each entity now

encompasses all the layers of a simulation.Instead each layer is now implemented as functions in the new design.

When layer receives a particular message, it will automatically invoke a function that is provided by the developer of the particular layer.And

based on the contents of the message,the function can then execute the appropriate instructions.At the end of the simulation,a function is also called for each layer of each node.


Applicationprocessing

RTP Wrapper RGIP

RSVP

Clust-ering

Applicationsetup

TCP/UDP Control

IP mobile

Routing

ACK / Flow ctrl

RTS / CTS Radio

Radio status / setup

Mobility

VCFlowctrl

Rou-ting

Transportwrapper

Framewrapper

Frameprocessing

Ipwrapper

Pack store/fwd

Factor/fwd

Propagationmodel

Clust-ering

Application

Transport

IP

Network

Link layer

MAC layer

Radio

Channel

Glomosim Simulation Layers


host host

Wireless MultihopNetwork

Wired Network

Glomo Simulation Scenario

APPLICATION: Data applications-Eg. File Transfer, rumor reconciliation etc. Real time application-Eg. Audio,Video,Video conference etc.


RESULT: Thus the Network Simulator GloMoSim is studied.


Ex. No.10

Date:

SIMULATION OF A DYNAMIC ROUTING PROTOCOL

-- LINK STATE ROUTING PROTOCOL

Aim:

To Study and Simulate Dynamic Routing Protocol in NS2.

Description:

Routing:

Routing is the process of selecting paths in computer networking along which to send data or physical traffic. Routing is performed for many kinds of networks, including the

telephone network, the Internet, and transport networks.

Routing directs forwarding, the passing of logically addressed packets from their source toward their ultimate destination through intermediary nodes; typically hardware devices ca lled routers, bridges, gateways, firewalls, or switches. Ordinary computers with multiple network cards can

also forward packets and perform routing, though with more limited performance. The routing process usually directs forwarding on the basis of routing tables which maintain a record of the

routes to various network destinations. Thus constructing routing tables, which are held in the routers' memory, becomes very important for efficient routing.

Routers create broadcast domains. A network broadcast is a message that is sent to all hosts on a network. The reason for a broadcast is for a host on a network to retrieve information about

an unknown host. Broadcasts can be necessary and useful tools for protocols on networks to enable data communication. The larger the number of hosts on a network, the more of a problem

broadcasts become. More hosts equals more broadcasts equals more consumed bandwidth on the network. When these broadcasts are sent, the host that receive the broadcasts need to process them, and this processing takes away valuable time from performing other important network

functions. Broadcasts are contained within networks by the Router, these networks are know as Broadcast Domains

Routing Protocol :

A routing protocol is the language a router speaks with other routers in order to share

information about the reach ability and status of networks.

Dynamic Routing Protocol:

http://en.wikipedia.org/wiki/Routers


Conceptually, the dynamic routing method has two parts: the routing protocol that is used between neighboring routers to convey information about their network environment, and the

routing algorithm that determines paths through that network. The protocol defines the method used to share the information externally, whereas the algorithm is the method used to process the

information internally.

The routing tables on dynamic routers are updated automatically based on the exchange of routing information with other routers. The most common dynamic routing protocols are:

• Distance vector routing protocols

• Link state routing protocols

Dynamic routing protocols not only perform these path determination and route table update functions but also determine the next-best path if the best path to a destination becomes unusable. The capability to compensate for topology changes is the most important

advantage dynamic routing offers over static routing.

Routing Protocol Basics

All dynamic routing protocols are built around an algorithm. Generally, an algorithm is a step-by-step procedure for solving a problem. A routing algorithm must, at a minimum,

specify the following:

A procedure for passing reachability information about networks to other routers

A procedure for receiving reachability information from other routers

A procedure for determining optimal routes based on the reachability information it

has and for recording this information in a route table

A procedure for reacting to, compensating for, and advertising topology changes in

an internetwork

A few issues common to any routing protocol are path determination, metrics, convergence, and load balancing.

Link State Routing Protocols

Link state routing protocols address some of the limitations of distance vector routing protocols. For example, link state routing protocols provide faster convergence than do distance vector routing protocols. Convergence is the process by which routers update routing

tables after a change in network topology — the change is replicated to all routers that need to know about it. Although link state routing protocols are more reliable and require less

bandwidth than do distance vector routing protocols, they are also more complex, more memory- intensive, and place a greater load on the CPU.

Path Determination


All networks within an internetwork must be connected to a router, and wherever a router has an interface on a network that interface must have an address on the network. This address is the originating point for reach ability information.

Program: (ex3.tcl)

#Create a simulator object


#Tell the simulator to use dynamic routing

$ns rtproto DV





proc finish {} {

global ns nf

$ns flush-trace


close $nf


exec nam out.nam &

exit 0

}

#Create seven nodes

for {set i 0} {$i < 7} {incr i} {

set n($i) [$ns node]

}

#Create links between the nodes

for {set i 0} {$i < 7} {incr i} {

$ns duplex-link $n($i) $n([expr ($i+1)%7]) 1Mb 10ms DropTail


}

#Create a UDP agent and attach it to node n(0)


$ns attach-agent $n(0) $udp0






#Create a Null agent (a traffic sink) and attach it to node n(3)


$ns attach-agent $n(3) $null0

#Connect the traffic source with the traffic sink

$ns connect $udp0 $null0

#Schedule events for the CBR agent and the network dynamics


$ns rtmodel-at 1.0 down $n(1) $n(2)

$ns rtmodel-at 2.0 up $n(1) $n(2)



$ns at 5.0 "finish"

#Run the simulation

$ns run


OUTPUT:

Transmission of data packets with Dynamic Routing protocol when the link between Node1 and Node 2 is down (1 ms)

Transmission of data packets with Dynamic Routing protocol when the link between Node1 and

Node 2 is up (2Ms)


Initial Layout (0 ms)


Transmission of data packets from node 0 to node 3 (0.79 ms)


Result:

Thus the Study and Simulation in Dynamic Routing Protocol in NS2 was studied and executed.

cs2307_mnl

Documents

server socket

implementation of echo

echo client

client program

new serversocket500

getlocalhost socket

new printstreams

new datainputstreams