Aims &algorithms

SIMULATION OF ARP/RARP AIM To write a program for simulation of ARP/RARP. ALGORITHM SERVER Step1: Create a server socket and client socket. Step2: Create a process. Step3: Get request from client. Step4: Run the ipconfig –all command to find the physical address. Step5: Send the physical address to the client. Step6: Close server socket and client socket connection. CLIENT Step1: Create a client socket connection with specified port. Step2: Read the message from the client. Step3: Send the System name to the server. Step4: Read the message from the server. Step5: Print the message. Step6: Close the client connection.

RESULT Thus the program for simulation of ARP/RARP is executed and the output is verified successfully.

BIT STUFFING AIM To write a program to perform bit stuffing. ALGORITHM Step1: Read the input message M to be transmitted in binary form. Step2: If there is continuously 5 one’s, append one 0 after 5th one. Step3: Resulting string is the message with bit stuffing.

RESULT Thus the program for bit stuffing is executed and the output is verified successfully.

FILE TRANSFERRING USING TCP AIM To write a program for transferring a file using TCP. ALGORITHM SERVER: Step1: Start the program Step2: Create an unnamed socket for the server using parameters AF_INET as domain and SOCK_STREAM as type. Step3: Get the server port number. Step4: Register the host address to the systems using bind () system call in server side. Step5: Create a connection queue and wait for clients using listen () system call with the number of clients requests as parameter. Step6: Create a child process using fork () system call. Step7: If the process identification number is equal to zero accept the connection using the accept() system call when the client request for the connection. Step8: If pid is not equal to zero then exit the process. Step9: Stop the program execution. CLIENT: Step1: Start the program. Step2: Create an unnamed socket for the client using parameters AF_INET as domain and SOCK_STREAM as type. Step3: Get the server port number. Step4: Now connect the socket to server using connect () system call. Step5: Enter the file name. Step6: The file is transferred from client to server using send () function. Step7: Print the contents of the file in new file. Step8: Stop the program.

RESULT

Thus the program for transferring a file from one machine to another machine using TCP is executed and the output is verified successfully.

SIMULATION OF WEBPAGE DOWNLOADING AIM To write a program for simulation of webpage downloading. ALGORITHM Step1: Set a server port as 80. Step2: Using HTTP services create a Socket for server by specifying the serverport Step3: Use HTTP socket for connecting the client to the URL. Step4: Use BufferedReader to output stream to place the response from the server by the client. Step5: Close the Connection as soon the request is been serviced Use Malformed URL exception If any errors in grabbing the server

RESULT. Thus the program for webpage downloading is executed and the output is verified successfully.

CLIENT-SERVER CHAT PROGRAM USING TCP AIM To write a program for implementing Client-Server Chat using TCP. ALGORITHM SERVER Step1:Start the program. Step2: Create an unnamed socket for the server using the Parameters AF_INET as domain and the SOCK_STREAM as type. Step3: Name the socket using bind() system call with the parameters server_sockfd and the server address(sin_addr and sin_sport). Step4: Create a connection queue and wait for clients using the listen() system call with number of clients request as parameters. Step5: Accept the connection using accept() system call when client requests for connection. Step6: Get the message which has to be sent to the client and check that it is not equal to ‘Bye’. Step7: If the message is not equal to‘Bye’ then write the message to the client and goto step6. Step8: If the message is ‘Bye’ then terminate the Process. Step9: Stop the program execution. CLIENT Step1: Start the program. Step2:Create an unnamed socket for client using socket() system. Step3: Call with parameters AF_INET as domain and SOCK_STREAM as type. Step4: Name the socket using bind() system call. Step5: Now connect the socket to server using connect() system call. Step6: Read the message from the server socket and compare it with ‘Bye’. Step7: If the message is not equal to ‘Bye’ then print the message to the serverm output device and repeat the steps 6&7. Step8: Get the message from the client side. Step9: Write the message is equal to server sockfd and goto step4. Step10: If the message is equal to ‘Bye’ then print good bye message and terminate the process. Step11: Stop the program.

RESULT Thus the program for chat using TCP is executed and the output is verified

Successfully.

