LAB MANUAL

Sub Code Sub Name Branch Semester

:- CS2307 :- Network Lab :- COMPUTER SCIENCE AND ENGINEERING :- 05

LIST OF EXPERIMENTS CS2307 - NETWORK LAB

1. Study of Network Commands 2a. Using TCP SOCKETS ( DATE TIME SERVER & CLIENT ) 2b. Using TCP SOCKETS ( ECHO SERVER & CLIENT) 2c.Using TCP SOCKETS ( TCP CHAT ) 3a. Using UDP SOCKETS ( RESOLVING THE DNS SERVER USING UDP ) 3b.USING SOCKETS ( DOMAIN NAME SERVER ) 4. Using RAW Sockets ( Packet Capturing And Filtering) 5. Programs Using RPC 6. Simulation of Sliding Window Protocols ( NS2 simulators) 7. Implementing Routing Protocols (OSPF ,DSDV) 8. Performance Comparison of MAC protocols 9. Performance comparison of Routing Protocols 10. Study of UDP performance 11. Study of TCP Performance

REQUIREMENTS 1. SOFTWARE C++ Compiler J2SDK (freeware) Linux NS2/Glomosim/OPNET (Freeware) 2. HARDWARE PCs

INDEX S.NO 1. 2a. 2b. 2c. 3a. 3b. 4. 5. 6. 7. 8. 9. 10. 11.

EX.No:1

EXPRIMENT NAME
Study of Network Commands Using TCP SOCKETS ( DATE TIME SERVER & CLIENT ) Using TCP SOCKETS ( ECHO SERVER & CLIENT) Using TCP SOCKETS ( TCP CHAT ) Using UDP SOCKETS ( RESOLVING THE DNS SERVER USING UDP ) USING SOCKETS ( DOMAIN NAME SERVER ) Using RAW Sockets ( Packet Capturing And Filtering) Programs Using RPC Simulation of Sliding Window Protocols ( NS2 simulators) Implementing Routing Protocols (OSPF ,DSDV) Performance Comparison of MAC protocols Performance comparison of Routing Protocols Study of UDP performance Study of TCP Performance

STUDY OF NETWORK COMMANDS

1. SOCKET FUNCTION Int Socket(int family , int type , int protocol);

It returns non negative value if ok, -1 on error.

FAMILY AF_INET AF_INET6

DESCRIPTION Ipv4 Protocol Ipv6 Protocol

TYPE Sock_STREAM Sock_DGRAM Sock_RAW

DESCRIPTION Stream socket- TCP Datagram socket-UDP Raw socket-Ipv4, Ipv6

2. CONNECT FUNCTION: Int connect(int sockfd, const struct sockaddr * sockaddr, socklen_t addrlen);

Returns 0 if ok, -1 on error.

It is used to client to establish a connection with a TCP server.

3. BIND FUNCTION

Int bind(int sockfd, const struct sockaddr *myaddr, socklen_t_addrlen); Returns 0 if ok, -1 on error.

It assigns a local protocol address to a socket second argument is a pointer to a protocol specific address third argument is the size of this address structure calling bind let us specify a port number an IP address, both or neither.

4. LISTEN FUNCTION It will called only by a TCP server. Int listen(int sockfd, int backlog);

When a socket is created by the socket function, a client socket will issue a connect. The listen function converts an unconnected socket in to passive socket.

The second argument to this function specifies the maximum number of connections that the kernel should queue for this socket.

5. CLOSE FUNCTION: Int close(int sockfd)

The default action of close with a TCP socket is to mark the socket as closed and return to the process immediately.

EX.NO:- 2a

DAY AND TIME OF SERVER

AIM: To display the day and time of the server using Telnet.

ALGORITHM: SERVER: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Initialise the socket and set its attributes and assign a specific port number as desired 4) Bind the server to the socket using Bind function. 5) Wait for the client requests . On request establish a connection using accept function. 6) Send the day and time to the client. 7) Repeat the steps until the connection is terminated. 8) Stop the program. CLIENT: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Initialise the socket and set its attributes and assign a specific port number as desired 4) Connect to the server using connect function to initialise the request. 5) Receive day and time from the server. 6) Repeat the steps until the connection is terminated. 7) Stop the program.

CLIENT PROGRAM:#include<stdio.h> #include<stdlib.h> #include<sys/socket.h> #include<sys/types.h> #include<netdb.h> int main() { int sd,c; char msg[50],sip[15]; struct sockaddr_in caddr; struct hostent *he; printf("enter server IP address"); scanf("%s",sip); he=gethostbyname(sip); sd=socket(AF_INET,SOCK_STREAM,0); if(sd!=-1) printf("socket is created\n"); else printf("socket is no created\n"); caddr.sin_family=AF_INET; caddr.sin_port=htons(5666); c=connect(sd,(struct sockaddr *)&caddr,sizeof(caddr)); if(c==0) printf("connected to server"); else printf("not connected"); recv(sd,msg,sizeof(msg),0); printf(" the day and time of the server is %s",msg); close(sd); return 0; }

SERVER PROGRAM:#include<stdio.h>

#include<string.h> #include<stdlib.h> #include<sys/socket.h> #include<sys/types.h> #include<netinet/in.h> #include<unistd.h> int main() { int sd,b,cd; char msg[50]; struct sockaddr_in caddr,saddr; socklen_t clen=sizeof(caddr); time_t tick; sd=socket(AF_INET,SOCK_STREAM,0); if(sd!=-1) printf("socket is created\n"); else printf("socket is not created\n"); saddr.sin_family=AF_INET; saddr.sin_addr.s_addr=htonl(INADDR_ANY); saddr.sin_port=htons(5666); b=bind(sd,(struct sockaddr *)&saddr,sizeof(saddr)); if(b==0) printf(bind to client:\n); else printf(not bind to client:\n); listen(sd,5); while(1) { cd=accept(sd,(struct sockaddr *)&caddr,&clen); tick=time(NULL); printf("system day and time %s",ctime(&tick)); strcpy(msg,ctime(&tick)); send(cd,msg,sizeof(msg),0); } close(sd); close(cd); return 0; }

OUTPUT:SERVER:-

[vt4862@localhost ~]$ cc sday.c [vt4862@localhost ~]$ ./a.out socket is created binded to client system day and time:Fri Mar 6 15:17:26 2009 CLIENT:-

[vt4862@localhost ~]$ cc cday.c [vt4862@localhost ~]$ ./a.out enter ip address:100.30.20.10 socket is created connected to server the day and time erver is Fri Mar 6 15:17:26 2009

