NS2网络模拟器手册

需积分: 9 153 浏览量更新于2024-07-19 收藏 1.39MB PDF 举报

"The NS2 Manual" 《NS2手册》是网络模拟器NS2的重要参考资料，由UC Berkeley、LBL（劳伦斯伯克利国家实验室）、USC/ISI（南加州大学信息科学研究所）和Xerox PARC的研究人员共同合作完成。手册的主要编辑者包括Kevin Fall和Kannan Varadhan。这份文档的最新版本日期为2004年10月26日。 NS2，全称为LBNL's Network Simulator（劳伦斯伯克利国家实验室的网络模拟器），是一个用C++编写的软件，它采用OTcl（Object-oriented Tcl）作为命令和配置接口。相对于NS1，NS2有三个主要改进： 1. 对象复杂性的降低：NS1中较复杂的对象被分解为更简单的组件，以提高灵活性和可组合性。这使得用户能够更容易地理解和定制模拟模型。 2. 配置接口升级：配置接口从传统的Tcl升级为OTcl，这是一种面向对象的Tcl版本，提供了更强大和灵活的脚本能力，便于模拟场景的设置和控制。 3. 与OTcl解释器的接口分离：NS2中的接口代码与主模拟器分开，这种设计增强了代码的模块化，使得模拟器的核心功能与脚本语言的实现相独立，提高了可维护性和扩展性。 NS2的文档提供HTML、Postscript和PDF三种格式，用户可以在http://www.isi.edu/nsnam/ns/ns-documentation.html找到这些文档的链接，方便根据个人需求选择合适的格式阅读和下载。 VINT项目是NS2背后的研发背景，它是一个由UC Berkeley、USC/ISI、LBL和Xerox PARC的专家们共同参与的合作项目，得到了美国国防高级研究计划局（DARPA）的资金支持。在各个机构下，项目分别由不同的DARPA grant资助，包括DABT63-96-C-0105、ABT63-96-C-0054以及在Xerox PARC下的其他资助。《NS2手册》是学习和使用NS2进行网络模拟的必备参考资料，它详尽地介绍了NS2的架构、使用方法、配置选项以及如何构建和分析网络模拟实验。对于网络工程、计算机科学和相关领域的研究人员和学生来说，这份手册具有极高的价值。

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 • nothing currently

Simulator Basics • 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

Routing • 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.)

• 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

Trafﬁc 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 trafﬁc sources

Application • is the non-Haobo http stuff documented? no.

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 inter-

preter (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 deﬁned in the class TclClass. user instantiated

objects are mirrored through methods deﬁned 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 efﬁciently 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, ﬁnd bug, ﬁx bug, recompile, re-run) is less important.

On the other hand, a large part of networkresearch involves slightly varying parameters orconﬁgurations, or quicklyexploring

a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since conﬁguration

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 conﬁguration. 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 [?]. For more information about split level programming for network simulation, see the ns paper [?].

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 conﬁguration, setup, and “one-time” stuff

• 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 ﬂow

• 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 ﬂow was started in OTcl and per-packet processing was all in C++. This approache

worked OK until we had 100s of ﬂows 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/hﬁlei to refer to a particular hﬁlei in the Tcl directory. Similarly, we will use the notation, ~ns/hﬁlei to

refer to a particular hﬁlei in the ns-2 directory.

There are a number of classes deﬁned in ~tclcl/. We only focus on the six that are used in ns: The Class Tcl (Section ??)

contains the methods that C++ code will use to access the interpreter. The class TclObject (Section ??) is the base class for

all simulator objects that are also mirrored in the compiled hierarchy. The class TclClass (Section ??) deﬁnes the interpreted

class hierarchy, and the methods to permit the user to instantiate TclObjects. The class TclCommand (Section ??) is used to

deﬁne simple global interpreter commands. The class EmbeddedTcl (Section ??) contains the methods to load higher level

builtin commands that make conﬁguring simulations easier. Finally, the class InstVar (Section ??) 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 ﬁle ~tclcl/tcl2c++.c is used in building ns, and is mentioned brieﬂy 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 communi-

cate 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

剩余394页未读，继续阅读

Wi-Fi研习者

粉丝: 2275
资源: 173

NS2网络模拟器手册

NS2 Manual

ns manual The VINT Project

The ns Manual A Collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC

The-Manual-Of-NS-In-Chinese.rar_网络_Unix_Linux_

ns-3-manual_r3.21

ns2.rar_ns2

VanetMobiSim_1_0__Manual.rar_CanuMobiSim_The Network_vehicular a

ns原版手册.pdf

ns手册（中文版)

NS2模拟器手册：功能升级与配置详解

最新资源