前言：我本来是一个准备在机器学习领域大展拳脚的一个人，但是由于科研训练项目网络态势感知的需要，我需要学习一些网络的姿势，以及NS2模拟工具的使用，但是在我真正接触NS2的时候，才知道这是一坨年代久远，断层严重的屎，会的人用的特别好，不会的人又没有问路的地方，在GFW里面一搜，所有资料都停留在12年以前，并且大多停留在了编写TCL脚本的层面，可是这个程度与真正的让NS2发挥威力，还相差甚远，所以我决定，在学习NS2的过程中，顺便做一份入门教程出来。
所以什么是NS2
本着要问为什么，先问是什么的原则，我们来看一下，NS2到底是什么？
NS2（Network Simulator,version 2）是一种面向对象的网络仿真器，本质上是一个离散事件模拟器,由UC Berkeley开发而成。它本身有一个虚拟时钟，所有的仿真都由离散事件驱动的。目前NS2可以用于仿真各种不同的IP网，已经实现的一些仿真有网络传输协议，比如TCP和UDP,业务源流量产生器，比如FTP,Telnet,Web CBR和VBR；路由队列管理机制，比如Droptail,RED和CBQ；路由算法，比如AODV、DSDV、DSR等无线路由协议。NS2也为进行局域网的仿真而实现了多播以及一些MAC 子层协议。
说了这么多，其实就是一句话：
C++和OTCL编写的用于网络方面的模拟器
NS2的内核由C++ 编写，前端则是OTCL的解释器。
NS2如何工作
既然要深入到NS2的源码，那么对于他的结构层次，就一定得明白。
首先，我们得知道，在整个NS2中有两个层次：
- 解释层次
- 编译层次
解释层次：就是OTCL解释器的层次
编译层次：就是C++编译器的层次
如果你对NS2稍微有些了解，你就会知道，NS2平时的工作是通过编写TCL代码来实现的。
但是我们又知道NS2的内核功能实际上是C++实现的，那么怎么将TCL编写的代码转换到C++上呢？
这里就需要提到，NS2的搭建哲学了——分裂对象模型：
什么是分裂对象模型呢？
这应该是NS2提出的一种模型或者叫做构建方法。（猜测，没有查到相关资料），而在NS2上具体来说呢，就是：
每实例化一个构件时，都会同时创建一个Otcl中的对象和一个对应的C++对象，两个对象可以互操作。
分裂对象模型中的Otcl类：解释类， 对应的C++类： 编译类。互为影像类。
这里我也要更正，我原来认识的错误地方：
shadow object并不是特指编译层次的对象，而是说，解释类的对象与编译类的互为shadow object。
-
TclObject并不是所有类（C++和Otcl）的父类，这也就解释了我之前的疑问，C++的类如何作为Otcl的父类。真正的情况应该是：
TclObject:：所有编译类的基类
SplitObject：所有解释类的基类
这里就提到了，两个层次的转换，两个层次的转换是通过一个C++的类TclObject来实现的，而解释器类层次怎么建立呢？这里涉及到一个类TclClass，它里面定义的方法解决了这个问题。这是NS2的主要层次结构，所以也会有其他不同的结构，这里暂时不提。
当然，如果你对上面的解释很模糊的话，也没有关系，我们结合后面讲到的分裂对象模型，你一定会明白的。
为什么NS2用两种语言？
其实，这个问题对于很多python的程序员，应该很容易理解，因为在工作中，其实很容易感觉到，python的速度慢，导致在许多要求性能，时间精度的地方没法使用，所以采用C++/C来实现性能要求高的地方。
那么为什么不用C/C++作为主要开发语言呢？
原因一目了然：开发效率太低
如果你需要设置一个简单的CBR流量发生器，结果用C++扬扬洒洒的写了300行，还没写好，你就知道，在不要求性能的地方，使用简单的脚本语言是多么的舒服。这也就是TCL的优势所在。
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++.
如果想了解更多，可以看一下IEEE中有关网络仿真的分层编程的文章。