[vt4862@localhost ~]$ RESULT:Thus the day time server is executed and the output is verified. EX.NO:- 2b AIM: To enable a simple message passing between client and server. ALGORITHM: SERVER: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Initialise the socket and set its attributes and assign a specific port number as desired 4) Bind the server to the socket using Bind function. 5) Wait for the client requests . On request establish a connection using accept function. 6) Fork a child process perform steps 7-10 for each process. 7) Read the message from the client through the connection. 8) Display the clients message 9) Send an acknowledgement message to the client. 10) Exit the child process and close the connection. CLIENT: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Initialise the socket and set its attributes and assign a specific port number as desired 4) Connect to the server using connect function to initialise the request. 5) Send the message to the server. 6) Receive an acknowledgement from the server. 7) Stop the program. TCP SIMPLE MESSAGE PASSING

10

PROGRAM: Server #include<stdio.h> #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<netdb.h> #define SERV_PORT 5001 int main(int argc,char* argv[]) { int sockfd,newsockfd,clen; struct sockaddr_in serv_addr,cli_addr; char buffer[4096]; sockfd=socket(AF_INET,SOCK_STREAM,0); serv_addr.sin_family=AF_INET; serv_addr.sin_addr.s_addr=INADDR_ANY; serv_addr.sin_port=htons(SERV_PORT); bind(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr)); listen(sockfd,5); clen=sizeof(cli_addr); newsockfd=accept(sockfd,(struct sockaddr*)&cli_addr,&clen); bzero(buffer,4096); read(newsockfd,buffer,4069); printf("\n Client:%s",buffer); write(newsockfd,buffer,4069); printf("\n"); close(sockfd); return(0); }

11

Client #include<stdio.h> #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<netdb.h> #define SERV_PORT 5001 int main(int argc,char* argv[]) { int sockfd; struct sockaddr_in serv_addr; struct hostent *server; char buffer[4096]; sockfd=socket(AF_INET,SOCK_STREAM,0); serv_addr.sin_family=AF_INET; serv_addr.sin_addr.s_addr=inet_addr("30.29.28.200"); serv_addr.sin_port=htons(SERV_PORT); connect(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr)); printf("\nEnter your message to send....\n"); bzero(buffer,4096); printf("\nclient:"); fgets(buffer,4096,stdin); write(sockfd,buffer,4096); bzero(buffer,4096); read(sockfd,buffer,4069); printf("\n Server message :%s",buffer); printf("\n"); close(sockfd); return(0); }

12

OUTPUT SERVER SIDE:

[vt4802@localhost ~]$ ./a.out client:hai

CLIENT SIDE:

[vt4802@localhost ~]$ ./a.out enter ur msg to send....... client:hai server msg:hai

13

RESULT: Thus the program for Simple message passing using TCP was successfully executed and verified. EX.NO:- 2c AIM: To enable chatting between the client and server. ALGORITHM: SERVER: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Initialise the socket and set its attributes and assign a specific port number as desired 4) Bind the server to the socket using Bind function. 5) Establish the listen queue using the listen function. 6) Wait for the client requests . On request establish a connection using accept function. 7) Repeat the steps 8-10 until the server sends bye. 8) Read the message from the client through the connection using read function and display the clients message 9) If the client message is bye goto step 11. 10) Accept the server message and write it to the client using write function. 11) Close the connection. 12) Goto step 6. CLIENT: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Initialise the socket and set its attributes and assign a specific port number as desired 4) Connect to the server using connect function to initialise the request. 5) Repeat the steps 6-8 until the server sends bye 6) Accept the client message and write it to the server using write function. 7) If the client message is bye goto step 9. 8) Read the message using read function and display the message TCP SIMPLE CHAT (HALF DUPLEX)

14

9) Stop the program.

PROGRAM: Server #include<stdio.h> #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<netdb.h> #define SERV_PORT 5001 int main(int argc,char* argv[]) { int sockfd,newsockfd,clen; struct sockaddr_in serv_addr,cli_addr; char buffer[4096]; sockfd=socket(AF_INET,SOCK_STREAM,0); serv_addr.sin_family=AF_INET; serv_addr.sin_addr.s_addr=INADDR_ANY; serv_addr.sin_port=htons(SERV_PORT); {ind(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr)); listen(sockfd,5); clen=sizeof(cli_addr); newsockfd=accept(sockfd,(struct sockaddr*)&cli_addr,&clen); do { bzero(buffer,4096); read(newsockfd,buffer,4096); }rintf("\n Client Message: %s",buffer); bzero(buffer,4096); printf("Server Message:"); fgets(buffer,4096,stdin); write(newsockfd,buffer,4096); } while(strcmp(buffer,"bye\n")!=0); close(sockfd); return(0); }

15

Client #include<stdio.h> #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<netdb.h> #define SERV_PORT 5001 int main(int argc,char* argv[]) { int sockfd; struct sockaddr_in serv_addr; struct hostent *server; char buffer[4096]; sockfd=socket(AF_INET,SOCK_STREAM,0); serv_addr.sin_family=AF_INET; serv_addr.sin_addr.s_addr=inet_addr("30.29.28.200"); serv_addr.sin_port=htons(SERV_PORT); connect(sockfd,(struct sockaddr*)&serv_addr,sizeof(serv_addr)); do { bzero(buffer,4096); printf("\nClient Message:"); fgets(buffer,4096,stdin); write(sockfd,buffer,4096); bzero(buffer,4096); read(sockfd,buffer,4096); printf("\n Server Message :%s",buffer); } while(strcmp(buffer,"bye\n")!=0); close(sockfd); return(0); }

16

OUTPUT: SERVER SIDE:

[vt4862@localhost ~]$ ./a.out client message:hi server:hello how are you client message:am fine server:ok take care client message:bye server:bye [vt4862@localhost ~]$ CLIENT SIDE:

[vt4862@localhost ~]$ ./a.out client:hi server message:hello how are you client:am fine server message:ok take care

17

client:bye server message:bye [vt4862@localhost ~]$ RESULT: Thus the program for TCP Simple chat is executed and output is verified.

EX.NO:- 3a) UDP SOCKETS ( RESOLVING THE DNS SERVER USING UDP) AIM: To implement the resolving of hostname by a DNS server. ALGORITHM: Start the program. Obtain the service name and protocol. Enter the port number and address type. Similarly follow the above step once again. The subsequent steps makes the required output to be displayed on the output screen. 6) The output is verified after executing the program. 7) Stop the program. PROGRAM: #include<netdb.h> main() { struct servent *sptr; int port; char pro[100],name[100]; printf("Enter the ser name:"); scanf("%s",name); printf("\n Enter the protocol(UDP/TCP):"); scanf("%s",pro); sptr=getservbyname(name,pro); printf("\n port no:%d",sptr->s_port); printf("\n address:%s",sptr->s_name); printf("enter the service port no"); scanf("%d",&port); printf("Enter the protocol(UDP/TCP):"); scanf("%s",pro); sptr=getservbyport(htons(port),pro); 1) 2) 3) 4) 5)

