Everything.dvi Ns2 Manual
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 322
The ns Manual
(formerly ns Notes and Documentation)1
The VINT Project
A Collaboration between researchers at
UC Berkeley, LBL, USC/ISI, and Xerox PARC.
Kevin Fall kfall@ee.lbl.gov, Editor
Kannan Varadhan kannan@catarina.usc.edu, Editor
April 10, 2001
ns c is LBNL’s Network Simulator [16]. The simulator is written in C++; it uses OTcl as a command and configuration
interface. ns v2 has three substantial changes from ns v1: (1) the more complex objects in ns v1 have been decomposed into
simpler components for greater flexibility and composability; (2) the configuration interface is now OTcl, an object oriented
version of Tcl; and (3) the interface code to the OTcl interpreter is separate from the main simulator.
Ns documentation is available in html, Postscript, and PDF formats. See http://www.isi.edu/nsnam/ns/ns-documentation.
html for pointers to these.
1 The VINT project is a joint effort by people from UC Berkeley, USC/ISI, LBL, and Xerox PARC. The project is supported by the Defense Advanced
Research Projects Agency (DARPA) at LBL under DARPA grant DABT63-96-C-0105, at USC/ISI under DARPA grant ABT63-96-C-0054, at Xerox PARC
under DARPA grant DABT63-96-C-0105. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s)
and do not necessarily reflect the views of the DARPA.
Contents
1 Introduction
10
2 Undocumented Facilities
14
I
16
Interface to the Interpreter
3 OTcl Linkage
3.1 Concept Overview . . . . . . . . . . . . . . . . . . . .
3.2 Code Overview . . . . . . . . . . . . . . . . . . . . . .
3.3 Class Tcl . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Obtain a Reference to the class Tcl instance . . .
3.3.2 Invoking OTcl Procedures . . . . . . . . . . . .
3.3.3 Passing Results to/fro the Interpreter . . . . . . .
3.3.4 Error Reporting and Exit . . . . . . . . . . . . .
3.3.5 Hash Functions within the Interpreter . . . . . .
3.3.6 Other Operations on the Interpreter . . . . . . .
3.4 Class TclObject . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Creating and Destroying TclObjects . . . . . . .
3.4.2 Variable Bindings . . . . . . . . . . . . . . . . .
3.4.3 Variable Tracing . . . . . . . . . . . . . . . . .
3.4.4 commandMethods: Definition and Invocation .
3.5 Class TclClass . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 How to Bind Static C++ Class Member Variables
3.6 Class TclCommand . . . . . . . . . . . . . . . . . . . .
3.7 Class EmbeddedTcl . . . . . . . . . . . . . . . . . . . .
3.8 Class InstVar . . . . . . . . . . . . . . . . . . . . . . .
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Simulator Basics
4 The Class Simulator
4.1 Simulator Initialization . . . . . . . . .
4.2 Schedulers and Events . . . . . . . . .
4.2.1 The List Scheduler . . . . . . .
4.2.2 the heap scheduler . . . . . . .
4.2.3 The Calendar Queue Scheduler
4.2.4 The Real-Time Scheduler . . .
4.3 Other Methods . . . . . . . . . . . . .
4.4 Commands at a glance . . . . . . . . .
17
17
18
18
19
19
19
20
20
21
21
22
23
25
26
28
29
31
32
33
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
36
37
38
38
38
38
39
5 Nodes and Packet Forwarding
5.1 Simulator Methods: Creating the Topology
5.2 Node Methods: Configuring the Node . . .
5.3 Configuring Node Functionality . . . . . .
5.3.1 Node Configuration Interface . . .
5.4 The Classifier . . . . . . . . . . . . . . . .
5.4.1 Address Classifiers . . . . . . . . .
5.4.2 Multicast Classifiers . . . . . . . .
5.4.3 MultiPath Classifier . . . . . . . .
5.4.4 Hash Classifier . . . . . . . . . . .
5.4.5 Replicator . . . . . . . . . . . . . .
5.5 Routing Module and Classifier Organization
5.5.1 Routing Module . . . . . . . . . .
5.5.2 Node Interface . . . . . . . . . . .
5.6 Commands at a glance . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
44
46
46
48
50
50
52
52
53
54
55
57
57
6 Links: Simple Links
6.1 Instance Procedures for Links and SimpleLinks
6.2 Connectors . . . . . . . . . . . . . . . . . . .
6.3 Object hierarchy . . . . . . . . . . . . . . . . .
6.4 Commands at a glance . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
61
63
63
64
7 Queue Management and Packet Scheduling
7.1 The C++ Queue Class . . . . . . . . . .
7.1.1 Queue blocking . . . . . . . . .
7.1.2 PacketQueue Class . . . . . . .
7.2 Example: Drop Tail . . . . . . . . . . .
7.3 Different types of Queue objects . . . .
7.4 Commands at a glance . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
67
68
69
70
71
75
8 Delays and Links
8.1 The LinkDelay Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Commands at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
76
77
9 Agents
9.1 Agent state . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Agent methods . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Protocol Agents . . . . . . . . . . . . . . . . . . . . . . . .
9.4 OTcl Linkage . . . . . . . . . . . . . . . . . . . . . . . . .
9.4.1 Creating and Manipulating Agents . . . . . . . . . .
9.4.2 Default Values . . . . . . . . . . . . . . . . . . . .
9.4.3 OTcl Methods . . . . . . . . . . . . . . . . . . . .
9.5 Examples: Tcp, TCP Sink Agents . . . . . . . . . . . . . .
9.5.1 Creating the Agent . . . . . . . . . . . . . . . . . .
9.5.2 Starting the Agent . . . . . . . . . . . . . . . . . .
9.5.3 Processing Input at Receiver . . . . . . . . . . . . .
9.5.4 Processing Responses at the Sender . . . . . . . . .
9.5.5 Implementing Timers . . . . . . . . . . . . . . . . .
9.6 Creating a New Agent . . . . . . . . . . . . . . . . . . . . .
9.6.1 Example: A “ping” requestor (Inheritance Structure)
9.6.2 The recv() and timeout() Methods . . . . . . . .
9.6.3 Linking the “ping” Agent with OTcl . . . . . . . . .
9.6.4 Using the agent through OTcl . . . . . . . . . . . .
9.7 The Agent API . . . . . . . . . . . . . . . . . . . . . . . .
9.8 Different agent objects . . . . . . . . . . . . . . . . . . . .
79
79
79
80
81
81
81
82
82
82
83
84
85
86
86
86
87
87
89
89
89
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9.9
Commands at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Timers
10.1 C++ abstract base class TimerHandler . . .
10.1.1 Definition of a new timer . . . . . .
10.1.2 Example: Tcp retransmission timer
10.2 OTcl Timer class . . . . . . . . . . . . . .
10.3 Commands at a glance . . . . . . . . . . .
92
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
94
94
95
95
98
98
11 Packet Headers and Formats
11.1 A Protocol-Specific Packet Header . . . . . . . . . . . . . . . .
11.1.1 Adding a New Packet Header Type . . . . . . . . . . .
11.1.2 Selectively Including Packet Headers in Your Simulation
11.2 Packet Classes . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.1 The Packet Class . . . . . . . . . . . . . . . . . . . . .
11.2.2 p_info Class . . . . . . . . . . . . . . . . . . . . . . .
11.2.3 The hdr_cmn Class . . . . . . . . . . . . . . . . . . . .
11.2.4 The PacketHeaderManager Class . . . . . . . . . . . .
11.3 Commands at a glance . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
101
101
102
102
105
105
106
107
12 Error Model
12.1 Implementation . . . .
12.2 Configuration . . . . .
12.3 Multi-state error model
12.4 Commands at a glance
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
109
109
110
111
112
13 Local Area Networks
13.1 Tcl configuration . . . . . . . . . . . . . . . . . . . . . . .
13.2 Components of a LAN . . . . . . . . . . . . . . . . . . . .
13.3 Channel Class . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.1 Channel State . . . . . . . . . . . . . . . . . . . . .
13.3.2 Example: Channel and classifier of the physical layer
13.3.3 Channel Class in C++ . . . . . . . . . . . . . . . .
13.4 MacClassifier Class . . . . . . . . . . . . . . . . . . . . . .
13.5 MAC Class . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5.1 Mac State . . . . . . . . . . . . . . . . . . . . . . .
13.5.2 Mac Methods . . . . . . . . . . . . . . . . . . . . .
13.5.3 Mac Class in C++ . . . . . . . . . . . . . . . . . .
13.5.4 CSMA-based MAC . . . . . . . . . . . . . . . . . .
13.6 LL (link-layer) Class . . . . . . . . . . . . . . . . . . . . .
13.6.1 LL Class in C++ . . . . . . . . . . . . . . . . . . .
13.6.2 Example: Link Layer configuration . . . . . . . . .
13.7 LanRouterclass . . . . . . . . . . . . . . . . . . . . . . .
13.8 Other Components . . . . . . . . . . . . . . . . . . . . . .
13.9 LANs and ns routing . . . . . . . . . . . . . . . . . . . . .
13.10Commands at a glance . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
113
113
114
115
115
115
115
116
117
117
117
117
118
119
119
119
120
120
120
122
14 The (Revised) Addressing Structure in NS
14.1 The Default Address Format . . . . . .
14.2 The Hierarchical Address Format . . . .
14.2.1 Default Hierarchical Setting . .
14.2.2 Specific Hierarchical Setting . .
14.3 The Expanded Node-Address Format .
14.4 Expanding port-id field . . . . . . . . .
14.5 Errors in setting address format . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
123
123
124
124
124
124
124
125
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14.6 Commands at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
15 Mobile Networking in ns
15.1 The basic wireless model in ns . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.1 Mobilenode: creating wireless topology . . . . . . . . . . . . . . . . . . .
15.1.2 Creating Node movements . . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.3 Network Components in a mobilenode . . . . . . . . . . . . . . . . . . . .
15.1.4 Different types of Routing Agents in mobile networking . . . . . . . . . .
15.1.5 Trace Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.6 Revised format for wireless traces . . . . . . . . . . . . . . . . . . . . . .
15.1.7 Generation of node-movement and traffic-connection for wireless scenarios
15.2 Extensions made to CMU’s wireless model . . . . . . . . . . . . . . . . . . . . .
15.2.1 wired-cum-wireless scenarios . . . . . . . . . . . . . . . . . . . . . . . .
15.2.2 MobileIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.3 Commands at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
126
126
126
127
130
133
135
138
141
142
142
144
145
16 Satellite Networking in ns
16.1 Overview of satellite models . . . . .
16.1.1 Geostationary satellites . . . .
16.1.2 Low-earth-orbiting satellites .
16.2 Using the satellite extensions . . . . .
16.2.1 Nodes and node positions . .
16.2.2 Satellite links . . . . . . . . .
16.2.3 Handoffs . . . . . . . . . . .
16.2.4 Routing . . . . . . . . . . . .
16.2.5 Trace support . . . . . . . . .
16.2.6 Error models . . . . . . . . .
16.2.7 Other configuration options .
16.2.8 nam support . . . . . . . . .
16.2.9 Integration with other modules
16.2.10 Example scripts . . . . . . . .
16.3 Implementation . . . . . . . . . . . .
16.3.1 Use of linked lists . . . . . . .
16.3.2 Node structure . . . . . . . .
16.3.3 Detailed look at satellite links
16.4 Commands at a glance . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
148
148
148
149
151
151
152
154
155
156
157
158
158
158
158
159
159
160
161
162
17 Radio Propagation Models
17.1 Free space model . . . . . . . .
17.2 Two-ray ground reflection model
17.3 Shadowing model . . . . . . . .
17.3.1 Backgroud . . . . . . .
17.3.2 Using shadowing model
17.4 Communication range . . . . . .
17.5 Commands at a glance . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
164
164
165
165
165
167
167
168
18 Debugging ns
18.1 Tcl-level Debugging . . . . . . . . . . . .
18.2 C++-Level Debugging . . . . . . . . . . .
18.3 Mixing Tcl and C debugging . . . . . . . .
18.4 Memory Debugging . . . . . . . . . . . . .
18.4.1 Using dmalloc . . . . . . . . . . .
18.4.2 Memory Conservation Tips . . . . .
18.4.3 Some statistics collected by dmalloc
18.5 Memory Leaks . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
169
169
169
170
171
171
172
172
172
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
18.5.1 OTcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
18.5.2 C/C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
19 Energy Model in ns
174
19.1 The C++ EnergyModel Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
19.2 The OTcl interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
III Support
176
20 Mathematical Support
20.1 Random Number Generation . . . . . . . .
20.2 Random Variables . . . . . . . . . . . . . .
20.3 Integrals . . . . . . . . . . . . . . . . . . .
20.4 ns-random . . . . . . . . . . . . . . . .
20.5 Some mathematical-support related objects
20.6 Commands at a glance . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
177
179
180
181
181
182
21 Trace and Monitoring Support
21.1 Trace Support . . . . . . . . . . . .
21.1.1 OTcl Helper Functions . . .
21.2 Library support and examples . . .
21.3 The C++ Trace Class . . . . . . . .
21.4 Trace File Format . . . . . . . . . .
21.5 Packet Types . . . . . . . . . . . .
21.6 Queue Monitoring . . . . . . . . . .
21.7 Per-Flow Monitoring . . . . . . . .
21.7.1 The Flow Monitor . . . . .
21.7.2 Flow Monitor Trace Format
21.7.3 The Flow Class . . . . . . .
21.8 Commands at a glance . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
184
184
185
186
188
189
191
192
194
194
194
195
195
22 Nam Trace
22.1 Nam Trace format . . . . . . . . . . . . . . . . . . . . . .
22.1.1 Packet Traces . . . . . . . . . . . . . . . . . . . .
22.1.2 Node state . . . . . . . . . . . . . . . . . . . . . .
22.1.3 Node Marking . . . . . . . . . . . . . . . . . . .
22.1.4 Link/Queue State . . . . . . . . . . . . . . . . . .
22.1.5 Agent Tracing . . . . . . . . . . . . . . . . . . .
22.1.6 Variable Tracing . . . . . . . . . . . . . . . . . .
22.1.7 Miscellaneous Trace Events . . . . . . . . . . . .
22.2 Ns commands for creating and controlling nam animations
22.2.1 Node . . . . . . . . . . . . . . . . . . . . . . . .
22.2.2 Link/Queue . . . . . . . . . . . . . . . . . . . . .
22.2.3 Agent and Features . . . . . . . . . . . . . . . . .
22.2.4 Some Generic Commands . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
198
198
199
200
200
200
201
201
202
203
203
203
204
204
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Routing
205
23 Unicast Routing
23.1 The Interface to the Simulation Operator (The API) . . .
23.2 Other Configuration Mechanisms for Specialised Routing
23.3 Protocol Specific Configuration Parameters . . . . . . .
23.4 Internals and Architecture of Routing . . . . . . . . . .
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
206
206
207
208
209
23.4.1 The classes . . . . . . . . . . . . . . . . . .
23.4.2 Interface to Network Dynamics and Multicast
23.5 Protocol Internals . . . . . . . . . . . . . . . . . . .
23.6 Unicast routing objects . . . . . . . . . . . . . . . .
23.7 Commands at a glance . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
209
213
213
214
215
24 Multicast Routing
24.1 Multicast API . . . . . . . . . . . . . . . . . . . .
24.1.1 Multicast Behavior Monitor Configuration
24.1.2 Protocol Specific configuration . . . . . . .
24.2 Internals of Multicast Routing . . . . . . . . . . .
24.2.1 The classes . . . . . . . . . . . . . . . . .
24.2.2 Extensions to other classes in ns . . . . . .
24.2.3 Protocol Internals . . . . . . . . . . . . . .
24.2.4 The internal variables . . . . . . . . . . . .
24.3 Commands at a glance . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
217
217
218
219
220
220
222
225
227
227
25 Network Dynamics
25.1 The user level API . . . . . . . . . . . . . . . . .
25.2 The Internal Architecture . . . . . . . . . . . . . .
25.2.1 The class rtModel . . . . . . . . . . . . . .
25.2.2 class rtQueue . . . . . . . . . . . . .
25.3 Interaction with Unicast Routing . . . . . . . . . .
25.3.1 Extensions to Other Classes . . . . . . . .
25.4 Deficencies in the Current Network Dynamics API
25.5 Commands at a glance . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
230
230
232
232
233
234
234
235
235
26 Hierarchical Routing
26.1 Overview of Hierarchical Routing . .
26.2 Usage of Hierarchical routing . . . . .
26.3 Creating large Hierarchical topologies
26.4 Hierarchical Routing with SessionSim
26.5 Commands at a glance . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
237
237
237
240
240
240
V
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Transport
242
27 UDP Agents
243
27.1 UDP Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
27.2 Commands at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
28 TCP Agents
28.1 One-Way TCP Senders . . . . . . . . . . .
28.1.1 The Base TCP Sender (Tahoe TCP)
28.1.2 Configuration . . . . . . . . . . . .
28.1.3 Simple Configuration . . . . . . . .
28.1.4 Other Configuration Parameters . .
28.1.5 Other One-Way TCP Senders . . .
28.2 TCP Receivers (sinks) . . . . . . . . . . .
28.2.1 The Base TCP Sink . . . . . . . . .
28.2.2 Delayed-ACK TCP Sink . . . . . .
28.2.3 Sack TCP Sink . . . . . . . . . . .
28.3 Two-Way TCP Agents (FullTcp) . . . . . .
28.3.1 Simple Configuration . . . . . . . .
28.4 Architecture and Internals . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
245
246
246
246
246
247
248
248
249
249
249
249
250
251
28.5
28.6
28.7
28.8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
252
252
253
253
29 Agent/SRM
29.1 Configuration . . . . . . . . . . . . . . . . . .
29.1.1 Trivial Configuration . . . . . . . . . .
29.1.2 Other Configuration Parameters . . . .
29.1.3 Statistics . . . . . . . . . . . . . . . .
29.1.4 Tracing . . . . . . . . . . . . . . . . .
29.2 Architecture and Internals . . . . . . . . . . . .
29.3 Packet Handling: Processing received messages
29.4 Loss Detection—The Class SRMinfo . . . . .
29.5 Loss Recovery Objects . . . . . . . . . . . . .
29.6 Session Objects . . . . . . . . . . . . . . . . .
29.7 Extending the Base Class Agent . . . . . . . .
29.7.1 Fixed Timers . . . . . . . . . . . . . .
29.7.2 Adaptive Timers . . . . . . . . . . . .
29.8 SRM objects . . . . . . . . . . . . . . . . . . .
29.9 Commands at a glance . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
254
254
254
256
257
258
260
260
262
262
264
265
265
265
266
267
30 PLM
30.1 Configuration . . . . . . . . . . . . . .
30.2 The Packet Pair Source Generator . . .
30.3 Architecture of the PLM Protocol . . .
30.3.1 Instantiation of a PLM Source .
30.3.2 Instantiation of a PLM Receiver
30.3.3 Reception of a Packet . . . . . .
30.3.4 Detection of a Loss . . . . . . .
30.3.5 Joining or Leaving a Layer . . .
30.4 Commands at a Glance . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
269
269
271
272
272
272
273
274
274
274
VI
Tracing TCP Dynamics . . . . . . . .
One-Way Trace TCP Trace Dynamics
One-Way Trace TCP Trace Dynamics
Commands at a glance . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Application
31 Applications and transport agent API
31.1 The class Application . . . . . . . . . . . . . .
31.2 The transport agent API . . . . . . . . . . . . .
31.2.1 Attaching transport agents to nodes . .
31.2.2 Attaching applications to agents . . . .
31.2.3 Using transport agents via system calls
31.2.4 Agent upcalls to applications . . . . . .
31.2.5 An example . . . . . . . . . . . . . . .
31.3 The class TrafficGenerator . . . . . . . . . . .
31.3.1 An example . . . . . . . . . . . . . . .
31.4 Simulated applications: Telnet and FTP . . . .
31.5 Applications objects . . . . . . . . . . . . . . .
31.6 Commands at a glance . . . . . . . . . . . . .
276
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
277
277
278
278
279
279
279
280
281
283
284
284
286
32 Web cache as an application
32.1 Using application-level data in ns . . . . . . . . . . .
32.1.1 ADU . . . . . . . . . . . . . . . . . . . . .
32.1.2 Passing data between applications . . . . . .
32.1.3 Transmitting user data over UDP . . . . . . .
32.1.4 Transmitting user data over TCP . . . . . . .
32.1.5 Class hierarchy related to user data handling
32.2 Overview of web cache classes . . . . . . . . . . . .
32.2.1 Managing HTTP connections . . . . . . . .
32.2.2 Managing web pages . . . . . . . . . . . . .
32.2.3 Debugging . . . . . . . . . . . . . . . . . .
32.3 Representing web pages . . . . . . . . . . . . . . .
32.4 Page pools . . . . . . . . . . . . . . . . . . . . . . .
32.4.1 PagePool/Math . . . . . . . . . . . . . . . .
32.4.2 PagePool/CompMath . . . . . . . . . . . . .
32.4.3 PagePool/ProxyTrace . . . . . . . . . . . . .
32.4.4 PagePool/Client . . . . . . . . . . . . . . . .
32.5 Web client . . . . . . . . . . . . . . . . . . . . . . .
32.6 Web server . . . . . . . . . . . . . . . . . . . . . .
32.7 Web cache . . . . . . . . . . . . . . . . . . . . . . .
32.7.1 Http/Cache . . . . . . . . . . . . . . . . . .
32.8 Putting together: a simple example . . . . . . . . . .
32.9 Http trace format . . . . . . . . . . . . . . . . . . .
32.10Commands at a glance . . . . . . . . . . . . . . . .
VII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Scale
33 Session-level Packet Distribution
33.1 Configuration . . . . . . . . . .
33.1.1 Basic Configuration . .
33.1.2 Inserting a Loss Module
33.2 Architecture . . . . . . . . . . .
33.3 Internals . . . . . . . . . . . . .
33.3.1 Object Linkage . . . . .
33.3.2 Packet Forwarding . . .
33.4 Commands at a glance . . . . .
287
287
287
288
289
290
291
291
291
292
293
293
294
294
295
295
296
297
298
298
298
299
301
302
304
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
VIII Emulation
34 Emulation
34.1 Introduction . . . . . . . . . . . . .
34.2 Real-Time Scheduler . . . . . . . .
34.3 Tap Agents . . . . . . . . . . . . .
34.4 Network Objects . . . . . . . . . .
34.4.1 Pcap/BPF Network Objects
34.4.2 IP Network Objects . . . . .
34.4.3 IP/UDP Network Objects . .
34.5 An Example . . . . . . . . . . . . .
34.6 Commands at a glance . . . . . . .
305
305
305
307
307
308
308
309
310
311
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
312
312
313
313
314
314
315
315
316
317
IX
Nam and Animation
318
35 Nam
319
35.1 Animations from nam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
9
Chapter 1
Introduction
Let’s start at the very beginning,
a very nice place to start,
when you sing, you begin with A, B, C,
when you simulate, you begin with the topology, 1
...
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 . The output is two trace files, out.tr and out.nam. When the simulation completes at
the end of , it will attempt to run a nam visualisation of the simulation on your screen.
# The preamble
set ns [new Simulator]
;# initialise the simulation
# Predefine tracing
set f [open out.tr w]
$ns trace-all $f
set nf [open out.nam w]
$ns namtrace-all $nf
1 with
apologies to Rodgers and Hammerstein
10
# so, we lied. now, we define the topology
#
#
n0
#
#
5Mb
#
2ms
#
#
n2 --------- n3
#
/
1.5Mb
#
5Mb /
10ms
#
2ms /
#
/
#
n1
#
set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
$ns duplex-link $n0 $n2 5Mb 2ms DropTail
$ns duplex-link $n1 $n2 5Mb 2ms DropTail
$ns duplex-link $n2 $n3 1.5Mb 10ms DropTail
# Some agents.
set udp0 [new Agent/UDP]
$ns attach-agent $n0 $udp0
set cbr0 [new Application/Traffic/CBR]
$cbr0 attach-agent $udp0
$udp0 set class_ 0
;# A UDP agent
;# on node $n0
;# A CBR traffic generator agent
;# attached to the UDP agent
;# actually, the default, but. . .
;# Its sink
;# on node $n3
set null0 [new Agent/Null]
$ns attach-agent $n3 $null0
$ns connect $udp0 $null0
$ns at 1.0 "$cbr0 start"
puts [$cbr0 set packetSize_]
puts [$cbr0 set interval_]
# A FTP over TCP/Tahoe from $n1 to $n3, flowid 2
set tcp [new Agent/TCP]
$tcp set class_ 1
$ns attach-agent $n1 $tcp
set sink [new Agent/TCPSink]
$ns attach-agent $n3 $sink
;# TCP does not generate its own traffic
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 1.2 "$ftp start"
$ns connect $tcp $sink
$ns at 1.35 "$ns detach-agent $n0 $tcp ; $ns detach-agent $n3 $sink"
11
12
# The simulation runs for .
# The simulation comes to an end when the scheduler invokes the finish{} procedure below.
# This procedure closes all trace files, and invokes nam visualization on one of the trace files.
$ns at 3.0 "finish"
proc finish {} {
global ns f nf
$ns flush-trace
close $f
close $nf
puts "running nam..."
exec nam out.nam &
exit 0
}
# Finally, start the simulation.
$ns run
13
Chapter 2
Undocumented Facilities
Ns is often growing to include new protocols. Unfortunately the documention doesn’t grow quite as often. This section lists
what remains to be documented, or what needs to be improved.
(The documentation is in the doc subdirectory of the ns source code if you want to add to it. :-)
Interface to the Interpreter
Simulator Basics
nothing currently
LANs need to be updated for new wired/wireless support (Yuri updated this?)
wireless support needs to be added (done)
should explicitly list queueing options in the queue mgt chapter?
Support
should pick a single list mgt package and document it
should document the trace-post-processing utilities in bin
The usage and design of link state and MPLS routing modules are not documented at all. (Note: link state and
MPLS appeared only in daily snapshots and releases after 09/14/2000.)
Routing
need to document hierarchical routing/addressing (Padma has done)
need a chapter on supported ad-hoc routing protocols
Queueing
CBQ needs documentation (can maybe build off of ftp://ftp.ee.lbl.gov/papers/cbqsims.
ps.Z?)
Transport
need to document MFTP
need to document RTP (session-rtp.cc, etc.)
need to document multicast building blocks
should repair and document snoop and tcp-int
Traffic and scenarios (new section)
should add a description of how to drive the simulator from traces
should add discussion of the scenario generator
should add discussion of http traffic sources
Application
is the non-Haobo http stuff documented? no.
14
Scale
should add disucssion of mixed mode (pending)
Emulation
Other
nothing currently
should document admission control policies?
should add a validation chapter and snarf up the contents of ns-tests.html
should snarf up Marc Greis’ tutorial rather than just referring to it?
15
Part I
Interface to the Interpreter
16
Chapter 3
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.
3.1 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 [18]. For more information about split level programming for network simulation, see the ns paper [2].
Which language for what? Having two languages raises the question of which language should be used for what purpose.
Our basic advice is to use OTcl:
for configuration, setup, and “one-time” stuff
17
if you can do what you want by manipulating existing C++ objects
and use C++:
if you are doing anything that requires processing each packet of a flow
if you have to change the behavior of an existing C++ class in ways that weren’t anticipated
For example, links are OTcl objects that assemble delay, queueing, and possibly loss modules. If your experiment can be
done with those pieces, great. If instead you want do something fancier (a special queueing dicipline or model of loss), then
you’ll need a new C++ object.
There are certainly grey areas in this spectrum: most routing is done in OTcl (although the core Dijkstra algorithm is in C++).
We’ve had HTTP simulations where each flow was started in OTcl and per-packet processing was all in C++. This approache
worked OK until we had 100s of flows starting per second of simulated time. In general, if you’re ever having to invoke Tcl
many times per second, you problably should move that code to C++.
3.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/file to refer to a particular file in the Tcl directory. Similarly, we will use the notation, ~ns/file to
refer to a particular file 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) contains methods to access
C++ member variables as OTcl instance variables.
The procedures and functions described in this chapter can be found in ~tclcl/Tcl.{cc, h}, ~tclcl/Tcl2.cc, ~tclcl/tcl-object.tcl,
and, ~tclcl/tracedvar.{cc, h}. The file ~tclcl/tcl2c++.c is used in building ns, and is mentioned briefly in this chapter.
3.3 Class Tcl
The class Tcl encapsulates the actual instance of the OTcl interpreter, and provides the methods to access and communicate with that interpreter. The methods described in this section are relevant to the ns programmer who is writing C++ code.
The class provides methods for the following operations:
obtain a reference to the Tcl instance;
invoke OTcl procedures through the interpreter;
retrieve, or pass back results to the interpreter;
report error situations and exit in an uniform manner; and
18
store and lookup “TclObjects”.
acquire direct access to the interpreter.
We describe each of the methods in the following subsections.
3.3.1 Obtain a Reference to the class Tcl instance
A single instance of the class is declared in ~tclcl/Tcl.cc as a static member variable; the programmer must obtain a reference
to this instance to access other methods described in this section. The statement required to access this instance is:
Tcl& tcl = Tcl::instance();
3.3.2 Invoking OTcl Procedures
There are four different methods to invoke an OTcl command through the instance, tcl. They differ essentially in their
calling arguments. Each function passes a string to the interpreter, that then evaluates the string in a global context. These
methods will return to the caller if the interpreter returns TCL_OK. On the other hand, if the interpreter returns TCL_ERROR,
the methods will call tkerror{}. The user can overload this procedure to selectively disregard certain types of errors. Such
intricacies of OTcl programming are outside the scope of this document. The next section (Section 3.3.3) describes methods
to access the result returned by the interpreter.
tcl.eval(char* ) invokes Tcl_GlobalEval() to execute through the interpreter.
tcl.evalc(const char* ) preserves the argument string . It copies the string into its internal buffer; it then invokes
the previous eval(char* ) on the internal buffer.
tcl.eval() assumes that the command is already stored in the class’ internal bp_; it directly invokes tcl.eval(char*
bp_). A handle to the buffer itself is available through the method tcl.buffer(void).
tcl.evalf(const char* , . . . ) is a Printf(3) like equivalent. It uses vsprintf(3) internally to create the input
string.
As an example, here are some of the ways of using the above methods:
Tcl& tcl = Tcl::instance();
char wrk[128];
strcpy(wrk, "Simulator set NumberInterfaces_ 1");
tcl.eval(wrk);
sprintf(tcl.buffer(), "Agent/SRM set requestFunction_ %s", "Fixed");
tcl.eval();
tcl.evalc("puts stdout hello world");
tcl.evalf("%s request %d %d", name_, sender, msgid);
3.3.3 Passing Results to/fro the Interpreter
When the interpreter invokes a C++ method, it expects the result back in the private member variable, tcl_->result. Two
methods are available to set this variable.
19
tcl.result(const char* )
Pass the result string back to the interpreter.
tcl.resultf(const char* fmt, . . . )
varargs(3) variant of above to format the result using vsprintf(3), pass the result string back to the interpreter.
if (strcmp(argv[1], "now") == 0) {
tcl.resultf("%.17g", clock());
return TCL_OK;
}
tcl.result("Invalid operation specified");
return TCL_ERROR;
Likewise, when a C++ method invokes an OTcl command, the interpreter returns the result in tcl_->result.
tcl.result(void) must be used to retrieve the result. Note that the result is a string, that must be converted into an
internal format appropriate to the type of result.
tcl.evalc("Simulator set NumberInterfaces_");
char* ni = tcl.result();
if (atoi(ni) != 1)
tcl.evalc("Simulator set NumberInterfaces_ 1");
3.3.4 Error Reporting and Exit
This method provides a uniform way to report errors in the compiled code.
tcl.error(const char* ) performs the following functions: write to stdout; write tcl_->result to stdout; exit
with error code 1.
tcl.resultf("cmd = %s", cmd);
tcl.error("invalid command specified");
/*NOTREACHED*/
Note that there are minor differences between returning TCL_ERROR as we did in the previous subsection (Section 3.3.3),
and calling Tcl::error(). The former generates an exception within the interpreter; the user can trap the exception and
possibly recover from the error. If the user has not specified any traps, the interpreter will print a stack trace and exit. However,
if the code invokes error(), then the simulation user cannot trap the error; in addition, ns will not print any stack trace.
3.3.5 Hash Functions within the Interpreter
ns stores a reference to every TclObject in the compiled hierarchy in a hash table; this permits quick access to the objects.
The hash table is internal to the interpreter. ns uses the name of the TclObject as the key to enter, lookup, or delete the
TclObject in the hash table.
20
tcl.enter(TclObject* ) will insert a pointer to the TclObject into the hash table.
It is used by TclClass::create_shadow() to insert an object into the table, when that object is created.
tcl.lookup(char* ) will retrieve the TclObject with the name .
It is used by TclObject::lookup().
tcl.remove(TclObject* ) will delete references to the TclObject from the hash table.
It is used by TclClass::delete_shadow() to remove an existing entry from the hash table, when that object is
deleted.
These functions are used internally by the class TclObject and class TclClass.
3.3.6 Other Operations on the Interpreter
If the above methods are not sufficient, then we must acquire the handle to the interpreter, and write our own functions.
tcl.interp(void) returns the handle to the interpreter that is stored within the class Tcl.
3.4 Class TclObject
class TclObject is the base class for most of the other classes in the interpreted and compiled hierarchies. Every object
in the class TclObject is created by the user from within the interpreter. An equivalent shadow object is created in the compiled
hierarchy. The two objects are closely associated with each other. The class TclClass, described in the next section, contains
the mechanisms that perform this shadowing.
In the rest of this document, we often refer to an object as a TclObject 1 . By this, we refer to a particular object that is either
in the class TclObject, or in a class that is derived from the class TclObject. If it is necessary, we will explicitly qualify
whether that object is an object within the interpreter, or an object within the compiled code. In such cases, we will use the
abbreviations “interpreted object”, and “compiled object” to distinguish the two. and within the compiled code respectively.
Differences from ns v1 Unlike ns v1, the class TclObject subsumes the earlier functions of the NsObject class. It therefore
stores the interface variable bindings (Section 3.4.2) that tie OTcl instance variables in the interpreted object to corresponding
C++ member variables in the compiled object. The binding is stronger than in ns v1 in that any changes to the OTcl variables
are trapped, and the current C++ and OTcl values are made consistent after each access through the interpreter. The consistency is done through the class InstVar (Section 3.8). Also unlike ns v1, objects in the class TclObject are no longer stored as
a global link list. Instead, they are stored in a hash table in the class Tcl (Section 3.3.5).
Example configuration of a TclObject The following example illustrates the configuration of an SRM agent (class
Agent/SRM/Adaptive).
set srm [new Agent/SRM/Adaptive]
$srm set packetSize_ 1024
$srm traffic-source $s0
1 In the latest release of ns and ns/tclcl, this object has been renamed to SplitObjefct, which more accurately reflects its nature of existence. However,
for the moment, we will continue to use the term TclObject to refer to these objects and this class.
21
By convention in ns, the class Agent/SRM/Adaptive is a subclass of Agent/SRM, is a subclass of Agent, is a subclass of
TclObject. The corresponding compiled class hierarchy is the ASRMAgent, derived from SRMAgent, derived from Agent,
derived from TclObject respectively. The first line of the above example shows how a TclObject is created (or destroyed)
(Section 3.4.1); the next line configures a bound variable (Section 3.4.2); and finally, the last line illustrates the interpreted
object invoking a C++ method as if they were an instance procedure (Section 3.4.4).
3.4.1 Creating and Destroying TclObjects
When the user creates a new TclObject, using the procedures new{} and delete{}; these procedures are defined in
~tclcl/tcl-object.tcl. They can be used to create and destroy objects in all classes, including TclObjects. 2 . In this section,
we describe the internal actions executed when a TclObject is created.
Creating TclObjects By using new{}, the user creates an interpreted TclObject. the interpreter will execute the constructor
for that object, init{}, passing it any arguments provided by the user. ns is responsible for automatically creating the
compiled object. The shadow object gets created by the base class TclObject’s constructor. Therefore, the constructor for
the new TclObject must call the parent class constructor first. new{} returns a handle to the object, that can then be used for
further operations upon that object.
The following example illustrates the Agent/SRM/Adaptive constructor:
Agent/SRM/Adaptive instproc init args {
eval $self next $args
$self array set closest_ "requestor 0 repairor 0"
$self set eps_
[$class set eps_]
}
The following sequence of actions are performed by the interpreter as part of instantiating a new TclObject. For ease of
exposition, we describe the steps that are executed to create an Agent/SRM/Adaptive object. The steps are:
1. Obtain an unique handle for the new object from the TclObject name space. The handle is returned to the user. Most
handles in ns have the form _oNNN, where NNN is an integer. This handle is created by getid{}. It can be
retrieved from C++ with the name(){} method.
2. Execute the constructor for the new object. Any user-specified arguments are passed as arguments to the constructor.
This constructor must invoke the constructor associated with its parent class.
In our example above, the Agent/SRM/Adaptive calls its parent class in the very first line.
Note that each constructor, in turn invokes its parent class’ constructor ad nauseum. The last constructor in ns is the
TclObject constructor. This constructor is responsible for setting up the shadow object, and performing other initializations and bindings, as we explain below. It is preferable to call the parent constructors first before performing the
initializations required in this class. This allows the shadow objects to be set up, and the variable bindings established.
3. The TclObject constructor invokes the instance procedure create-shadow{} for the class Agent/SRM/Adaptive.
4. When the shadow object is created, ns calls all of the constructors for the compiled object, each of which may establish
variable bindings for objects in that class, and perform other necessary initializations. Hence our earlier injunction that
it is preferable to invoke the parent constructors prior to performing the class initializations.
5. After the shadow object is successfully created, create_shadow(void)
2 As an example, the classes Simulator, Node, Link, or rtObject, are classes that are not derived from the class TclObject. Objects in these classes are not,
therefore, TclObjects. However, a Simulator, Node, Link, or route Object is also instantiated using the new procedure in ns.
22
(a) adds the new object to hash table of TclObjects described earlier (Section 3.3.5).
(b) makes cmd{} an instance procedure of the newly created interpreted object. This instance procedure invokes the
command() method of the compiled object. In a later subsection (Section 3.4.4), we describe how the command
method is defined, and invoked.
Note that all of the above shadowing mechanisms only work when the user creates a new TclObject through the interpreter.
It will not work if the programmer creates a compiled TclObject unilaterally. Therefore, the programmer is enjoined not to
use the C++ new method to create compiled objects directly.
Deletion of TclObjects The delete operation destroys the interpreted object, and the corresponding shadow object. For
example, use-scheduler{scheduler} uses the delete procedure to remove the default list scheduler, and instantiate
an alternate scheduler in its place.
Simulator instproc use-scheduler type {
$self instvar scheduler_
delete scheduler_
set scheduler_ [new Scheduler/$type]
;# first delete the existing list scheduler
}
As with the constructor, the object destructor must call the destructor for the parent class explicitly as the very last statement
of the destructor. The TclObject destructor will invoke the instance procedure delete-shadow, that in turn invokes the
equivalent compiled method to destroy the shadow object. The interpreter itself will destroy the interpreted object.
3.4.2 Variable Bindings
In most cases, access to compiled member variables is restricted to compiled code, and access to interpreted member variables
is likewise confined to access via interpreted code; however, it is possible to establish bi-directional bindings such that both
the interpreted member variable and the compiled member variable access the same data, and changing the value of either
variable changes the value of the corresponding paired variable to same value.
The binding is established by the compiled constructor when that object is instantiated; it is automatically accessible by the
interpreted object as an instance variable. ns supports five different data types: reals, bandwidth valued variables, time valued
variables, integers, and booleans. The syntax of how these values can be specified in OTcl is different for each variable type.
Real and Integer valued variables are specified in the “normal” form. For example,
$object set realvar 1.2e3
$object set intvar 12
Bandwidth is specified as a real value, optionally suffixed by a ‘k’ or ‘K’ to mean kilo-quantities, or ‘m’ or ‘M’ to mean
mega-quantities. A final optional suffix of ‘B’ indicates that the quantity expressed is in Bytes per second. The default
is bandwidth expressed in bits per second. For example, all of the following are equivalent:
$object set bwvar 1.5m
$object set bwvar 1.5mb
$object set bwvar 1500k
23
$object
$object
$object
$object
set
set
set
set
bwvar
bwvar
bwvar
bwvar
1500kb
.1875MB
187.5kB
1.5e6
Time is specified as a real value, optionally suffixed by a ‘m’ to express time in milli-seconds, ‘n’ to express time in
nano-seconds, or ‘p’ to express time in pico-seconds. The default is time expressed in seconds. For example, all of the
following are equivalent:
$object
$object
$object
$object
set
set
set
set
timevar
timevar
timevar
timevar
1500m
1.5
1.5e9n
1500e9p
Note that we can also safely add a to reflect the time unit of seconds. ns will ignore anything other than a valid real
number specification, or a trailing ‘m’, ‘n’, or ‘p’.
Booleans can be expressed either as an integer, or as ‘T’ or ‘t’ for true. Subsequent characters after the first letter are
ignored. If the value is neither an integer, nor a true value, then it is assumed to be false. For example,
;# set to true
$object set boolvar t
$object set boolvar true
$object set boolvar 1
;# or any non-zero value
;# set to false
$object set boolvar false
$object set boolvar junk
$object set boolvar 0
The following example shows the constructor for the ASRMAgent 3 .
ASRMAgent::ASRMAgent() {
bind("pdistance_", &pdistance_);
bind("requestor_", &requestor_);
bind_time("lastSent_", &lastSessSent_);
bind_bw("ctrlLimit_", &ctrlBWLimit_);
bind_bool("running_", &running_);
}
/* real variable */
/* integer variable */
/* time variable */
/* bandwidth variable */
/* boolean variable */
Note that all of the functions above take two arguments, the name of an OTcl variable, and the address of the corresponding
compiled member variable that is linked. While it is often the case that these bindings are established by the constructor of
the object, it need not always be done in this manner. We will discuss such alternate methods when we describe the class
InstVar (Section 3.8) in detail later.
Each of the variables that is bound is automatically initialised with default values when the object is created. The default
values are specified as interpreted class variables. This initialisation is done by the routing init-instvar{}, invoked by
methods in the class Instvar, described later (Section 3.8). init-instvar{} checks the class of the interpreted object, and
all of the parent class of that object, to find the first class in which the variable is defined. It uses the value of the variable in
that class to initialise the object. Most of the bind initialisation values are defined in ~ns/tcl/lib/ns-default.tcl.
For example, if the following class variables are defined for the ASRMAgent:
3 Note
that this constructor is embellished to illustrate the features of the variable binding mechanism.
24
Agent/SRM/Adaptive set pdistance_ 15.0
Agent/SRM set pdistance_ 10.0
Agent/SRM set lastSent_ 8.345m
Agent set ctrlLimit_
1.44M
Agent/SRM/Adaptive set running_ f
Therefore, every new Agent/SRM/Adaptive object will have pdistance_ set to 15.0; lastSent_ is set to 8.345m from
the setting of the class variable of the parent class; ctrlLimit_ is set to 1.44M using the class variable of the parent class
twice removed; running is set to false; the instance variable pdistance_ is not initialised, because no class variable exists
in any of the class hierarchy of the interpreted object. In such instance, init-instvar{} will invoke warn-instvar{},
to print out a warning about such a variable. The user can selectively override this procedure in their simulation scripts, to
elide this warning.
Note that the actual binding is done by instantiating objects in the class InstVar. Each object in the class InstVar binds one
compiled member variable to one interpreted member variable. A TclObject stores a list of InstVar objects corresponding to
each of its member variable that is bound in this fashion. The head of this list is stored in its member variable instvar_ of
the TclObject.
One last point to consider is that ns will guarantee that the actual values of the variable, both in the interpreted object and the
compiled object, will be identical at all times. However, if there are methods and other variables of the compiled object that
track the value of this variable, they must be explicitly invoked or changed whenever the value of this variable is changed.
This usually requires additional primitives that the user should invoke. One way of providing such primitives in ns is through
the command() method described in the next section.
3.4.3 Variable Tracing
In addition to variable bindings, TclObject also supports tracing of both C++ and Tcl instance variables. A traced variable
can be created and configured either in C++ or Tcl. To establish variable tracing at the Tcl level, the variable must be visible
in Tcl, which means that it must be a bounded C++/Tcl or a pure Tcl instance variable. In addition, the object that owns
the traced variable is also required to establish tracing using the Tcl trace method of TclObject. The first argument to the
trace method must be the name of the variable. The optional second argument specifies the trace object that is responsible
for tracing that variable. If the trace object is not specified, the object that own the variable is responsible for tracing it.
For a TclObject to trace variables, it must extend the C++ trace method that is virtually defined in TclObject. The Trace
class implements a simple trace method, thereby, it can act as a generic tracer for variables.
class Trace : public Connector {
...
virtual void trace(TracedVar*);
};
Below is a simple example for setting up variable tracing in Tcl:
# \$tcp tracing its own variable cwnd_
\$tcp trace cwnd_
# the variable ssthresh_ of \$tcp is traced by a generic \$tracer
set tracer [new Trace/Var]
\$tcp trace ssthresh_ \$tracer
25
For a C++ variable to be traceable, it must belong to a class that derives from TracedVar. The virtual base class TracedVar
keeps track of the variable’s name, owner, and tracer. Classes that derives from TracedVar must implement the virtual method
value, that takes a character buffer as an argument and writes the value of the variable into that buffer.
class TracedVar {
...
virtual char* value(char* buf) = 0;
protected:
TracedVar(const char* name);
const char* name_;
// name of the variable
TclObject* owner_;
// the object that owns this variable
TclObject* tracer_;
// callback when the variable is changed
...
};
The TclCL library exports two classes of TracedVar: TracedInt and TracedDouble. These classes can be used in
place of the basic type int and double respectively. Both TracedInt and TracedDouble overload all the operators that can
change the value of the variable such as assignment, increment, and decrement. These overloaded operators use the assign
method to assign the new value to the variable and call the tracer if the new value is different from the old one. TracedInt and
TracedDouble also implement their value methods that output the value of the variable into string. The width and precision
of the output can be pre-specified.
3.4.4 command Methods: Definition and Invocation
For every TclObject that is created, ns establishes the instance procedure, cmd{}, as a hook to executing methods through the
compiled shadow object. The procedure cmd{} invokes the method command() of the shadow object automatically, passing
the arguments to cmd{} as an argument vector to the command() method.
The user can invoke the cmd{} method in one of two ways: by explicitly invoking the procedure, specifying the desired
operation as the first argument, or implicitly, as if there were an instance procedure of the same name as the desired operation.
Most simulation scripts will use the latter form, hence, we will describe that mode of invocation first.
Consider the that the distance computation in SRM is done by the compiled object; however, it is often used by the interpreted
object. It is usually invoked as:
$srmObject distance? agentAddress
If there is no instance procedure called distance?, the interpreter will invoke the instance procedure unknown{}, defined
in the base class TclObject. The unknown procedure then invokes
$srmObject cmd distance? agentAddress
to execute the operation through the compiled object’s command() procedure.
Ofcourse, the user could explicitly invoke the operation directly. One reason for this might be to overload the operation by
using an instance procedure of the same name. For example,
Agent/SRM/Adaptive instproc distance? addr {
26
$self instvar distanceCache_
if ![info exists distanceCache_($addr)] {
set distanceCache_($addr) [$self cmd distance? $addr]
}
set distanceCache_($addr)
}
We now illustrate how the command() method using ASRMAgent::command() as an example.
int ASRMAgent::command(int argc, const char*const*argv) {
Tcl& tcl = Tcl::instance();
if (argc == 3) {
if (strcmp(argv[1], "distance?") == 0) {
int sender = atoi(argv[2]);
SRMinfo* sp = get_state(sender);
tcl.tesultf("%f", sp->distance_);
return TCL_OK;
}
}
return (SRMAgent::command(argc, argv));
}
We can make the following observations from this piece of code:
The function is called with two arguments:
The first argument (argc) indicates the number of arguments specified in the command line to the interpreter.
The command line arguments vector (argv) consists of
— argv[0] contains the name of the method, “cmd”.
— argv[1] specifies the desired operation.
— If the user specified any arguments, then they are placed in argv[2...(argc - 1)].
The arguments are passed as strings; they must be converted to the appropriate data type.
If the operation is successfully matched, the match should return the result of the operation using methods described
earlier (Section 3.3.3).
command() itself must return either TCL_OK or TCL_ERROR to indicate success or failure as its return code.
If the operation is not matched in this method, it must invoke its parent’s command method, and return the corresponding
result.
This permits the user to concieve of operations as having the same inheritance properties as instance procedures or
compiled methods.
In the event that this command method is defined for a class with multiple inheritance, the programmer has the liberty
to choose one of two implementations:
1) Either they can invoke one of the parent’s command method, and return the result of that invocation, or
2) They can each of the parent’s command methods in some sequence, and return the result of the first invocation that
is successful. If none of them are successful, then they should return an error.
In our document, we call operations executed through the command() instproc-likes. This reflects the usage of these operations as if they were OTcl instance procedures of an object, but can be very subtly different in their realisation and usage.
27
3.5 Class TclClass
This compiled class (class TclClass) is a pure virtual class. Classes derived from this base class provide two functions:
construct the interpreted class hierarchy to mirror the compiled class hierarchy; and provide methods to instantiate new
TclObjects. Each such derived class is associated with a particular compiled class in the compiled class hierarchy, and can
instantiate new objects in the associated class.
As an example, consider a class such as the class RenoTcpClass. It is derived from class TclClass, and is associated
with the class RenoTcpAgent. It will instantiate new objects in the class RenoTcpAgent. The compiled class hierarchy
for RenoTcpAgent is that it derives from TcpAgent, that in turn derives from Agent, that in turn derives (roughly) from
TclObject. RenoTcpClass is defined as
static class RenoTcpClass: public TclClass {
public:
RenoTcpClass() : TclClass("Agent/TCP/Reno") {}
TclObject* create(int argc, const char*const* argv) {
return (new RenoTcpAgent());
}
} class_reno;
We can make the following observations from this definition:
1. The class defines only the constructor, and one additional method, to create instances of the associated TclObject.
2. ns will execute the RenoTcpClass constructor for the static variable class_reno, when it is first started. This sets
up the appropriate methods and the interpreted class hierarchy.
3. The constructor specifies the interpreted class explicitly as Agent/TCP/Reno. This also specifies the interpreted
class hierarchy implicitly.
Recall that the convention in ns is to use the character slash (’/’) is a separator. For any given class A/B/C/D, the
class A/B/C/D is a sub-class of A/B/C, that is itself a sub-class of A/B, that, in turn, is a sub-class of A. A itself is a
sub-class of TclObject.
In our case above, the TclClass constructor creates three classes, Agent/TCP/Reno sub-class of Agent/TCP subclass of Agent sub-class of TclObject.
4. This class is associated with the class RenoTcpAgent; it creats new objects in this associated class.
5. The RenoTcpClass::create method returns TclObjects in the class RenoTcpAgent.
6. When the user specifies new Agent/TCP/Reno, the routine RenoTcpClass::create is invoked.
7. The arguments vector (argv) consists of
— argv[0] contains the name of the object.
— argv[1...3] contain $self, $class, and $proc.Since create is called through the instance procedure
create-shadow, argv[3] contains create-shadow.
— argv[4] contain any additional arguments (passed as a string) provided by the user.
The class Trace illustrates argument handling by TclClass methods.
class TraceClass : public TclClass {
public:
28
TraceClass() : TclClass("Trace") {}
TclObject* create(int args, const char*const* argv) {
if (args >= 5)
return (new Trace(*argv[4]));
else
return NULL;
}
} trace_class;
A new Trace object is created as
new Trace "X"
Finally, the nitty-gritty details of how the interpreted class hierarchy is constructed:
1. The object constructor is executed when ns first starts.
2. This constructor calls the TclClass constructor with the name of the interpreted class as its argument.
3. The TclClass constructor stores the name of the class, and inserts this object into a linked list of the TclClass objects.
4. During initialization of the simulator, Tcl_AppInit(void) invokes TclClass::bind(void)
5. For each object in the list of TclClass objects, bind() invokes register{}, specifying the name of the interpreted
class as its argument.
6. register{} establishes the class hierarchy, creating the classes that are required, and not yet created.
7. Finally, bind() defines instance procedures create-shadow and delete-shadow for this new class.
3.5.1 How to Bind Static C++ Class Member Variables
In Section 3.4, we have seen how to expose member variables of a C++ object into OTcl space. This, however, does not apply
to static member variables of a C++ class. Of course, one may create an OTcl variable for the static member variable of every
C++ object; obviously this defeats the whole meaning of static members.
We cannot solve this binding problem using a similar solution as binding in TclObject, which is based on InstVar, because
InstVars in TclCL require the presence of a TclObject. However, we can create a method of the corresponding TclClass and
access static members of a C++ class through the methods of its corresponding TclClass. The procedure is as follows:
1. Create your own derived TclClass as described above;
2. Declare methods bind() and method() in your derived class;
3. Create your binding methods in the implementation of your bind() with add_method("your_method"), then
implement the handler in method() in a similar way as you would do in TclObject::command(). Notice that the
number of arguments passed to TclClass::method() are different from those passed to TclObject::command().
The former has two more arguments in the front.
As an example, we show a simplified version of PacketHeaderClass in ~ns/packet.cc. Suppose we have the following
class Packet which has a static variable hdrlen_ that we want to access from OTcl:
29
class Packet {
......
static int hdrlen_;
};
Then we do the following to construct an accessor for this variable:
class PacketHeaderClass : public TclClass {
protected:
PacketHeaderClass(const char* classname, int hdrsize);
TclObject* create(int argc, const char*const* argv);
/* These two implements OTcl class access methods */
virtual void bind();
virtual int method(int argc, const char*const* argv);
};
void PacketHeaderClass::bind()
{
/* Call to base class bind() must precede add_method() */
TclClass::bind();
add_method("hdrlen");
}
int PacketHeaderClass::method(int ac, const char*const* av)
{
Tcl& tcl = Tcl::instance();
/* Notice this argument translation; we can then handle them as if in TclObject::command() */
int argc = ac - 2;
const char*const* argv = av + 2;
if (argc == 2) {
if (strcmp(argv[1], "hdrlen") == 0) {
tcl.resultf("%d", Packet::hdrlen_);
return (TCL_OK);
}
} else if (argc == 3) {
if (strcmp(argv[1], "hdrlen") == 0) {
Packet::hdrlen_ = atoi(argv[2]);
return (TCL_OK);
}
}
return TclClass::method(ac, av);
}
After this, we can then use the following OTcl command to access and change values of Packet::hdrlen_:
PacketHeader hdrlen 120
set i [PacketHeader hdrlen]
30
3.6 Class TclCommand
This class (class TclCommand) provides just the mechanism for ns to export simple commands to the interpreter, that can
then be executed within a global context by the interpreter. There are two functions defined in ~ns/misc.cc: ns-random and
ns-version. These two functions are initialized by the function init_misc(void), defined in ~ns/misc.cc; init_misc
is invoked by Tcl_AppInit(void) during startup.
class VersionCommand defines the command ns-version. It takes no argument, and returns the current ns
version string.
;# get the current version
% ns-version
2.0a12
class RandomCommand defines the command ns-random. With no argument, ns-random returns an integer,
uniformly distributed in the interval .
When specified an argument, it takes that argument as the seed. If this seed value is 0, the command uses a heuristic
seed value; otherwise, it sets the seed for the random number generator to the specified value.
;# return a random number
% ns-random
2078917053
% ns-random 0
858190129
% ns-random 23786
23786
;#set the seed heuristically
;#set seed to specified value
Note that, it is generally not advisable to construct top-level commands that are available to the user. We now describe how
to define a new command using the example class say_hello. The example defines the command hi, to print the string
“hello world”, followed by any command line arguments specified by the user. For example,
% hi this is ns [ns-version]
hello world, this is ns 2.0a12
1. The command must be defined within a class derived from the class TclCommand. The class definition is:
class say_hello : public TclCommand {
public:
say_hello();
int command(int argc, const char*const* argv);
};
2. The constructor for the class must invoke the TclCommand constructor with the command as argument; i.e.,
say_hello() : TclCommand("hi") {}
The TclCommand constructor sets up "hi" as a global procedure that invokes TclCommand::dispatch_cmd().
3. The method command() must perform the desired action.
The method is passed two arguments. The first argument, argc, contains the number of actual arguments passed by
the user.
31
The actual arguments passed by the user are passed as an argument vector (argv) and contains the following:
— argv[0] contains the name of the command (hi).
— argv[1...(argc - 1)] contains additional arguments specified on the command line by the user.
command() is invoked by dispatch_cmd().
/* because we are using stream I/O */
#include
int say_hello::command(int argc, const char*const* argv) {
cout << "hello world:";
for (int i = 1; i < argc; i++)
cout << ’ ’ << argv[i];
cout << ’ n’;
return TCL_OK;
}
4. Finally, we require an instance of this class. TclCommand instances are created in the routine init_misc(void).
new say_hello;
Note that there used to be more functions such as ns-at and ns-now that were accessible in this manner. Most of these
functions have been subsumed into existing classes. In particular, ns-at and ns-now are accessible through the scheduler
TclObject. These functions are defined in ~ns/tcl/lib/ns-lib.tcl.
;# get new instance of simulator
% set ns [new Simulator]
_o1
% $ns now
0
% $ns at ...
...
;# query simulator for current time
;# specify at operations for simulator
3.7 Class EmbeddedTcl
ns permits the development of functionality in either compiled code, or through interpreter code, that is evaluated at initialization. For example, the scripts ~tclcl/tcl-object.tcl or the scripts in ~ns/tcl/lib. Such loading and evaluation of scripts is done
through objects in the class EmbeddedTcl.
The easiest way to extend ns is to add OTcl code to either ~tclcl/tcl-object.tcl or through scripts in the ~ns/tcl/lib directory.
Note that, in the latter case, ns sources ~ns/tcl/lib/ns-lib.tcl automatically, and hence the programmer must add a couple of lines
to this file so that their script will also get automatically sourced by ns at startup. As an example, the file ~ns/tcl/mcast/srm.tcl
defines some of the instance procedures to run SRM. In ~ns/tcl/lib/ns-lib.tcl, we have the lines:
source tcl/mcast/srm.tcl
to automatically get srm.tcl sourced by ns at startup.
Three points to note with EmbeddedTcl code are that firstly, if the code has an error that is caught during the eval, then ns will
not run. Secondly, the user can explicitly override any of the code in the scripts. In particular, they can re-source the entire
32
script after making their own changes. Finally, after adding the scripts to ~ns/tcl/lib/ns-lib.tcl, and every time thereafter that
they change their script, the user must recompile ns for their changes to take effect. Of course, in most cases 4 , the user can
source their script to override the embedded code.
The rest of this subsection illustrate how to integrate individual scripts directly into ns. The first step is convert the script into
an EmbeddedTcl object. The lines below expand ns-lib.tcl and create the EmbeddedTcl object instance called et_ns_lib:
tclsh bin/tcl-expand.tcl tcl/lib/ns-lib.tcl |
../Tcl/tcl2c++ et_ns_lib > gen/ns_tcl.cc
The script, ~ns/bin/tcl-expand.tcl expands ns-lib.tcl by replacing all source lines with the corresponding source files.
The program, ~tclcl/tcl2cc.c, converts the OTcl code into an equivalent EmbeddedTcl object, et_ns_lib.
During initialization, invoking the method EmbeddedTcl::load explicitly evaluates the array.
— ~tclcl/tcl-object.tcl is evaluated by the method Tcl::init(void); Tcl_AppInit() invokes Tcl::Init(). The
exact command syntax for the load is:
et_tclobject.load();
— Similarly, ~ns/tcl/lib/ns-lib.tcl is evaluated directly by Tcl_AppInit in ~ns/ns_tclsh.cc.
et_ns_lib.load();
3.8 Class InstVar
This section describes the internals of the class InstVar. This class defines the methods and mechanisms to bind a C++
member variable in the compiled shadow object to a specified OTcl instance variable in the equivalent interpreted object. The
binding is set up such that the value of the variable can be set or accessed either from within the interpreter, or from within
the compiled code at all times.
There are five instance variable classes: class InstVarReal, class InstVarTime, class InstVarBandwidth,
class InstVarInt, and class InstVarBool, corresponding to bindings for real, time, bandwidth, integer, and
boolean valued variables respectively.
We now describe the mechanism by which instance variables are set up. We use the class InstVarReal to illustrate the
concept. However, this mechanism is applicable to all five types of instance variables.
When setting up an interpreted variable to access a member variable, the member functions of the class InstVar assume that
they are executing in the appropriate method execution context; therefore, they do not query the interpreter to determine the
context in which this variable must exist.
In order to guarantee the correct method execution context, a variable must only be bound if its class is already established
within the interpreter, and the interpreter is currently operating on an object in that class. Note that the former requires that
when a method in a given class is going to make its variables accessible via the interpreter, there must be an associated
4 The few places where this might not work are when certain variables might have to be defined or undefined, or otherwise the script contains code other
than procedure and variable definitions and executes actions directly that might not be reversible.
33
class TclClass (Section 3.5) defined that identifies the appropriate class hierarchy to the interpreter. The appropriate method
execution context can therefore be created in one of two ways.
An implicit solution occurs whenever a new TclObject is created within the interpreter. This sets up the method execution
context within the interpreter. When the compiled shadow object of the interpreted TclObject is created, the constructor for
that compiled object can bind its member variables of that object to interpreted instance variables in the context of the newly
created interpreted object.
An explicit solution is to define a bind-variables operation within a command function, that can then be invoked
via the cmd method. The correct method execution context is established in order to execute the cmd method. Likewise,
the compiled code is now operating on the appropriate shadow object, and can therefore safely bind the required member
variables.
An instance variable is created by specifying the name of the interpreted variable, and the address of the member variable in
the compiled object. The constructor for the base class InstVar creates an instance of the variable in the interpreter, and then
sets up a trap routine to catch all accesses to the variable through the interpreter.
Whenever the variable is read through the interpreter, the trap routine is invoked just prior to the occurrence of the read. The
routine invokes the appropriate get function that returns the current value of the variable. This value is then used to set the
value of the interpreted variable that is then read by the interpreter.
Likewise, whenever the variable is set through the interpreter, the trap routine is invoked just after to the write is completed.
The routine gets the current value set by the interpreter, and invokes the appropriate set function that sets the value of the
compiled member to the current value set within the interpreter.
34
Part II
Simulator Basics
35
Chapter 4
The Class Simulator
The overall simulator is described by a Tcl class Simulator. It provides a set of interfaces for configuring a simulation
and for choosing the type of event scheduler used to drive the simulation. A simulation script generally begins by creating an
instance of this class and calling various methods to create nodes, topologies, and configure other aspects of the simulation.
A subclass of Simulator called OldSim is used to support ns v1 backward compatibility.
The procedures and functions described in this chapter can be found in ~ns/tcl/lib/ns-lib.tcl, ~ns/scheduler.{cc,h}, and,
~ns/heap.h.
4.1 Simulator Initialization
When a new simulation object is created in tcl, the initialization procedure performs the following operations:
initialize the packet format (calls create_packetformat)
create a scheduler (defaults to a calendar scheduler)
create a “null agent” (a discard sink used in various places)
The packet format initialization sets up field offsets within packets used by the entire simulation. It is described in more detail
in the following chapter on packets (Chapter 11). The scheduler runs the simulation in an event-driven manner and may be
replaced by alternative schedulers which provide somewhat different semantics (see the following section for more detail).
The null agent is created with the following call:
set nullAgent_ [new Agent/Null]
This agent is generally useful as a sink for dropped packets or as a destination for packets that are not counted or recorded.
4.2 Schedulers and Events
The simulator is an event-driven simulator. There are presently four schedulers available in the simulator, each of which
is implemented using a different data structure: a simple linked-list, heap, calendar queue (default), and a special type
36
called “real-time”. Each of these are described below. The scheduler runs by selecting the next earliest event, executing it
to completion, and returning to execute the next event. Presently, the simulator is single-threaded, and only one event in
execution at any given time. If more than one event are scheduled to execute at the same time, their execution is performed
on the first scheduled – first dispatched manner. Simultaneous events are not re-ordered anymore by schedulers (as it was in
earlier versions) and all schedulers should yeild the same order of dispatching given the same input.
No partial execution of events or pre-emption is supported.
An event generally comprises a “firing time” and a handler function. The actual definition of an event is found in ~ns/scheduler.h:
class Event {
public:
Event* next_;
/* event list */
Handler* handler_;
/* handler to call when event ready */
double time_;
/* time at which event is ready */
int uid_;
/* unique ID */
Event() : time_(0), uid_(0) {}
};
/*
* The base class for all event handlers. When an event’s scheduled
* time arrives, it is passed to handle which must consume it.
* i.e., if it needs to be freed it, it must be freed by the handler.
*/
class Handler {
public:
virtual void handle(Event* event);
};
Two types of objects are derived from the base class Event: packets and “at-events”. Packets are described in detail in
the next chapter (Chapter 11.2.1). An at-event is a tcl procedure execution scheduled to occur at a particular time. This is
frequently used in simulation scripts. A simple example of how it is used is as follows:
...
set ns_ [new Simulator]
$ns_ use-scheduler Heap
$ns_ at 300.5 "$self complete_sim"
...
This tcl code fragment first creates a simulation object, then changes the default scheduler implementation to be heap-based
(see below), and finally schedules the function $self complete_sim to be executed at time 300.5 (seconds)(Note that
this particular code fragment expects to be encapsulated in an object instance procedure, where the appropriate reference to
$self is correctly defined.). At-events are implemented as events where the handler is effectively an execution of the tcl
interpreter.
4.2.1 The List Scheduler
The list scheduler (class Scheduler/List) implements the scheduler using a simple linked-list structure. The list is
kept in time-order (earliest to latest), so event insertion and deletion require scanning the list to find the appropriate entry.
Choosing the next event for execution requires trimming the first entry off the head of the list. This implementation preserves
event execution in a FIFO manner for simultaneous events.
37
4.2.2 the heap scheduler
The heap scheduler (class Scheduler/Heap) implements the scheduler using a heap structure. This structure is superior to the list structure for a large number of events, as insertion and deletion times are in for events. This
implementation in ns v2 is borrowed from the MaRS-2.0 simulator [1]; it is believed that MaRS itself borrowed the code from
NetSim [11], although this lineage has not been completely verified.
4.2.3 The Calendar Queue Scheduler
The calendar queue scheduler (class Scheduler/Calendar) uses a data structure analogous to a one-year desk calendar, in which events on the same month/day of multiple years can be recorded in one day. It is formally described in [6],
and informally described in Jain (p. 410) [12]. The implementation of Calendar queues in ns v2 was contributed by David
Wetherall (presently at MIT/LCS).
4.2.4 The Real-Time Scheduler
The real-time scheduler (class Scheduler/RealTime) attempts to synchronize the execution of events with real-time.
It is currently implemented as a subclass of the list scheduler. The real-time capability in ns is still under development,
but is used to introduce an ns simulated network into a real-world topology to experiment with easily-configured network
topologies, cross-traffic, etc. This only works for relatively slow network traffic data rates, as the simulator must be able to
keep pace with the real-world packet arrival rate, and this synchronization is not presently enforced.
4.3 Other Methods
The Simulator class provides a number of methods used to set up the simulation. They generally fall into three categories:
methods to create and manage the topology (which in turn consists of managing the nodes (Chapter 5) and managing t
he links (Chapter 6)), methods to perform tracing (Chapter 21), and helper functions to deal with the scheduler. The following
is a list of the non-topology related simulator methods:
Simulator
Simulator
Simulator
Simulator
Simulator
Simulator
Simulator
Simulator
instproc
instproc
instproc
instproc
instproc
instproc
instproc
instproc
now
;# return scheduler’s notion of current time
at args
;# schedule execution of code at specified time
cancel args
;# cancel event
run args
;# start scheduler
halt
;# stop (pause) the scheduler
flush-trace
;# flush all trace object write buffers
create-trace type files src dst
;# create trace object
create_packetformat
;# set up the simulator’s packet format
38
4.4 Commands at a glance
Synopsis:
ns ..
Description:
Basic command to run a simulation script in ns.
The simulator (ns) is invoked via the ns interpreter, an extension of the
vanilla otclsh command shell. A simulation is defined by a OTcl script
(file). Several examples of OTcl scripts can be found under ns/tcl/ex
directory.
The following is a list of simulator commands commonly used in simulation
scripts:
set ns_ [new Simulator]
This command creates an instance of the simulator object.
set now [$ns_ now]
The scheduler keeps track of time in a simulation. This returns scheduler’s
notion of current time.
$ns_ halt
This stops or pauses the scheduler.
$ns_ run
This starts the scheduler.
$ns_ at