08-08-2012, 10:56 AM
The ns Manual
[attachment=30488]
Introduction
This document (ns Notes and Documentation) provides reference documentation for ns. Although we begin with a simple
simulation script, resources like Marc Greis’s tutorial web pages (originally at his web site, now at http://www.isi.
edu/nsnam/ns/tutorial/) or the slides from one of the ns tutorials are problably better places to begin for the ns
novice.
We first begin by showing a simple simulation script. This script is also available in the sources in ~ns/tcl/ex/simple.tcl.
This script defines a simple topology of four nodes, and two agents, a UDP agent with a CBR traffic generator, and a TCP
agent. The simulation runs for 3s. The output is two trace files, out.tr and out.nam. When the simulation completes at
the end of 3s, it will attempt to run a nam visualisation of the simulation on your screen.
OTcl Linkage
ns is an object oriented simulator, written in C++, with an OTcl interpreter as a frontend. The simulator supports a class
hierarchy in C++ (also called the compiled hierarchy in this document), and a similar class hierarchy within the OTcl interpreter
(also called the interpreted hierarchy in this document). The two hierarchies are closely related to each other; from the
user’s perspective, there is a one-to-one correspondence between a class in the interpreted hierarchy and one in the compiled
hierarchy. The root of this hierarchy is the class TclObject. Users create new simulator objects through the interpreter; these
objects are instantiated within the interpreter, and are closely mirrored by a corresponding object in the compiled hierarchy.
The interpreted class hierarchy is automatically established through methods defined in the class TclClass. user instantiated
objects are mirrored through methods defined in the class TclObject. There are other hierarchies in the C++ code and OTcl
scripts; these other hierarchies are not mirrored in the manner of TclObject
Concept Overview
Why two languages? ns uses two languages because simulator has two different kinds of things it needs to do. On one hand,
detailed simulations of protocols requires a systems programming language which can efficiently manipulate bytes, packet
headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around
time (run simulation, find bug, fix bug, recompile, re-run) is less important.
On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring
a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration
runs once (at the beginning of the simulation), run-time of this part of the task is less important.
ns meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower to change, making it suitable
for detailed protocol implementation. OTcl runs much slower but can be changed very quickly (and interactively), making it
ideal for simulation configuration. ns (via tclcl) provides glue to make objects and variables appear on both langauges.
For more information about the idea of scripting languages and split-language programming, see Ousterhout’s article in IEEE
Computer [26]. For more information about split level programming for network simulation, see the ns paper [2].
Code Overview
In this document, we use the term “interpreter” to be synonymous with the OTcl interpreter. The code to interface with the
interpreter resides in a separate directory, tclcl. The rest of the simulator code resides in the directory, ns-2. We will use
the notation ~tclcl/hfilei to refer to a particular hfilei in the Tcl directory. Similarly, we will use the notation, ~ns/hfilei to
refer to a particular hfilei in the ns-2 directory.
There are a number of classes defined in ~tclcl/. We only focus on the six that are used in ns: The Class Tcl (Section 3.3)
contains the methods that C++ code will use to access the interpreter. The class TclObject (Section 3.4) is the base class for
all simulator objects that are also mirrored in the compiled hierarchy. The class TclClass (Section 3.5) defines the interpreted
class hierarchy, and the methods to permit the user to instantiate TclObjects. The class TclCommand (Section 3.6) is used to
define simple global interpreter commands. The class EmbeddedTcl (Section 3.7) contains the methods to load higher level
builtin commands that make configuring simulations easier. Finally, the class InstVar (Section 3.8) containsmethods to access
C++ member variables as OTcl instance variables.
[attachment=30488]
Introduction
This document (ns Notes and Documentation) provides reference documentation for ns. Although we begin with a simple
simulation script, resources like Marc Greis’s tutorial web pages (originally at his web site, now at http://www.isi.
edu/nsnam/ns/tutorial/) or the slides from one of the ns tutorials are problably better places to begin for the ns
novice.
We first begin by showing a simple simulation script. This script is also available in the sources in ~ns/tcl/ex/simple.tcl.
This script defines a simple topology of four nodes, and two agents, a UDP agent with a CBR traffic generator, and a TCP
agent. The simulation runs for 3s. The output is two trace files, out.tr and out.nam. When the simulation completes at
the end of 3s, it will attempt to run a nam visualisation of the simulation on your screen.
OTcl Linkage
ns is an object oriented simulator, written in C++, with an OTcl interpreter as a frontend. The simulator supports a class
hierarchy in C++ (also called the compiled hierarchy in this document), and a similar class hierarchy within the OTcl interpreter
(also called the interpreted hierarchy in this document). The two hierarchies are closely related to each other; from the
user’s perspective, there is a one-to-one correspondence between a class in the interpreted hierarchy and one in the compiled
hierarchy. The root of this hierarchy is the class TclObject. Users create new simulator objects through the interpreter; these
objects are instantiated within the interpreter, and are closely mirrored by a corresponding object in the compiled hierarchy.
The interpreted class hierarchy is automatically established through methods defined in the class TclClass. user instantiated
objects are mirrored through methods defined in the class TclObject. There are other hierarchies in the C++ code and OTcl
scripts; these other hierarchies are not mirrored in the manner of TclObject
Concept Overview
Why two languages? ns uses two languages because simulator has two different kinds of things it needs to do. On one hand,
detailed simulations of protocols requires a systems programming language which can efficiently manipulate bytes, packet
headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around
time (run simulation, find bug, fix bug, recompile, re-run) is less important.
On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring
a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration
runs once (at the beginning of the simulation), run-time of this part of the task is less important.
ns meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower to change, making it suitable
for detailed protocol implementation. OTcl runs much slower but can be changed very quickly (and interactively), making it
ideal for simulation configuration. ns (via tclcl) provides glue to make objects and variables appear on both langauges.
For more information about the idea of scripting languages and split-language programming, see Ousterhout’s article in IEEE
Computer [26]. For more information about split level programming for network simulation, see the ns paper [2].
Code Overview
In this document, we use the term “interpreter” to be synonymous with the OTcl interpreter. The code to interface with the
interpreter resides in a separate directory, tclcl. The rest of the simulator code resides in the directory, ns-2. We will use
the notation ~tclcl/hfilei to refer to a particular hfilei in the Tcl directory. Similarly, we will use the notation, ~ns/hfilei to
refer to a particular hfilei in the ns-2 directory.
There are a number of classes defined in ~tclcl/. We only focus on the six that are used in ns: The Class Tcl (Section 3.3)
contains the methods that C++ code will use to access the interpreter. The class TclObject (Section 3.4) is the base class for
all simulator objects that are also mirrored in the compiled hierarchy. The class TclClass (Section 3.5) defines the interpreted
class hierarchy, and the methods to permit the user to instantiate TclObjects. The class TclCommand (Section 3.6) is used to
define simple global interpreter commands. The class EmbeddedTcl (Section 3.7) contains the methods to load higher level
builtin commands that make configuring simulations easier. Finally, the class InstVar (Section 3.8) containsmethods to access
C++ member variables as OTcl instance variables.