18

printf("\n port no:%d",sptr->s_port); printf("\n addr:%s",sptr->s_name); printf("\n protocol:%s",sptr->s_proto); }

Output:

[vt4862@localhost ~]$ cc adns.c [vt4862@localhost ~]$ ./a.out a.txt enter service namehttp enter the protocol (UDP/TCP)tcp portno:20480 address:http enter the service port no80 enter protocol (UDP/TCP)tcp port no:20480

19

address:http protocol:tcp [vt4862@localhost ~]$

Result: Thus the resolver server using domain name space is executed and the output is verified.

EX.NO:- 3b) DOMAIN NAME SERVER USING UDP AIM: To implement Domain Name Server using UDP client- server program. ALGORITHM: SERVER: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol. 3) Assign IP address, port number and protocol family to the members. 4) Bind the IP address, port number and protocol family to the socket. 5) Listen for requests from client. 6) Obtain the hostname and retrieve address using gethostbyname function. 7) Write the host address to the client side. 8) Close the socket. CLIENT: 1) Start the program. 2) Create a socket with address family AF_INET type SOCK_STREAM family and default protocol.

20

3) 4) 5) 6)

Initialize the socket and its attributes. Enter the hostname and write it to the server. Read the IP address and display it. Close the socket.

PROGRAM:SERVER:#include<netinet/in.h> #include<stdio.h> #include<string.h> #include<arpa/inet.h> #include<sys/types.h> #include<netdb.h> #include<sys/socket.h> int main(int argc,char *argv[]) { int sockfd,n; char msg[1024],buf[1024]; struct sockaddr_in servaddr,cliaddr; socklen_t len; struct hostent *hp; sockfd=socket(AF_INET,SOCK_DGRAM,0); bzero(&servaddr,sizeof(servaddr)); servaddr.sin_family=AF_INET; servaddr.sin_addr.s_addr=htonl(INADDR_ANY); servaddr.sin_port=htons(4773); bind(sockfd,(struct sockaddr*)&servaddr,sizeof(servaddr)); for(;;)

21

{ len=sizeof(cliaddr); n=recvfrom(sockfd,msg,100,0,(struct sockaddr*)&cliaddr,&len); msg[n]='\0'; printf("%s\n",msg); if(n<0) { perror("Send error"); } if((hp=gethostbyname(msg))==NULL) { printf("cant get address"); } if(inet_ntop(AF_INET,hp->h_addr_list[0],buf,sizeof(buf))<=0) printf("Host address not available\n"); printf("%s",buf); sendto(sockfd,buf,sizeof(buf),0,(struct sockaddr*)&cliaddr,len); } }

CLIENT:#include<netinet/in.h> #include<strings.h> #include<arpa/inet.h> #include<netdb.h> #define MAXLINE 1024 int main(int argc,char *argv[]) { int sockfd,n; socklen_t len; char sendline[1024],recvline[1024]; struct sockaddr_in servaddr; scanf("%s",sendline); sockfd=socket(AF_INET,SOCK_DGRAM,0); bzero(&servaddr,sizeof(servaddr)); servaddr.sin_family=AF_INET; servaddr.sin_port=htons(4773); inet_pton(AF_INET,argv[1],&servaddr.sin_addr); len=sizeof(servaddr); sendto(sockfd,sendline,strlen(sendline),0,(struct sockaddr*)&servaddr,len); n=recvfrom(sockfd,recvline,MAXLINE,0,NULL,NULL); recvline[n]='\0';

22

printf("\nThe IPaddress is %s",recvline); return 0; }

OUTPUT:SERVER:-

[vt4795@localhost kanna]$ ./a.out 100.30.20.10 100.30.20.10 [vt4795@localhost kanna ]$ CLIENT:-

23

[vt4795@localhost kanna]$ cc dnsclient.c [vt4795@localhost kanna]$ ./a.out redhat 100.30.20.10 100.30.20.10 The IP address is 100..30.20.10 [vt4795@localhost kanna]$

RESULT:Thus the Domain name server using UDP is executed and output is verified.

DNS PROGRAM

#include<stdio.h> #include<sys/socket.h> #include<sys/types.h> #include<netdb.h> #include<string.h> #include<arpa/inet.h> #include<netinet/in.h> #include<stdlib.h> int main(int argc,char *argv[]) { char *ptr,**pptr; char str[INET6_ADDRSTRLEN]; struct hostent *hptr; while(argc > 0) { ptr=argv[1]; if((hptr=gethostbyname(ptr))==NULL) { continue;

24

} printf("Official Host have:%s\n",hptr->h_name); switch(hptr->h_addrtype) { case AF_INET: pptr=hptr->h_addr_list; for(;*pptr!=NULL;pptr++) printf("Address:%s\n",inet_ntop(hptr->h_addrtype,*pptr,str,sizeof(str))); exit(0); break; default: break; } } exit(0); }

OUTPUT Official Host have:localhost.localdomain Address:127.0.0.1

25

RESULT:Thus the Domain name server using UDP is executed and output is verified.

EX.NO:- 4 4a)

RAW SOCKETS

Aim :- To implement Socket Creation Algorithm: Step1: Start the program Step2:Declare two integers socket fd1,fd2 Step3:Define sockfd socket which transmit data as stream of bytes. Step4:-Define sockfd2 as socket which transmit data as datagram Step5: If socket fd is -1 then display socket 1 is not created Step6: If sockfd2 is -1 then display socket 2 is not created else obtain file descriptor Step7:Stop the Program. PROGRAM:#include<stdio.h> #include<stdlib.h> #include<sys/socket.h> #include<netinet/in.h> #include<arpa/inet.h> #include<unistd.h>

26

{ printf(\n Socket Creation); int sockfd1,sockfd2; sockfd1=socket(AF_INET,SOCK_STREAM,0); sockfd2=socket(AF_INET,SOCK_STREAM,0); if(sockfd1==-1) { printf(\nSocket is not created); } else { prints(\nSocket1 is not created); printf(\n socket1 file descriptor is %d,sockfd1); } if(sockfd2==-1) { printf(\n cokcet1 is not created); } else { printf(\n socket is created); printf(\n socket2 file descriptor is :%d,sockfd2); } }

OUTPUT SOCKET CREATION Socket1 is created Socket1 file descriptor is :3 Socket2 is created Socket2 file descriptor is :3

27

Result :- Thus Socket has been created successfully

Ex.No :- 4b Aim: To implement Socket Binding Algorithm:

SOCKET BINDING

