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 bit-
rate 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.