CRC COMPUTATION AIM To write a program to perform CRC Computation ALGORITHM CRC Computation: Step1: Read the input message M to be transmitted in polynomial form M(x) and convert to binary form M. Step2: Read a width W (maximum power of G(x)), and a poly G(x) (of width W) and convert G(x) to binary form G. Step3: Append W zero bits to the message at the end. Call this M’. Step4: Divide M’ by G using CRC arithmetic. The remainder is the checksum. Step5: Checksum is then appended to the message at the end and the result is transmitted. CRC Error Detection: At the other end, the receiver can do one of two things: Case a: Separate the message and checksum. Calculate the checksum for the message (after appending W zeros) and compare the two checksums. Case b: Checksum the whole lot (without appending zeros) and see if it comes out as zero! Case b: Read the received input message M in polynomial form M(x) and covert to binary form M. Read a width W (maximum power of G(x)), and a poly G(x) (of width W) and convert G(x) to binary form G. Divide M by G using CRC arithmetic.

RESULT:Thus the program for CRC Computation is executed and the output is verified successfully.

SLIDING WINDOW PROTOCOL AIM To write a C program for the simulation of sliding window protocol ALGORITHM SENDER Step 1: Start the program. Step 2: Create a socket for the sender and bind it with the receiver. Step 3: Set the size of the window. Step 4: Send the frames up to the size of the window to the receiver. Step 5: If any of the frames are lost then retransmit those frames to the receiver. Step6: Stop the execution. RECEIVER Step1: Start the program. Step2: Create a socket for the receiver, bind it and listen for the frames from the sender. Step3: If all the frames are successfully received, send the acknowledgement for the last frame to the sender. Step4: If any of the frames is lost, then send the acknowledgement of the last frame, which was successfully received. Step5: Keep on receiving and acknowledging the frames until the sender sends. Step6: Stop the program execution.

RESULT Thus the program for simulation of Sliding window Protocol has been executed and the output is verified successfully.

DOMAIN NAME SYSTEM AIM To write a program for the simulation of Domain Name System. ALGORITHM SERVER Step1: Start the program. Step2: Create the socket for the server. Step3: Bind the socket to the port. Step4: Listen for the incoming client connection. Step5: Receive the IP address from the client to be resolved. Step6: Get the domain name for the client. Step7: Check the existence of the domain in the server. Step8: If domain matches then send the corresponding address to the client. Step9: Stop the program execution. CLIENT: Step1: Start the Program. Step2: Create the socket for the client. Step3: Connect the socket to the Server. Step4: Send the host name to the server to be resolved. Step5: If the server corresponds then print the address and terminate the process.

RESULT Thus the program for the simulation of Domain Name System has been executed and the output is verified successfully.