Step1: Start the program Step2: Define the portno globally as 2000 Step3:Declare the initial variable sockfd1 Step4:Define the structure for both client and server Step5:If sockfd is transmitted as stream of bytes it is equal to -1 then display Error Message Step6:Using the member fun access the structure value such as sin_family,sin_port,sin_addr Step7:If size of bind value is not -1 then display socket bounded portno else display Bind error Step8: Stop the Program. Program:

28

#include<stdio.h> #include<stdlib.h> #include<sys/socket.h> #include<netinet/in.h> #include<arpa/inet.h> #include<unistd.h> #defibe PORTNO 2000 int main() { printf(\n Socket Binding); int sockfd,i=PORTNO; struct sockaddr_in myaddr; if((sockfd=socket(AF_INET,SOCK_STREAM,0))==-1) { printf(\n socket creation error); } myaddr.sin_family=AF_NET; myaddr.sin_port=htone(PORTNO); myaddr.sin_addr.s_addr=INADDR_ANY; memset(&(myaddr.sin_zero,\0,8)); if(bind(sockfd,(struct sockaddr*)&mytaddr,sizeof(myaddr))!=-1) { printf(\nsocket is binded to port number %d,i); } else { printf(\n binding error); } } OUTPUT Socket binding Socket bounded to port number 2000

29

Result :- Thus Socket has been Binding successfully

EX.NO:-5 AIM :-

RPC

To implement Remote Procedure Call.

ALGORITHM:-

Step1:Start the program Step2:create a remote interface Step3:create implementation for remote methods. Step4:Generating stub abd skeleton classes using rmi complier Step5:The client classfile,the stub classfile and the interface class files are placed on client machine. Step6:The server classfile,interface classfile and the skeleton classfile placed on server machine. Step7:Create an instance of Remote object Step8:Create an instance of Remote object. Step9:Register the Remote object Step10:Invoke the Remote Methods

30

Step11:Stop the program PROGRAM:/* INTERFACE PROGRAM*/ import java.rmi.*; public interface SerInt extends Remote { double add(double d1,double d2)throwa RemoteExecution; }

/* ADDSERVER IMPLEMENTATION PROGRAM*/ import java.rmi.*; import java.rmi.server.*; public class AddServerimpl extends UnicastRemoteObject implements server { public Addserverimpl() throws RemoteException { } public double add(double d1,double d2) throws RemoteException { return d1+d2; } } /* ADDSERVER PROGRAM */ import java..rmi.*; import java.rmi.registry.*; public class AddServer { public static void main(String arg[]) {

31

try { AddServerimpl asim=new AddServerimpl(); Registry reg=LocateRegistry.createRegistry(5000); Reg.rebind(AddServer,asim); System.out.println(Server start); String ab[]=reg.list(); System.out.println(the remote object available are ); For(int i=0;i<ab.length;i++) System.out.println(ab[i]); } catch(Exception e) { System.out.println(Exception +e); } } } /* ADDCLIENT PROGRAM */ import java.rmi.*; public class AddClient public static void main(String args[]) { try { SerInt adInt=(SerInt)Naming.lookup(rmi://localhost:5000/AddServer); System.out.println(The first number is+args[0]); Double d1=Double.valueOf(args[0].doubleValue(); System.out.println(:the second number is : +args[1]); double d2=double.ValueOf(args[1].doubleValue(); System.out.println(The sum is :+adint.add(d1,d2)); } catch(Exception e) { System.out.println(Exception : +e); } } OUTPUT C:\jdk1.3>javac SerInt.java C:\jdk1.3\bin>javac AddServerimpl.java

32

C:\jdk1.3\bin>rmic AddServerimpl C:\jdk1.3\bin>javac AddServer.java C:\jdk1.3\bin>java AddServer Server start.. The remote objects available are : AddSErver C:\jdk1.3\bin>javac AddClient.java C:\jdk1.3\bin>java AddClient 1 2 The First number is : 1 The Second number is : 2 The Sumis : 3.0 RESULT: Thus the program for implementing RMI/RPC executes successfully.

EX.NO:- 6 AIM :

SLIDING WINDOW PROTOCOL

To avoid congestion and to ensure reliable data transfer. ALGORITHM: 1) Start the program 2) Sender keeps track of outstanding frames and updates the variables and window as acknowledgements arrive. 3) Receiver sliding window waits for a specific frame to arrive in a specific order and frame arriving out of order is discarded and needs to be resent . 4) Commence transmission. 5) Deal with damaged or lost frame. 6) Deal with damaged or lost acknowledgement. 7) Deal with delayed acknowledgement. 8) Update sender window size. 9) Stop the program. PROGRAM: #include<stdio.h> #include<conio.h>

33

#include<stdlib.h> void main() { int temp1,temp2,temp3,temp4; int winsize=8; int noframes,moreframes,i; int receiver(int); int simulate(int); temp1=0; temp2=0; temp3=0; temp4=0; clrscr(); for(i=0;i<200;i++) rand(); noframes=5; printf("\nNo. of frames is %d",noframes); getch(); moreframes=noframes; while(moreframes>0) { temp1=simulate(winsize); winsize=temp1; temp4+=temp1; if(temp4>noframes) temp4=noframes; for(i=temp3+1;i<=temp4;i++) printf("\nSending frame %d",i); getch(); temp2=receiver(temp1); temp3+=temp2; if(temp3>noframes) temp3=noframes; printf("\nAcknowledgement for the frames upto %d",temp3); getch(); moreframes-=temp2; temp4=temp3; if(winsize<=0) winsize=8; } printf("\nEnd of SLIDING WINDOW PROTOCOL"); getch(); } int receiver(int temp1) { int i;

34

for(i=0;i<100;i++) rand(); i=rand()%temp1; return 1; } int simulate(int winsize) { int temp1,i; for(i=0;i<50;i++) temp1=rand(); if(temp1==0) temp1=simulate(winsize); i=temp1%winsize; if(i==0) return winsize; else return temp1%winsize; } OUTPUT: SENDING FIRST FRONE......1 sending1 Ack(NEXT EXPECTEd FRAME)::2 sending2 Ack(NEXT EXPECTEd FRAME)::3 sending3 Ack(NEXT EXPECTEd FRAME)::4 SENDING......4 SENDING......5 SENDING......6 SENDING......7 TIMEOUT.FOR FRAME4 Resending.....4 Resending.....5 Resending.....6 Resending.....7

35

RESULT: Thus the program to do the SLIDING WINDOW PROTOCOL was executed and output was verified.

EX.NO:-7a AIM:

ROUTING PROTOCOL (OSPF)

