前言：我本來是一個(gè)準(zhǔn)備在機(jī)器學(xué)習(xí)領(lǐng)域大展拳腳的一個(gè)人，但是由于科研訓(xùn)練項(xiàng)目網(wǎng)絡(luò)態(tài)勢感知的需要，我需要學(xué)習(xí)一些網(wǎng)絡(luò)的姿勢，以及NS2模擬工具的使用，但是在我真正接觸NS2的時(shí)候，才知道這是一坨年代久遠(yuǎn)，斷層嚴(yán)重的屎，會(huì)的人用的特別好，不會(huì)的人又沒有問路的地方，在GFW里面一搜，所有資料都停留在12年以前，并且大多停留在了編寫TCL腳本的層面，可是這個(gè)程度與真正的讓NS2發(fā)揮威力，還相差甚遠(yuǎn)，所以我決定，在學(xué)習(xí)NS2的過程中，順便做一份入門教程出來。
所以什么是NS2
本著要問為什么，先問是什么的原則，我們來看一下，NS2到底是什么？
NS2（Network Simulator,version 2）是一種面向?qū)ο?/a>的網(wǎng)絡(luò)仿真器，本質(zhì)上是一個(gè)離散事件模擬器,由UC Berkeley開發(fā)而成。它本身有一個(gè)虛擬時(shí)鐘，所有的仿真都由離散事件驅(qū)動(dòng)的。目前NS2可以用于仿真各種不同的IP網(wǎng)，已經(jīng)實(shí)現(xiàn)的一些仿真有網(wǎng)絡(luò)傳輸協(xié)議，比如TCP和UDP,業(yè)務(wù)源流量產(chǎn)生器，比如FTP,Telnet,Web CBR和VBR；路由隊(duì)列管理機(jī)制，比如Droptail,RED和CBQ；路由算法，比如AODV、DSDV、DSR等無線路由協(xié)議。NS2也為進(jìn)行局域網(wǎng)的仿真而實(shí)現(xiàn)了多播以及一些MAC 子層協(xié)議。
說了這么多，其實(shí)就是一句話：
C++和OTCL編寫的用于網(wǎng)絡(luò)方面的模擬器
NS2的內(nèi)核由C++ 編寫，前端則是OTCL的解釋器。
NS2如何工作
既然要深入到NS2的源碼，那么對于他的結(jié)構(gòu)層次，就一定得明白。
首先，我們得知道，在整個(gè)NS2中有兩個(gè)層次：
- 解釋層次
- 編譯層次
解釋層次：就是OTCL解釋器的層次
編譯層次：就是C++編譯器的層次
如果你對NS2稍微有些了解，你就會(huì)知道，NS2平時(shí)的工作是通過編寫TCL代碼來實(shí)現(xiàn)的。
但是我們又知道NS2的內(nèi)核功能實(shí)際上是C++實(shí)現(xiàn)的，那么怎么將TCL編寫的代碼轉(zhuǎn)換到C++上呢？
這里就需要提到，NS2的搭建哲學(xué)了——分裂對象模型：
什么是分裂對象模型呢？
這應(yīng)該是NS2提出的一種模型或者叫做構(gòu)建方法。（猜測，沒有查到相關(guān)資料），而在NS2上具體來說呢，就是：
每實(shí)例化一個(gè)構(gòu)件時(shí)，都會(huì)同時(shí)創(chuàng)建一個(gè)Otcl中的對象和一個(gè)對應(yīng)的C++對象，兩個(gè)對象可以互操作。
分裂對象模型中的Otcl類：解釋類， 對應(yīng)的C++類： 編譯類?；橛跋耦?。
這里我也要更正，我原來認(rèn)識的錯(cuò)誤地方：
shadow object并不是特指編譯層次的對象，而是說，解釋類的對象與編譯類的互為shadow object。
-
TclObject并不是所有類（C++和Otcl）的父類，這也就解釋了我之前的疑問，C++的類如何作為Otcl的父類。真正的情況應(yīng)該是：
TclObject:：所有編譯類的基類
SplitObject：所有解釋類的基類
這里就提到了，兩個(gè)層次的轉(zhuǎn)換，兩個(gè)層次的轉(zhuǎn)換是通過一個(gè)C++的類TclObject來實(shí)現(xiàn)的，而解釋器類層次怎么建立呢？這里涉及到一個(gè)類TclClass，它里面定義的方法解決了這個(gè)問題。這是NS2的主要層次結(jié)構(gòu)，所以也會(huì)有其他不同的結(jié)構(gòu)，這里暫時(shí)不提。
當(dāng)然，如果你對上面的解釋很模糊的話，也沒有關(guān)系，我們結(jié)合后面講到的分裂對象模型，你一定會(huì)明白的。
為什么NS2用兩種語言？
其實(shí)，這個(gè)問題對于很多python的程序員，應(yīng)該很容易理解，因?yàn)樵诠ぷ髦?，其?shí)很容易感覺到，python的速度慢，導(dǎo)致在許多要求性能，時(shí)間精度的地方?jīng)]法使用，所以采用C++/C來實(shí)現(xiàn)性能要求高的地方。
那么為什么不用C/C++作為主要開發(fā)語言呢？
原因一目了然：開發(fā)效率太低
如果你需要設(shè)置一個(gè)簡單的CBR流量發(fā)生器，結(jié)果用C++揚(yáng)揚(yáng)灑灑的寫了300行，還沒寫好，你就知道，在不要求性能的地方，使用簡單的腳本語言是多么的舒服。這也就是TCL的優(yōu)勢所在。
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中有關(guān)網(wǎng)絡(luò)仿真的分層編程的文章。