Network Simulator AIM To study the Network Simulator NS2 Network simulator 2 Network simulator 2(NS2) is a discrete event simulator targeted at networking research. It provides support for simulation of TCP, routing and multicast protocols over wired and wireless networks. Currently the development of NS2 is supported by DAPRA, NSF and ACIRI..NS21 can be used for non-commercial use free of charge. Architecture Network simulator 2’s architecture is object-oriented (C++/OTc10. it tries to achieve scalability as well as extensibility through of control and detailed protocol functionally. C++ is used for detailed protocol implementation for which simulation in which runtime efficiency is not that important, but the possibility to quickly modify simulation is very useful. The main drawbacks resulting from this approach are that the user has to know C++ as well as Otcl, and debugging of simulations becomes more difficult. In the tool TclCL class hierarchy is used to ling together C++ and OTcl. After linking of C++ member variables to OTcl object variables by using the bind member function, C++ variables can be modified through OTcl directly. Other commands from Otcl are delivered to C++ object through member function TclObject:: command(int argc, const char *argv). Class tcl can be used to invoke OTcl procedures from C++ code. This can be useful for example in passing a result string to Otcl. Simulator Network simulator 2 is a discrete event simulator. It contains three types os discrete event schedulers: list, heap, and hash based calendar. nS2 also provides default implementation for network nodes, links between nodes, routing algorithm, some transport level protocols(especially UDP and many different variants of TCP) and some traffic generators. Adding functionality to these objects can extend the simulator. NS2 also contains some useful utilities which includes e.g Tcl debugger simulation scenario generators and simulation topology generator. Tcl debugger is used to debug Tcl scripts and it might become necessary if one is using large scripts to control a simulations. Tcl debugger is however not automatically with NS2 but it can be installed later. One drawback of using Tcl debugger is that it is dependent on used Tcl version and also NS 2 version,

For topology generation there are four choices: NTG, RTG,GT-ITM and THERS packages. At least GT-ITM is a part of the NS2 distribution. It requires Knuth web and SGB software to work together with NS2, but these software Packages are also part of the NS2 distribution. With these topology generators one can create large network topologies without the need to define the whole topology by hand. Simulation scenario generator can be used to create traffic between bodes. When simulating wireless networks, the scenario generator can also be used to generate files that define the movement of nodes. Emulator It is also possible to use network simulator 2 as and emulator. Currently emulator support is available for FreeBSD operating system only. Emulator can be used to connect the tool to a live network. When the emulator is used one must use real-time scheduler instead of scheduler instead of schedulers mentioned in the preceding chapter. It connects the simulation time to real time. If the scheduler falls behind emulation fails. The emulator has two modes. In protocol modes the emulator interprets received traffic (e.g ICMPP Echo). In opaque mode received data is not interpreted. The emulator is connecting to live network on the IP level. Support Software Nam-VINT/LBL Network Animator Nam is a Tcl/TK based animation tool for viewing network simulation traces and real world packet trace data. It support topology layout, packets level animation, and various data inspection tools. Nam began at LBL. It has evolved substantially over the past few years. Nam developed efforts is now an ongoing collaboration with the VINT project. The first step to use nam is to produce a trace file. The trace file should contain topology information, for example nodes, links and packet traces. During an NS2 simulation, user can produce topology configuration layout information a packet traces using tracing events in NS2. When the trace file is generated, it is ready to animated by nam. Upon startup, nam will read the trace file, create topology, pop up a window, do layout if it is necessary and then pause at the time of the first packet in the trace file. Nam provides control over many aspects of animation through its user interface. Nam does animated using the following building blocks: node, link, queue, packet, agent, and monitor. X Graph-an animating plotting program

One part of the ns-allinone package is xgraph, a plotting program which can be used to create graphic representations of simulation results. XGraph plotting program written by David Harrison at UC Berkeley. The original program supported line plots(and restricted surface plots) on any X11 display, and had several useful features, including being able to zoom on a region with the mouse. First, it does crude animation of data sets. The animation only pages through data sets in the order in which they are loaded. It is quite crude, but useful if all your data sets are in one file in time order, and are output at uniform times. Also, they code will take derivatives of your data numerically and display those derivatives in a new XGraph window. These new features have been made a couple of years ago, and have no longer been supported. There are a few annoying problems which haven’t been cleaned up yet, the most aggravating of which is a problem with handling expose events, which sometimes forces the window to animate or refresh four or five times when it is exposed. Also, the derivative routines have not been rigorously tested. Finally, the labels are occasionally wrong when doing log plots. Existing Protocol Testing Using NS2(Minor assignment) How to begin The first step in the simulation is to acquire an instance of the simulator class. Instances of objects in classes are created and destroyed in NS2 using the new and delete methods. For example, an instance of the simulator object is created by the following command: e.g, set ns [new simulator] A network topology is realized using three primitive building blocks: nodes, links, and agents. The simulator class has methods to create/configure each of these building blocks. Nodes are created with the node simulator method that automatically assigns a unique address to each node. Links are created between nodes to form a network bidirectional links respectively. Agents are the objects that are actively drive the simulation. Agents can be thought of as the processes and /or transport entities that turn on nodes that may be end hosts or routers. Traffic sources and sinks, dynamic routing modules and the various protocol modules are all example of agents. Agents are created by instantiating objects in the subclass of class agent i.e., Agent/type where specifies the nature of the agent. For example, TCP agent is created using the command: Set tcp [new Agent/TCP] Once the agents are created, they are attached to nodes with the attach–agent Simulator method. Each agent is automatically assigned a port number unique across all agents may have sources attached to them while others may generate their own data. For example, you can attach ftp and telnet sources to tcp agents but constant bitrate agents using the attach-source and attach-traffic agents methods. Each object has some configuration parameters associated with it that can be modified. Configuration parameters are instance variable of the object. These parameters are initialized during startup to default values that can simply be return the

default window size for the tcp project. The default values for that object can be explicitly overridden by simple assignment either before a simulation is in progress. For example the window-size for a particular TCP session can be changed in the following manner. $tcp set window_25

The default values for the configuration parameters of all the class objects subsequently created can also be changed by simple assignment. For example, we can say: Agent/TCP set window_30 to make all future tcp agent creations default to a window size of 30. Events are scheduled in NS2 using the simulator method that allows OTcl callbacks provide a flexible simulation mechanism: they can be used to start or stop sources, dump statistics, instantiate link failures, reconfigure the network topology etc. the simulation is started via the run method continues until there are no more events processed. At this time, the original invocation of the run command returns and he script can exit or invoke another simulation run after possible reconfiguration. Alternatively, the simulation can be prematurely halted by invoking the stop command or by exiting the script with Tcl’s standard exit command. Packets are forwarded along the shortest path route from a source to a destination, where the distance metric is the sum of costs of the links traversed from the sources to destination. The cost of a link is 1 by default: the distance metric is simply the hop count in this case. The cost of the link can be changed with the cost simulator method. A static topology model is used as the default in NS2 in which the states of nodes/links do not change during the course of a simulation. Also static unicast routing is the default in which the routes are recomputed over the entire topology once prior to starting the simulation. About TCP The TCP agent does not generate any application data on its own: instead, the simulation user can connect any traffic generation module to the TCP agent to generate data. Two applications are commonly used for TCP:FTP and telnet. FTP represents a bulk data transfer of large size, and telnet chooses its transfer sizes randomly from tclib. There are two major types of TCP agents: one-way agents and a two-way agent, One –way agents are further subdivided into a set of TCP senders and receivers. The two-way agent is symmetric. About the minor assignment

The existing protocol testing assignment is planned to be an easy one. The primary task is to write a simulation script for a specific case. Starting the use of NS2 is more difficult than some other simulation program because with NS2 you have to build a network you want to simulate by using a script. This is more difficult with some other tool where you have a good GUI. The difficulty when you want to make some new experiments: the only error message from NS2 will be that it will not start simulation. With GUI we can find the error and we also rectify it. The best way to start NS2 is to read Marc Greis’s tutorial available on the NS2 webpage mentioned in the beginning of the document. This has been also mentioned in the work of description together with some other links. The idea is to get some picture

about NS2 and learn basics about how to write simulation scripts. The simulation concentrates on TCP sliding Window Flow Control and the Slow Start mechanism. These have been chosen because they are familiar features of TCP. Protocol implementation using NS2 (major assignment) In the protocol implementation assignment the student is asked to implement a Go-Back-N-ARQ (Automatic Repeat Request) protocol. A state machine description of the protocol agent is given as well as some example. Usually every software developer working with NS2 should have his/her own installation of the tool. Using this approach with telecommunications Laboratory course would mean that lots os disk space would be needed. That is why a modified makefile would be written. When using this makefile all the students can use some installation of NS2. also modifications to files that need to be modified when adding a new protocol to be modified when adding a new protocol to NS2 have been done excepts modifications to file ns-default tcl. This modification cannot be done only one installation of NS2 is used. Template files for students working with the assignment contain an implementation of a needed timer. There is also hints chapter in the assignment specification in order to help the students to find way to do things with NS2 without a through inspection of ns manual. Installation There was some problem during installation of the software from all in pone package. Two lines in the NS2 sources code had to be edited manually due to differences in socket handling in Linux and for example in Sun. modifications were done based on instructions represented in the NS2 mailing list. Both modifications were made to file ns-2.1bs/inde-utis/webtrace-conv/ucb/utils.cc. Line 358 If((ns=accept(s,(struct sodkaddr??*)&from, &fromlen)<0)

Was replaced by line If((ns=accept(s,(struct suchaddr*)(&from ),(socklen_t*)(&fromlen)))<0) And line 477 If(getsockname(s,&sockname,&len)<0) was replaced by line if(getsockname(s,&sockname,(socklen_t*)(&len))<0) Validation scripts that are run after the installation reported also some minor warning due to rounding up error. According to NA2 documentation these should not however be considered as fatal. One drawback of NS2 is that is dependent of several independent software packages e.g NS2 itself, Tcl and zlib linraries. This might cause problems if user’s environment already contains some of these packages and their versions don’t work together. However when NS2 is installed under one directory. This result that one should able to resolve potential problem with users environment as well as keep track of the used versions of software packages. Existing protocol Testing Learning of how too write tcl-scripts takes some time. It is helpful when you already know the basics. There is also some example files available in the tcl/ex/directory, but unfortunately they haven’t been updated which means that most of them don’t work. When you have something wrong with your script and you are going to start the simulation, you will not get any clear error message from NS2. Implementation of new protocol to NS2 is quite easy as long as the protocol’s state machine is not complicated. NS2 does not support state machine like programming of protocols. Addition of new PDU structure to the tool is also quite easy. NS2 does not however give good support for PDU encoding and decoding on byte level because of the structure used in the tool to represent a PDU. Simple protocols are quite quickly implemented because the tool provides default implementation e.g. timers and queues. Documentation of NS2 is quite poor and that is why one’s first implementations using the tool could take some time. Ns manual is also a bit too general on several key subjects which are needed when implementing protocols. Some features are not documented at all. When compared to other simulation tools NS2 seems also quite primitive-it lacks graphical user interface and control of the simulations is done using Tcl which is sometimes quite hard to debug.

RESULT Thus the study of Network Simulator NS2 is studied successfully.

OPTIMIZING NETWORK ENGINEERING TOOL (OPNET) AIM To study the Network simulator OPNET. OPNET OPNET is an engineering system capable of simulating large communication networks with detailed protocol modeling and performance analysis. Features include graphical specification of models, a dynamic, event-scheduled simulation Kernel, integrated data analysis tools and hierarchical, object based modeling. It is a commercial tool by MIL3, Inc. Models built with OPNET are hierarchically structured, see the following figure. At the lowest level the process domain is structured as a finite state machine (FSM).The FSM can be structured with the help of a graphical editor that allows the user to specify the relation between the single states and their transitions. The single states and the transition conditions can then be programmed with a C like language called proto-C. Processes that were specified in the process domain, different source and destination modules offered by OPNET as a well as data generators and queues can then be grouped into nodes in the node domain. Nodes can now be connected with each other to build up different network architectures in the network domain. OPNET it self can be divided into three large domains:

Network domain

Node domain

Link domain

Process domain

Specification domain :in this domain different editors are offered that enable the user to specify in a graphical manner the different levels of the models. Editors for programming the finite state machine and parameters specification are provided as well Simulation domain: The simulation kernel offers the users a procedures library that simplify various problem related to the subject of dada communication like the manipulation of dada packets Analysis domain:OPNET provides various tools allow for the collection of dada, their graphical presentati0n and analysis. OPNET SIMULATOR OPNET (Optimized Network Engineering Tool) provides a comprehensive development environment for the specification” simulation and performance analysis of communication networks. A large range of communication systems from a single LAN to global satellite networks can be supported. Discrete event simulation are used as the means of analyzing system performance and their behavior. The key features of OPNET are summarized here as: Modeling and Simulation Cycle OPNET provides powerful tools to assist user to go through three out of the five phases in a design circle (i.e. the building of models” the execution of a simulation and the analysis of the output dada)”see figure1.

Define problem

Build Models

Execution Simulation

Analysis Result

Make decision

HIERARCHICAL MODELING; OPNET employs a hierarchical structure to modeling. Each level of hierarchy describes different aspects of the complete model being simulated OPNET models consist of three primary model layers; the process layer , the node layer and the network layer as shown in the table below.. Network Models

Network and subnetworks

Node Models

Individual nodes and stations

Process Models

STD that define a node

Specialized in communication networks detailed library models provide support for existing protocols and allow researchers and developers to either modify these existing models or develop of their own.

AUTOMATIC SIMULATION GENERATION V models can be compiled into executable code. An executable event simulation can be debugged or simply executed , resulting in output data. This sophisticated packages comes complete with the rang of tools which allows developers specify models in great detail, identify the elements of the model of interest ,execute the simulation and analyze the generated output data; 1. Hierarchical model building  Network editor-network topology models  Node editor-data flow model define  Process editor –control flow models 2 Running simulation  Simulation tools –define and run simulation  Debugging tool- interact with running simulations analyzing results  Probe editor- data need to be connected  Analysis tool- statistical results  Filter tool- data processing  Animation viewer- dynamic behavior HIERARCHICAL MODELING OPNET provides four tool called editors to develop a representation of a system being modeled .These editors, the network, node, process and parameter, Editors are organized in hierarchical fashion, which supports the concept of model level rescue. Figure 2 portrays this hierarchical organization. The following sections introduce each of the modeling domains. The parameter editor is always seen as a utility editor and not considered a modeling domain. NETWORK MODEL: Network Editor is used to specify the physical topology of a communication network, which defines the position and inter connection of a communicating entities i.e. node and link. The specific capabilities of a each node are realized in the underlying model. A set of parameters or characteristics is attached with each model that can be set to customize the nodes behavior. A node can either be fixed, mobile or satellite. Simplex or duplex point –point links connect pair of nodes. A bus link provides a broadcast medium for a arbitrary number of attached devices. Mobile communication is supported by radio links. Links can also be customized to simulate the actual communication channels. The complexity of a network model would be unmanageable where numerous networks were being modeled as part of a single system. This complexity is eliminated by an abstraction known as a subnetwork . A subnetwork may contain many subnetwork, at the lowest levels, a subnetwork is composed only a nodes and links facilitate communication between subnetworks.

Node Model Communication devices created and interconnected at network level need to be specified in the node domain using the node editor. These modules can be grouped into two distinct categories. The first set is modulus that has predefined characteristics and a set of built in parameters. Examples are packet generators, point-point transmitters and ratio receivers. The second group condition highly programmable modulus. These modules referred to as processors and queues, relay on the process module specifications. Each node is described by a node model as it is functionality defined by the process model. Modulus is interconnected by either packet streams or statistic wires. Packets are transferred between modulus using packet streams. Statistic wires could be used to convey numeric signals. Process Model: Process models created using the process editor are used to describe the logic flow and behavior of processor and queue modulus. Communication between processes is supported by interrupts. Process modulus are expressed in a language called proto-C, Which consists of state transition diagram, a liberary of kernel procedures, and the standard C programming language? The OPNET process editor uses a powerful state transition diagram approach to support specification of any type protocol, resource, application algorithm. States and transition graphically define the progression of a process in response to events. within each state general logic can be specified using a library of predefined functions and even the full flexibility of the C language. Process may create new process to perform subtask and thus is called the parent process. RUNNING SIMULATION: SIMULATION EDITOR: After defining the models of the network system, we can exercise then in a dynamic simulation in order to study system performance and behavior. Generally, there are three steps for simulations execution and information collection: 1) Specifying Data Collection: Model developers always need to decide which information should be extracted from the simulation, such as application specific statistics, behavioral characterizations, and sometimes application specific visualization. These can take on several different forms including visual animations time dependent series of value(vector), and parametric relationship(scalar). 2 ) Simulation Construction : OPNET simulations are obtained by executing a simulation program, which is an executable file in the host computer’s file system. 3) Simulation Execution: Simulation execution is the final step in an “iteration “ of a modeling experiment. In general based on the results observed during this step, change are made to the model’s specification or to the probes, and additional simulations are executed.

OPNET provides a number of options for running simulations, including internal and external execution, and the ability to configure attributes That affect the simulation’s behavior. This section introduces concepts, techniques and features that support simulation execution. OPNET simulations can be run independently from the OPNET graphical tool by Using the op_runsim utility program. However, you can also run simulations from The simulation Tool within OPNET, which offers the convenience of a graphical interface. The simulation Tool provide the following services: 1)Specification of simulations sequence consisting of an ordered list of simulations associated attributes values. 2) Executing of simulations sequences in files for later use. 3) Storage of simulation sequences in files for later use. DATA GENERATION ROBE EDITOR Most OPNET models that contain objects that are capable of generating vast amount output data include pre-defined and user defined statistics, automatic animation, and custom programmed animation. Several different probe types are provided by OPNET in order To capture different types of output data. These are : .STATISTICS PROBE .AUTOMATIC ANIMATION PROBE .CUSTOM ANIAMTION .COUPLED STATISTICS

RESULT Thus the study of OPNET is studied successfully.