To find the shortest path on interior routing protocol based on link state routing Update table inside autonomous systems. ALGORITHM: 1) Start the program. 2) Use the link state routing to update the routing table area. 3) Each router sends the state of its neighbourhood to every other router it does so by flooding. 4) Each neighbour sends the packet to all its neighbours. 5) Each router shares the state of its neighbourhood only when there is a change. 6) From this router calculate the shortest path between itself and each in the network. 7) Stop the program. PROGRAM;#include<stdio.h> #include<conio.h> #define INFIN 999 typedef struct edge

36

{ int wt; }edge; edge connection[10][10]; int n; void main() { int perm[10]; int source,dest,i,j; int shortest(int,int); clrscr(); printf("\nEnter the no. of routers:"); scanf("%d",&n); printf("\nEnter the connection matrix of routers:\n"); for(i=1;i<=n;i++) for(j=1;j<=n;j++) scanf("%d",&connection[i][j].wt); for(i=1;i<=n;i++) for(j=1;j<=n;j++) if(connection[i][j].wt!=INFIN) printf("\npath found between %d and %d with cost : %d",i,j,connection[i][j]); printf("\nEnter the source router:"); scanf("%d",&source); printf("\nEnter the destination router :"); scanf("%d",&dest); printf("\nSHORTEST PATH : %d",shortest(source,dest)); printf("\nPress any key"); getch(); } int shortest(int source,int dest) { int small,perm[10],current,new1,start,temp,i,dist[10],k=1; for(i=1;i<=n;i++) { perm[i]=0; dist[i]=INFIN; erm[source]=1; dist[source]=0; current=source; //printf("%d",current); while(current!=dest) { small=INFINITY; start=dist[current]; for(i=1;i<=n;i++)

37

{ if(perm[i]==0) { new1=start+connection[current][i].wt; if(new1<dist[i]) dist[i]=new1; if(dist[i]<small) { small=dist[i]; temp=i; } } } current=temp; perm[current]=1; } return(small); }

OUTPUT Enter the no. of routers: 2 Enter the connection matrix of routers: 10 15 7 12 path found between 1 and 1 with cost : 10 path found between 1 and 2 with cost : 15 path found between 2 and 1 with cost : 7 path found between 2 and 2 with cost : 12 Enter the source router: 2 Enter the destination router: 1 SHORTEST PATH: 7 Press any key

38

RESULT Thus the program to find the shortest path using OSPF routing protocol was executed and output was verified.

EX.NO:-7b

DISTANCE VECTOR ROUTING PROTOCOL

PROGRAM
#include<stdio.h> main() { int a[50],hc[20],d[20],n,i,h[50],m,d1[50],flag,j,k,flag1,ch; char r[10][20],nn,ht; printf("Enter the number in routing table"); scanf("%d",&n); j=0; for(i=0;i<n;i++) { printf("Enter the Destination:Net"); scanf("%d",&d[i]); printf("Enter the Hop Count:"); scanf("%d",&hc[i]); printf("Enter the Next Router:"); scanf("%s",&r[j][i]); } do { printf("Old routing Table"); printf("\ndestination\thopcount\trouter\n"); for(i=0;i<n;i++)

39

{ printf("\nNet%d\t\t%d\t\t%c",d[i],hc[i],r[0][i]); } ht=r[0][0]; printf("\nEnter the Router Name"); scanf("%s",&nn); r[0][0]=ht; printf("\nEnter the number in message table\n"); scanf("%d",&m); for(i=0;i<m;i++) { printf("Enter the Destination:Net"); scanf("%d",&d1[i]); printf("Enter the HopCount:"); scanf("%d",&h[i]); } printf("Message from %c",nn); for(i=0;i<m;i++) { printf("\nNet%d\t%d",d1[i],h[i]); } for(i=0;i<m;i++) { h[i]=h[i]+1; } printf("\nMessage from %c after increment",nn); for(i=0;i<m;i++) { printf("\n%d\t%d",d1[i],h[i]); } flag=0; for(i=0;i<n;i++) { for(j=0;j<m;j++) { if(d[i]==d1[j]) { flag=1; k=j; } } if(flag==1) {

40

if(r[0][i]==nn) { hc[i]=h[k]; r[0][i]=nn; } else { if(hc[i]>h[i]) { hc[i]=h[i]; r[0][i]=nn; } else { hc[i]=hc[i]; } }} else { hc[i]=hc[i]; } } flag1=0; for(i=0;i<m;i++) { flag1=0; for(j=0;j<n;j++) { if(d1[i]==d[j]) { flag1=1; break; } } if(flag1!=1) { d[n]=d1[i]; hc[n]=h[i]; r[0][n]=nn; n=n+1; } } printf("\nNew routing Table\n");

41

printf("destination\thopcount\trouter\n"); for(i=0;i<n;i++) { printf("\nNet%d\t\t%d\t\t%c",d[i],hc[i],r[0][i]); } printf("\nDo u want to send message from another router"); scanf("%d",&ch); }while(ch!=0); }

OUTPUT Enter the number in routing table3 Enter the Destination:Net10 Enter the Hop Count:1 Enter the Next Router:a Enter the Destination:Net11 Enter the Hop Count:2 Enter the Next Router:b Enter the Destination:Net12 Enter the Hop Count:3 Enter the Next Router:c Old routing Table destination hopcount router

42

Net10 Net11 Net12

1 2 3

a b c

Enter the Router Name a Enter the number in message table 2 Enter the Destination:Net11 Enter the HopCount:3

Enter the Destination:Net12 Enter the HopCount:3 Message from a

Net11 3

Net12 3 Message from a after increment 11 12 4 4

New routing Table destination et10 Net11 Net12 hopcount 1 2 0 router a a

Do u want to send message from another router0

43

RESULT Thus the program to find the shortest path using DSDV routing protocol was executed and output was verified. EX.NO:- 8 AIM: To compare the performance of MAC protocols PERFORMANCE COMPARISION OF MAC PROTOCOLS

ALGORTHIM:Step1: create a new simulator Step2: open the network animator file which is the namfile outman Step3:set the agent trace and the router trace in the ON state and then get the MAC trace as OFF state. Step4: Construct four nodes namely n0,n1,n2 and n3 and the color for trandfering the packets is set as green and red. Step5:The delay time for each nodes and the node agent for each nodes are set. Step6:The droptail queues are used to transfer the packets by capturing them in a queue as specified. PROGRAM :Set ns[new Simulator]

44

$ns color1 Blue $ns color 2 Red Set nf[open out.nam w] $ns namtrace-all $nf Proc finish{} { global ns nf $ns flush_trace close $nf exec nam out.nam & exit 0 } Set no[$ns node] Set n1[$ns node] Set n2[$ns node] Set n3[$ns node] $ns duplex-link $n0 $n2 2 Mb 10ms DropTail $ns duplex-link $n1 $n2 2 Mb 10ms DropTail $ns duplex-link $n2 $n3 1.7 Mb 20ms DropTail $ns queue-link $n0 $n2 $n3 10 $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 $ns duplex-link-op $n2 $n3 queuePOs 0.5 Set tcp[new Agent/TCP] $tcp set class_2 $ns attach-agent $no $tcp Set sink[new Agent/TCPSink] $ns attach-agent $n3 $sink $ns connect $tcp $sink $tcp set fid_1 Set ftp[new Application/FTP] $ftp attach-agent $tcp $ftp set type_FTP Set udp[new Agent/UDP] $ns attach-agent $n1 $udp Set null[new Agent/Null] $ns attach-agent $n3 $null $ns connect $udp $null $udp set fid_2 Set cbr [new Application/Traffic/CBR] $cbr attach_agent $uDP $cbr set type_CBR $cbr set packet_size_1000 $cbr set rate_1mb

45

$cbr set random_false $ns at 0.1 $cbr start $ns at 1.0 $ftp start $ns at 4.0 $ftp stopt $ns at 4.5 $cbr stop $ns at 4.5 $ns detach-agent $n0 $tcp;$ns detach-agent $n3 $sink $ns at 5.0 finish Puts CBR packet size=[$cbr set packet_size_] Puts CBR interval=[$cbr set interval_] $ns run RESULT : Thus the program for comparision of MAC protocols using NS-2 simulators has been executed successfully. EX.NO:- 9 PERFORMANCE COMPARISION OF ROUTING PROTOCOLS

AIM: To compare the performance of Routing protocols PROGRAM:AODV Set val(mn) Ser val(rp) Set Val(x) Set Val(y) 10 AODV 800 800 ; # number of mobilenodes ;#routing protocol

Set as[New Simulator] #ns-random 0 Set f[open aodv10,tr,w] $ns trace-all sf Set namtrace[open aodv10,nam w] $ns namtrace-all-wireless $namtrace $val(x) $val(y) Set f0 [open packets_received.tr w] Set f1 [open packets_lost.tr w] Set f2 [open proj_out2. tr w]

46

Set f3 [open proj_out3.tr w] Set topo [new Topography] $topo load_flatgrid 800 800 create-god $val(nn) Set chan_1 [new $val(chan)] Set chan_2 [new $val(chan)] Set chan_3 [new $val(chan)] Set chan_4 [new $val(chan)] Set chan_5 [new $val(chan)] Set chan_6 [new $val(chan)] # CONFIGURE AND CREATE NODES

DSR Set val(nn) Set val(rp) Set val(x) Set val(x) #set val(stop) 10 DSR 800 800 10.0

set ns[new Simulator] #ns-random 0 Set f[open dsr15.tr,w] $ns trace-all sf Set namtrace[open dsr15.tr w] $ns namtrace-all-wireless $namtrace $val(x) $val(y) Set f0 [open packets_received.tr w] Set f1 [open packets_lost.tr w] Set f2 [open proj_out2. tr w] Set f3 [open proj_out3.tr w] Set topo [new Topography] $topo load_flatgrid 800 800 create-god $val(nn) Set chan_1 [new $val(chan)] Set chan_2 [new $val(chan)] Set chan_3 [new $val(chan)] Set chan_4 [new $val(chan)]

47

Set chan_5 [new $val(chan)] Set chan_6 [new $val(chan)] Set chan_7 [new $val(chan)] Set chan_8 [new $val(chan)] Set chan_9 [new $val(chan)] Set chan_10 [new $val(chan)] #CONFIGURE AND CREATE NODES

AODV NAM Network Simulator

DSR NAM Network Simulator

48

X Graph 0f 10 seconds simulation time of AODV

X Graph 0f 10 seconds simulation time of DSR

49

RESULT :Thus the comparing the performance of AODV and DSR is executes successfully.

EX.NO:- 10

STUDY OF UDP PERFORMANCE

Aim: To study about UDP Performance The User Datagram Protocol (UDP) is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special transmission channels or data paths. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768. UDP uses a simple transmission model without implicit hand-shaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is

50

preferable to waiting for delayed packets, which may not be an option in a real-time system. If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose. UDP's stateless nature is also useful for servers answering small queries from huge numbers of clients. Unlike TCP, UDP is compatible with packet broadcast (sending to all on local network) and multicasting (send to all subscribers). Common network applications that use UDP include: the Domain Name System (DNS), streaming media applications such as IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP) and many online games.

Service ports Main article: TCP and UDP port UDP applications use datagram sockets to establish host-to-host communications. An application binds a socket to its endpoint of data transmission, which is a combination of an IP address and a service port. A port is a software structure that is identified by the port number, a 16 bit integer value, allowing for port numbers between 0 and 65535. Port 0 is reserved, but is a permissible source port value if the sending process does not expect messages in response. The Internet Assigned Numbers Authority has divided port numbers into three ranges. Port numbers 0 through 1023 are used for common, well-known services. On Unix-like operating systems, using one of these ports requires superuser operating permission. Port numbers 1024 through 49151 are the registered ports used for IANA-registered services. Ports 49152 through 65535 are dynamic ports that are not officially for any specific service, and can be used for any purpose. They are also used as ephemeral ports, from

51

which software running on the host may randomly choose a port in order to define itself. In effect, they are used as temporary ports primarily by clients when communicating with servers. Packet structure UDP is a minimal message-oriented Transport Layer protocol that is documented in IETF RFC 768. UDP provides no guarantees to the upper layer protocol for message delivery and the UDP protocol layer retains no state of UDP messages once sent. For this reason, UDP is sometimes referred to as Unreliable Datagram Protocol.[citation needed]

UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload.[3] If transmission reliability is desired, it must be implemented in the user's application. bits 0 15 0 Source Port Number 32 Length 64 Data 16 31 Destination Port Number Checksum

The UDP header consists of 4 fields, all of which are 2 bytes (16 bits). The use of two of those is optional in IPv4 (pink background in table). In IPv6 only the source port is optional (see below). Source port number

52

This field identifies the sender's port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the server, the port number is likely to be a well-known port number. Destination port number This field identifies the receiver's port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.

Length A field that specifies the length in bytes of the entire datagram: header and data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 8 byte UDP header 20 byte IP header). Checksum The checksum field is used for error-checking of the header and data. If no checksum is generated by the transmitter, the field uses the value all-zeros. This field is not optional for IPv6. Checksum computation The method used to compute the checksum is defined in RFC 768: Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.

53

In other words, all 16-bit words are summed using one's complement arithmetic. The sum is then one's complemented to yield the value of the UDP checksum field. If the checksum calculation results in the value zero (all 16 bits 0) it should be sent as the one's complement (all 1's). The difference between IPv4 and IPv6 is in the data used to compute the checksum.

IPv4 PSEUDO-HEADER When UDP runs over IPv4, the checksum is computed using a PSEUDO-HEADER that contains some of the same information from the real IPv4 header. The PSEUDOHEADER is not the real IPv4 header used to send an IP packet. The following table defines the PSEUDO-HEADER used only for the checksum calculation. bits 0 7 0 8 15 16 23 24 31

Source address

32 Destination address 64 Zeros Protocol UDP length Destination Port Checksum

96 Source Port 128 Length 160 Data

54

When computing the checksum, again a PSEUDO-HEADER is used that mimics the real IPv6 header: The source address is the one in the IPv6 header. The destination address is the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header; otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header. The value of the Next Header field is the protocol value for UDP: 17. The UDP length field is the length of the UDP header and data.

Reliability and congestion control solutions Lacking reliability, UDP applications must generally be willing to accept some loss, errors or duplication. Some applications such as TFTP may add rudimentary reliability mechanisms into the application layer as needed. Most often, UDP applications do not require reliability mechanisms and may even be hindered by them. Streaming media, real-time multiplayer games and voice over IP (VoIP) are examples of applications that often use UDP. If an application requires a high degree of reliability, a protocol such as the Transmission Control Protocol or erasure codes may be used instead. Lacking any congestion avoidance and control mechanisms, network-based mechanisms are required to minimize potential congestion collapse effects of uncontrolled, high rate UDP traffic loads. In other words, since UDP senders cannot detect congestion, networkbased elements such as routers using packet queuing and dropping techniques will often be the only tool available to slow down excessive UDP traffic. The Datagram Congestion Control Protocol (DCCP) is being designed as a partial solution to this potential problem by adding end host TCP-friendly congestion control behavior to high-rate UDP streams such as streaming media. Comparison of UDP and TCP

55

Main article: Transport Layer Transmission Control Protocol is a connection-oriented protocol, which means that it requires handshaking to set up end-to-end communications. Once a connection is set up user data may be sent bi-directionally over the connection.

Reliable TCP manages message acknowledgment, retransmission and

timeout. Multiple attempts to deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there's either no missing data, or, in case of multiple timeouts, the connection is dropped.

Ordered if two messages are sent over a connection in sequence, the

first message will reach the receiving application first. When data segments arrive in the wrong order, TCP buffers the out-of-order data until all data can be properly re-ordered and delivered to the application.

Heavyweight TCP requires three packets to set up a socket connection,

before any user data can be sent. TCP handles reliability and congestion control.

Streaming Data is read as a byte stream, no distinguishing indications are

transmitted to signal message (segment) boundaries. UDP is a simpler message-based connectionless protocol. Connectionless protocols do not set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver.

Unreliable When a message is sent, it cannot be known if it will reach its

destination; it could get lost along the way. There is no concept of acknowledgment, retransmission or timeout.

56

Not ordered If two messages are sent to the same recipient, the order in which Lightweight There is no ordering of messages, no tracking connections, etc. It is Datagrams Packets are sent individually and are checked for integrity only if

they arrive cannot be predicted.

a small transport layer designed on top of IP.

they arrive. Packets have definite boundaries which are honored upon receipt, meaning a read operation at the receiver socket will yield an entire message as it was originally sent.

RESULT : Thus the performance of UDP is studied Sucessfully.

EX.NO:- 11

STUDY OF TCP PERFORMANCE

Aim: To study about TCP Performance The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP. TCP provides the service of exchanging data directly between two network hosts, whereas IP handles addressing and routing message across one or more networks. In particular, TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. TCP is the protocol that major Internet applications rely on, applications such as the World Wide Web, email, and file transfer. Other applications, which do not require reliable data stream service, may use the User Datagram Protocol (UDP) which provides a datagram service that emphasizes reduced latency over reliability Network function

57

TCP provides a communication service at an intermediate level between an application program and the Internet Protocol (IP). That is, when an application program desires to send a large chunk of data across the Internet using IP, instead of breaking the data into IP-sized pieces and issuing a series of IP requests, the software can issue a single request to TCP and let TCP handle the IP details. IP works by exchanging pieces of information called packets. A packet is a sequence of octets and consists of a header followed by a body. The header describes the packet's destination and, optionally, the routers to use for forwarding until it arrives at its destination. The body contains the data IP is transmitting.

Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost, duplicated, or delivered out of order. TCP detects these problems, requests retransmission of lost packets, rearranges out-of-order packets, and even helps minimize network congestion to reduce the occurrence of the other problems. Once the TCP receiver has finally reassembled a perfect copy of the data originally transmitted, it passes that datagram to the application program. Thus, TCP abstracts the application's communication from the underlying networking details. TCP is utilized extensively by many of the Internet's most popular applications, including the World Wide Web (WWW), E-mail, File Transfer Protocol, Secure Shell, peer-to-peer file sharing, and some streaming media applications. TCP is optimized for accurate delivery rather than timely delivery, and therefore, TCP sometimes incurs relatively long delays (in the order of seconds) while waiting for out-of-order messages or retransmissions of lost messages. It is not particularly suitable for real-time applications such as Voice over IP. For such applications, protocols like the Real-time Transport Protocol (RTP) running over the User Datagram Protocol (UDP) are usually recommended instead.

58

TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another without duplication or losing data. Since packet transfer is not reliable, a technique known as positive acknowledgment with retransmission is used to guarantee reliability of packet transfers. This fundamental technique requires the receiver to respond with an acknowledgment message as it receives the data. The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet. The sender also keeps a timer from when the packet was sent, and retransmits a packet if the timer expires. The timer is needed in case a packet gets lost or corrupted. TCP consists of a set of rules: for the protocol, that are used with the Internet Protocol, and for the IP, to send data "in a form of message units" between computers over the Internet. At the same time that IP takes care of handling the actual delivery of the data,

TCP takes care of keeping track of the individual units of data transmission, called segments, that a message is divided into for efficient routing through the network. For example, when an HTML file is sent from a Web server, the TCP software layer of that server divides the sequence of octets of the file into segments and forwards them individually to the IP software layer (Internet Layer). The Internet Layer encapsulates each TCP segment into an IP packet by adding a header that includes (among other data) the destination IP address. Even though every packet has the same destination address, they can be routed on different paths through the network. When the client program on the destination computer receives them, the TCP layer (Transport Layer) reassembles the individual segments and ensures they are correctly ordered and error free as it streams them to an application. Protocol operation A Simplified TCP State Diagram. See TCP EFSM diagram for a more detailed state diagram including the states inside the ESTABLISHED state.

59

TCP protocol operations may be divided into three phases. Connections must be properly established in a multi-step handshake process (connection establishment) before entering the data transfer phase. After data transmission is completed, the connection termination closes established virtual circuits and releases all allocated resources. A TCP connection is managed by an operating system through a programming interface that represents the local end-point for communications, the Internet socket. During the lifetime of a TCP connection it undergoes a series of state changes:

1. LISTEN : In case of a server, waiting for a connection request from any remote client. 2. SYN-SENT : waiting for the remote peer to send back a TCP segment with the SYN and ACK flags set. (usually set by TCP clients) 3. SYN-RECEIVED : waiting for the remote peer to send back an acknowledgment after having sent back a connection acknowledgment to the remote peer. (usually set by TCP servers) 4. ESTABLISHED : the port is ready to receive/send data from/to the remote peer. 5. FIN-WAIT-1 6. FIN-WAIT-2 7. CLOSE-WAIT 8. CLOSING 9. LAST-ACK
10. TIME-WAIT : represents waiting for enough time to pass to be sure the remote

peer received the acknowledgment of its connection termination request. According to RFC 793 a connection can stay in TIME-WAIT for a maximum of four minutes.
11. CLOSEDConnection establishment

60

To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:
1. SYN: The active open is performed by the client sending a SYN to the server. It

sets the segment's sequence number to a random value A.

2. SYN-ACK:

In response, the server replies with a SYN-ACK. The

acknowledgment number is set to one more than the received sequence number (A + 1), and the sequence number that the server chooses for the packet is another random number, B.

3. ACK: Finally, the client sends an ACK back to the server. The sequence number

is set to the received acknowledgement value i.e. A + 1, and the acknowledgement number is set to one more than the received sequence number i.e. B + 1. At this point, both the client and server have received an acknowledgment of the connection. Data transfer There are a few key features that set TCP apart from User Datagram Protocol:

Ordered data transfer - the destination host rearranges according to sequence Retransmission of lost packets - any cumulative stream not acknowledged is Error-free data transfer (The checksum in UDP is optional) Flow control - limits the rate a sender transfers data to guarantee reliable delivery.

number

retransmitted

The receiver continually hints the sender on how much data can be received (controlled by the sliding window). When the receiving host's buffer fills, the next

61

acknowledgment contains a 0 in the window size, to stop transfer and allow the data in the buffer to be processed.

Congestion control

Reliable transmission TCP uses a sequence number to identify each byte of data. The sequence number identifies the order of the bytes sent from each computer so that the data can be reconstructed in order, regardless of any fragmentation, disordering, or packet loss that may occur during transmission. For every payload byte transmitted the sequence number must be incremented. In the first two steps of the 3-way handshake, both computers exchange an initial sequence number (ISN). This number can be arbitrary, and should in fact be unpredictable to defend against TCP Sequence Prediction Attacks.

TCP primarily uses a cumulative acknowledgment scheme, where the receiver sends an acknowledgment signifying that the receiver has received all data preceding the acknowledged sequence number. Essentially, the first byte in a segment's data field is assigned a sequence number, which is inserted in the sequence number field, and the receiver sends an acknowledgment specifying the sequence number of the next byte they expect to receive. In addition to cumulative acknowledgments, TCP receivers can also send selective acknowledgments to provide further information (see selective acknowledgments). Maximum segment size The Maximum segment size (MSS) is the largest amount of data, specified in bytes, that TCP is willing to send in a single segment. For best performance, the MSS should be set small enough to avoid IP fragmentation, which can lead to excessive retransmissions if there is packet loss. To try to accomplish this, typically the MSS is negotiated using the MSS option when the TCP connection is established, in which case it is determined by the

62

maximum transmission unit (MTU) size of the data link layer of the networks to which the sender and receiver are directly attached. Furthermore, TCP senders can use Path MTU discovery to infer the minimum MTU along the network path between the sender and receiver, and use this to dynamically adjust the MSS to avoid IP fragmentation within the network. TCP Timestamps TCP timestamps, defined in RFC 1323, help TCP compute the round-trip time between the sender and receiver. Timestamp options include a 4-byte timestamp value, where the sender inserts its current value of its timestamp clock, and a 4-byte echo reply timestamp value, where the receiver generally inserts the most recent timestamp value that it has received. The sender uses the echo reply timestamp in an acknowledgment to compute the total elapsed time since the acknowledged segment was sent. TCP timestamps are also used to help in the case where TCP sequence numbers encounter their 232 bound and "wrap around" the sequence number space. This scheme is known as Protect Against Wrapped Sequence numbers, or PAWS (see RFC 1323 for details). Furthermore, the Eifel detection algorithm, defined in RFC 3522, which detects unnecessary loss recovery Connection termination The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can. The terminating side should continue reading the data until the other side terminates as well.

63

It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method. It is possible for both hosts to send FINs simultaneously then both just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done in parallel for both directions. Some host TCP stacks may implement a "half-duplex" close sequence, as Linux or HPUX do. If such a host actively closes a connection but still has not read all the incoming data the stack already received from the link, this host sends a RST instead of a FIN (Section 4.2.2.13 in RFC 1122). This allows a TCP application to be sure the remote application has read all the data the former sentwaiting the FIN from the remote side, when it actively closes the connection. However, the remote TCP stack cannot

distinguish between a Connection Aborting RST and this Data Loss RST. Both cause the remote stack to throw away all the data it received, but that the application still didn't read.[clarification needed] Some application protocols may violate the OSI model layers, using the TCP open/close handshaking for the application protocol open/close handshaking - these may find the RST problem on active close. As an example: s = connect(remote); send(s, data); close(s); For a usual program flow like above, a TCP/IP stack like that described above does not guarantee that all the data arrives to the other application unless the programmer is sure that the remote side will not send anything.

64

TCP ports Main article: TCP and UDP port TCP uses the notion of port numbers to identify sending and receiving application end-points on a host, or Internet sockets. Each side of a TCP connection has an associated 16-bit unsigned port number (0-65535) reserved by the sending or receiving application. Arriving TCP data packets are identified as belonging to a specific TCP connection by its sockets, that is, the combination of source host address, source port, destination host address, and destination port. This means that a server computer can provide several clients with several services simultaneously, as long as a client takes care of initiating any simultaneous connections to one destination port from different source ports.

Port numbers are categorized into three basic categories: well-known, registered, and dynamic/private. The well-known ports are assigned by the Internet Assigned Numbers Authority (IANA) and are typically used by system-level or root processes. Well-known applications running as servers and passively listening for connections typically use these ports. Some examples include: FTP (21), SSH (22), TELNET (23), SMTP (25) and HTTP (80). Registered ports are typically used by end user applications as ephemeral source ports when contacting servers, but they can also identify named services that have been registered by a third

65

RESULT :Thus the performance of TCP is studied successfully.

66