NS-2數(shù)據(jù)庫(kù)接口的研究與實(shí)現(xiàn)

摘 要:針對(duì)目前對(duì)網(wǎng)絡(luò)仿真運(yùn)行數(shù)據(jù)的分析仍然采用文本數(shù)據(jù)文件輸出，手工或自己編程序分析，工作量大，難以處理，提出了一種靈活開放的NS與關(guān)系數(shù)據(jù)庫(kù)的連接架構(gòu)，可以直接將仿真運(yùn)行數(shù)據(jù)導(dǎo)入至數(shù)據(jù)庫(kù)中進(jìn)行分析。通過一些實(shí)例來具體說明用關(guān)系數(shù)據(jù)庫(kù)分析NS運(yùn)行結(jié)果的優(yōu)點(diǎn)與方法。通過運(yùn)用數(shù)據(jù)庫(kù)的方法，數(shù)據(jù)之間的聯(lián)系能夠很好地體現(xiàn)，大大節(jié)省了數(shù)據(jù)分析的工作量，并且能夠?qū)Ψ抡娼Y(jié)果數(shù)據(jù)進(jìn)行多方面、多層次的深入挖掘。

關(guān)鍵詞:NS-2; 關(guān)系數(shù)據(jù)庫(kù); 接口; 無線自組織網(wǎng)絡(luò)

中圖分類號(hào):TP393

文獻(xiàn)標(biāo)志碼:A

文章編號(hào):1001-3695(2010)02-0623-05

doi:10.3969/j.issn.1001-3695.2010.02.061

Database interface research and implementation for NS-2

ZHOU Yong-kai1， YI Ping1，2， CAI Ji-wen1， TIAN Ye1， WANG Zhi-yang1

(1.Network Information Security Research Center of Ministry of Education， School of Information Security Engineering， Shanghai Jiaotong University， Shanghai 200240， China; 2.Key Laboratory of Child Development Learning Science of Ministry of Education， Southeast University， Nanjing 210096， China)

Abstract:NS-2 is an open source network simulation software which is widely used in research area. But most of the researchers still analyze NS-2’s simulation data manually or by writing some awk scripts， which is usually of heavy workload and hard to deal with the huge amount of data. This paper introduced a flexible and open architecture to connect NS-2 with relational database. NS users could design their own relational model and directly inject the simulation data into database. By adopting the database analyzing method， well embodied the relations among the data， thus the process of analyzing could be time-saving， and multi-level， multi-depth analysis could be archived.

Key words:NS-2; relational database; interface; wireless Ad hoc networks

0 引言

NS-2是當(dāng)今學(xué)術(shù)界十分流行的一款開源的網(wǎng)絡(luò)模擬軟件，尤其是CMU對(duì)其加入了無線模塊的支持后，無線Ad hoc的網(wǎng)絡(luò)模擬基本上都是基于NS-2進(jìn)行的。根據(jù)文獻(xiàn)[1]， 2000—2004年間在ACM上發(fā)表的模擬類論文中有近50%是使用NS-2仿真的。NS-2每次模擬后的結(jié)果都記錄在一個(gè)trace文件中，由于NS獨(dú)特的離散事件模擬機(jī)制，它以時(shí)間作為主線組織起如上的各條記錄，如果知道trace文件中每一字段所表示的意思，那么這些記錄看起來還是比較直觀的。但當(dāng)模擬數(shù)據(jù)量較大時(shí)，這種僅是靠時(shí)間的先后次序串起來的記錄之間其他的內(nèi)在關(guān)系是難以體現(xiàn)的。在對(duì)其進(jìn)行數(shù)據(jù)分析時(shí)，光靠目測(cè)是行不通的，需要用計(jì)算機(jī)來輔助。通常對(duì)trace文件分析用的是awk腳本，但是其解釋執(zhí)行的速度過慢，如果用C/C++等高級(jí)語言讀文件分析，則每次編程的工作量較大，而且還要通過編譯才能執(zhí)行。所以用計(jì)算機(jī)對(duì)NS的運(yùn)行結(jié)果分析都比較困難，而且許多有用信息難以挖掘。

根據(jù)數(shù)據(jù)庫(kù)的理論，NS采用的這種trace文件數(shù)據(jù)記錄屬于文件分析階段。這種以時(shí)間作為惟一主線組織起來的各條記錄雖然簡(jiǎn)單，但是存在數(shù)據(jù)冗余問題，更重要的是，數(shù)據(jù)之間聯(lián)系難以體現(xiàn)，所以急需提升到數(shù)據(jù)庫(kù)分析的層次。鑒于目前關(guān)系數(shù)據(jù)庫(kù)的DBMS(數(shù)據(jù)庫(kù)管理系統(tǒng))比較多，將NS運(yùn)行出的數(shù)據(jù)導(dǎo)入到關(guān)系數(shù)據(jù)庫(kù)當(dāng)中，如此的話，分析起來僅需一些SQL查詢語句即可，更能從海量數(shù)據(jù)中方便地挖掘有用的信息。用數(shù)據(jù)庫(kù)對(duì)NS進(jìn)行分析對(duì)于廣大的研究人員來說至少具有以下幾點(diǎn)優(yōu)越性:a)可以根據(jù)數(shù)據(jù)庫(kù)關(guān)系模式切換視圖，直觀地顯示相關(guān)聯(lián)的數(shù)據(jù);b)可以利用數(shù)據(jù)庫(kù)高效的存儲(chǔ)與計(jì)算功能方便地進(jìn)行某些變量的統(tǒng)計(jì);c)可以深入細(xì)節(jié)，驗(yàn)證協(xié)議的完備性。

本文首先介紹現(xiàn)有的針對(duì)NS-2運(yùn)行數(shù)據(jù)的一些分析方法和工具，其次闡述NS的trace文件記錄體系的不足之處以及為什么要用更高級(jí)的關(guān)系數(shù)據(jù)庫(kù)模式來分析模擬實(shí)驗(yàn)運(yùn)行的結(jié)果。之后引入一個(gè)連接NS與數(shù)據(jù)庫(kù)的開放設(shè)計(jì)架構(gòu)，在此架構(gòu)之上，本文以無線Ad hoc網(wǎng)路的DSR(動(dòng)態(tài)源路由協(xié)議)為例說明數(shù)據(jù)庫(kù)的關(guān)系模式設(shè)計(jì)以及NS如何向數(shù)據(jù)庫(kù)導(dǎo)出數(shù)據(jù);最后通過一些分析實(shí)例來說明用關(guān)系數(shù)據(jù)庫(kù)分析NS運(yùn)行結(jié)果的優(yōu)點(diǎn)與方法。

1 相關(guān)研究工作

按照文獻(xiàn)[2～6]中提到的傳統(tǒng)方法，NS研究人員通常使用awk腳本對(duì)trace文件的內(nèi)容進(jìn)行分析以統(tǒng)計(jì)出相關(guān)的信息。awk是一種專門用來分析文件記錄的腳本語言，它提供了一些正則匹配、數(shù)據(jù)列提取等功能。但是這種基于awk腳本的分析有很大的缺陷，其不足主要表現(xiàn)在以下幾個(gè)方面:

a)awk語言解釋執(zhí)行的速度過慢。

b)awk語言對(duì)正則匹配的支持較好，但是對(duì)于某些排序、歸類的過程操作實(shí)現(xiàn)起來比較麻煩。

c)多種視圖表切換顯示時(shí)需要每次編寫不同的腳本。

針對(duì)這種基于awk腳本分析的主要缺陷，人們提出了幾種改進(jìn)的方法用于提高分析效率，減輕人工負(fù)擔(dān)。經(jīng)過對(duì)現(xiàn)有技術(shù)文獻(xiàn)與NS的官方資料的搜索發(fā)現(xiàn)，目前主要有以下幾種替代方法或分析工具:

a)改用C/C++讀文件分析可提高機(jī)器運(yùn)行的效率。

b)iNSpect TraceGraph工具根據(jù)trace文件形成一些常用的統(tǒng)計(jì)參數(shù)的曲線，如文獻(xiàn)[1]。

c)JTrana工具。將trace文件導(dǎo)入到MySQL后臺(tái)數(shù)據(jù)庫(kù)中，前臺(tái)做一個(gè)GUI的界面，顯示一些常用的統(tǒng)計(jì)量以及曲線，如文獻(xiàn)[7]。

d)NANS。用Java編寫的一個(gè)GUI程序，用于分析trace文件并形成一些常用的統(tǒng)計(jì)參數(shù)的曲線，如文獻(xiàn)[8]。

e)還有一些工具如NS-2/akaroa2[9]、Yavista[10]等也都提供了類似的分析功能。

雖然上述幾種方法的分析效率或者簡(jiǎn)便程度遠(yuǎn)高于awk腳本的分析，但是它們本質(zhì)上基本都是以NS運(yùn)行之后生成的trace文件作為輸入，做了一些轉(zhuǎn)換的工作，再輸出一些常用的統(tǒng)計(jì)量。從數(shù)據(jù)庫(kù)理論的角度來說，這種以模擬時(shí)間作為橫坐標(biāo)的trace文件體系本身就存在一些固有的問題:

a)數(shù)據(jù)冗余。Trace中許多數(shù)據(jù)是重復(fù)的，如一個(gè)經(jīng)過多個(gè)節(jié)點(diǎn)轉(zhuǎn)發(fā)的包，其報(bào)文是完全相同的，但每轉(zhuǎn)發(fā)一次就要被重復(fù)記錄一次。

b)每次實(shí)現(xiàn)一個(gè)新的統(tǒng)計(jì)功能必須重新寫一個(gè)腳本或重新編譯一次程序。

c)數(shù)據(jù)之間的關(guān)系在trace文件中難以體現(xiàn)。Trace文件惟一的主線就是模擬的時(shí)間，而其他數(shù)據(jù)記錄之間的關(guān)系(如一個(gè)路由查詢對(duì)應(yīng)于多個(gè)路由應(yīng)答)是無法體現(xiàn)的。

根據(jù)數(shù)據(jù)庫(kù)理論，數(shù)據(jù)庫(kù)記錄體系恰好能克服上述文件記錄體系的諸多不足，所以，本文認(rèn)為對(duì)NS的數(shù)據(jù)分析需要進(jìn)一步提升到數(shù)據(jù)庫(kù)分析或更高的層次。其實(shí)，在許多應(yīng)用領(lǐng)域(如網(wǎng)站設(shè)計(jì))，數(shù)據(jù)庫(kù)記錄的方式很早就淘汰了文件記錄，而NS作為一款為類Unix系統(tǒng)開發(fā)的仿真軟件，可能在設(shè)計(jì)之初只想到了傳統(tǒng)的文件分析模式。 本文的想法是將NS運(yùn)行出的數(shù)據(jù)導(dǎo)入到關(guān)系數(shù)據(jù)庫(kù)當(dāng)中，能夠更加簡(jiǎn)單方便地從海量數(shù)據(jù)中方便地挖掘有用的信息。

鑒于MySQL是一款應(yīng)用較廣的開源數(shù)據(jù)庫(kù)管理軟件，在普通的學(xué)術(shù)與個(gè)人使用方面是完全免費(fèi)的，所以本文使用MySQL作為NS的后臺(tái)數(shù)據(jù)管理系統(tǒng)(DBMS)。

上述替代方法b)中的JTrana軟件[7]也使用到了MySQL數(shù)據(jù)庫(kù)，但該軟件中只是將MySQL數(shù)據(jù)庫(kù)作為一個(gè)排序、歸類的工具來使用，其輸入還是trace文件，并沒有實(shí)質(zhì)性地改變NS文件記錄的模式。

2 NS與MySQL數(shù)據(jù)庫(kù)的連接

為了使NS的數(shù)據(jù)能夠不經(jīng)過trace文件而直接導(dǎo)入到MySQL數(shù)據(jù)庫(kù)中，必須在它們之間設(shè)立接口并建立一套運(yùn)行機(jī)制。對(duì)于NS的用戶來說，首先該套體系必須簡(jiǎn)單直觀，其次應(yīng)當(dāng)具有充分的靈活性與可擴(kuò)展性，即用戶自己可以自由地設(shè)計(jì)數(shù)據(jù)庫(kù)的關(guān)系模式以確定哪些表項(xiàng)是需要被具體記錄分析的。

2.1 接口體系架構(gòu)的設(shè)計(jì)

NS-2與MySQL連接的體系結(jié)構(gòu)如圖1所示。

1)NS_MySQL接口 利用NS中的TclClass機(jī)制與MySQL提供的C語言連接的API函數(shù)構(gòu)建一個(gè)NS與MySQL的接口類class TclMysql。NS每次運(yùn)行時(shí)先實(shí)例化一個(gè)TclMysql的全局變量，這樣NS中的任何一個(gè)模塊都可以利用這個(gè)實(shí)例變量作為連接接口向MySQL數(shù)據(jù)庫(kù)中導(dǎo)出數(shù)據(jù)。

2)數(shù)據(jù)庫(kù)關(guān)系模式設(shè)計(jì) 一個(gè)相對(duì)獨(dú)立的模塊，NS用戶可以根據(jù)自己的仿真實(shí)例(如路由協(xié)議)來設(shè)計(jì)數(shù)據(jù)庫(kù)的各個(gè)表項(xiàng)以及表項(xiàng)之間的約束關(guān)系，一旦關(guān)系模式確立之后，NS中的數(shù)據(jù)就必須依照該模式向數(shù)據(jù)庫(kù)中導(dǎo)出數(shù)據(jù)。

3)適合的數(shù)據(jù)導(dǎo)出點(diǎn) 指的是在NS模擬模塊中的合適地方添加數(shù)據(jù)導(dǎo)出語句，這是由用戶仿真實(shí)例的具體事務(wù)流程而確定的。

2.2 NS與MySQL的接口實(shí)現(xiàn)

思路:在C++中建立實(shí)例類TclMysql，利用NS中的TclClass機(jī)制建立一個(gè)TclMysqlClass的靜態(tài)類用于在tcl腳本與C++中的TclMysql類建立接口連接。這樣執(zhí)行tcl腳本時(shí)只需new一個(gè)TclMysql類即可在后臺(tái)建立C++與MySQL的連接。TclMysqlClass類如下:

static class TclMysqlClass: public TclClass {

//建立C++ TclMysql類與tcl中TclMysql類的連接

public:

TclMysqlClass(): TclClass(\"TclMysql\") {}

Tcl0bject create(int argc， coNSt charconstargv){

chardbname=(char)argv[4];

//pay attention to the index of the argv[]

return (new TclMysql(dbname));

}

}class_TclMysql;

TclMysql類如下:

class TclMysql: pubic TclObject{//繼承自TclObject

MYSQL mysql;//內(nèi)藏一個(gè)MYSQL類對(duì)象用于連接

TclMysql(chardbname);

//建立NS與NS_mysql數(shù)據(jù)庫(kù)的連接，字符串中為連接參數(shù)

virtual int command(int argc， coNSt charcnNStargv){

/command函數(shù)，為tcl添加方法調(diào)用，其中提供了一個(gè)closedb的方法，用于模擬后關(guān)閉與MySQL的連接，釋放內(nèi)存/

int mysql_query(charquery);

//查詢語句的接口，query為查詢的SQL語句

//由于在模擬階段只需要插入數(shù)據(jù)即可，query一般為insert語句

int mysql_query(charquery， coNSt charprint_msg);

//查詢語句的接口，query為SQL語句，print_msg為結(jié)果信息

int mysql_query(charquery， coNSt charprint_mag， char err_msg);/查詢語句的接口，query為SQL語句，Print_msg為結(jié)果信息，err_msg為出錯(cuò)信息/

};

在NS-lib.tcl中還需添加幾個(gè)tcl全局方法:

TclMysql iNStproc init args{# 構(gòu)造tcl中的TcIMysql類

eval $self next $args #簡(jiǎn)單地調(diào)用父類

}

Simulator iNStproc dbtrace-all file{#綁定dbtrace_對(duì)象

$self iNStvar dbtrace_

set dbtrace_$file

}

Simulator iNStproc get-db-traceall{}{ #返回dbtrace_對(duì)象

$self instvar dbtrace_

if [info exists dbtrace_]{

return $dbtrace_

puts \"dbtrace_:$dbtrace\\"

}else{

#puts\"no dbtrace\\"

return\"\"

}

}

2.3 運(yùn)行流程

根據(jù)本節(jié)所設(shè)計(jì)的NS_MySQL接口體系，具體的使用流程(圖2)如下:

a)使用者根據(jù)其具體的模擬場(chǎng)景或使用的協(xié)議建立數(shù)據(jù)庫(kù)的關(guān)系模型，并在MySQL中建立相應(yīng)的數(shù)據(jù)庫(kù)與數(shù)據(jù)表。

b)在使用者需要仿真的NS模塊中的相應(yīng)位置使用2.2節(jié)中提供的TclMysql接口來實(shí)現(xiàn)記錄的插入、刪除或更新操作。

c)在模擬的tcl腳本中加入一些NS_MySQL的配置信息。具體的只需添加如下語句即可:

set dbtrace [now TclMysql NS_mysql] #建立連接

$NS_dbtrace-all $dbtrace #綁定dbtrace_對(duì)象

d)運(yùn)行NS，每次運(yùn)行中的數(shù)據(jù)自動(dòng)存入MySQL數(shù)據(jù)庫(kù)中。使用者可以在運(yùn)行結(jié)束后輸入簡(jiǎn)單的SQL語句對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行視圖顯示與參數(shù)統(tǒng)計(jì)等分析工作。

3 關(guān)系數(shù)據(jù)庫(kù)ER模式設(shè)計(jì)示例

第2章引入了一種連接NS與MySQL的體系架構(gòu)，該架構(gòu)充分考慮到了易用性與可擴(kuò)展性。至此，本文已經(jīng)提供了一個(gè)底層的NS_MySQL的接口，而接口上層的部分完全可以由NS用戶根據(jù)自己的仿真需求來定制。

在trace文件中，可以任意地向其中寫入任何信息，但對(duì)于數(shù)據(jù)庫(kù)來說，必須事先設(shè)計(jì)好關(guān)系模式才能向其中寫入數(shù)據(jù)，這就是數(shù)據(jù)庫(kù)階段與文件階段最顯著的區(qū)別。本節(jié)以無線Ad hoc網(wǎng)絡(luò)的DSR(動(dòng)態(tài)源路由)協(xié)議作為示例，來說明如何在NS中具體地將數(shù)據(jù)導(dǎo)入到關(guān)系數(shù)據(jù)庫(kù)中。數(shù)據(jù)庫(kù)的設(shè)計(jì)細(xì)節(jié)請(qǐng)參考數(shù)據(jù)庫(kù)相關(guān)的文獻(xiàn)。

3.1 DSR業(yè)務(wù)流分析

以CS模型建模，對(duì)標(biāo)準(zhǔn)的DSR協(xié)議的業(yè)務(wù)流如圖3所示。

如果一個(gè)節(jié)點(diǎn)要發(fā)送一個(gè)數(shù)據(jù)包(Data)，則它先查緩存，如果沒有則向網(wǎng)絡(luò)發(fā)出路由查詢報(bào)文(RREQ)，網(wǎng)絡(luò)會(huì)回復(fù)一個(gè)路由應(yīng)答報(bào)文(RREP)，其中包含路由信息。于是該節(jié)點(diǎn)根據(jù)路由信息發(fā)出數(shù)據(jù)報(bào)文(Data)，在傳輸數(shù)據(jù)的過程中可能會(huì)出錯(cuò)，所以還會(huì)收到路由錯(cuò)誤報(bào)文(RERR)。如果下一跳節(jié)點(diǎn)不可達(dá)網(wǎng)絡(luò)節(jié)點(diǎn)自身的MAC層會(huì)回饋一個(gè)CBK消息通知。

當(dāng)然這只是一個(gè)標(biāo)準(zhǔn)的流程，并不一定每次發(fā)包都要經(jīng)歷上述幾個(gè)流程。比如，如果有路由緩存的話就不必再發(fā)送路由請(qǐng)求了，如果傳輸沒有出錯(cuò)，就沒有RERR報(bào)文了。但上述的流程可以很好地總括DSR的所有狀態(tài)，實(shí)際的每個(gè)流程都是其中的一個(gè)子集。

根據(jù)上述流程可以發(fā)現(xiàn)如下關(guān)系:

a)一個(gè)數(shù)據(jù)包的發(fā)送可能對(duì)應(yīng)一次RREQ、RERR。

b)一次RREQ可以有多個(gè)RREP對(duì)應(yīng)。

c)每個(gè)Data、RREP、RREQ、RRER報(bào)文可由多個(gè)節(jié)點(diǎn)轉(zhuǎn)發(fā)。

d)一個(gè)CBK消息由該節(jié)點(diǎn)的下層提供。

上述這些關(guān)系對(duì)于下面的ER模式的設(shè)計(jì)起著十分重要的作用。

3.2 ER圖設(shè)計(jì)

根據(jù)上述分析，ER圖設(shè)計(jì)如圖4所示。

4 實(shí)例分析

做了以上的工作后再運(yùn)行NS，其運(yùn)行結(jié)果就會(huì)自動(dòng)地記錄到MySQL數(shù)據(jù)庫(kù)中了。以下用幾個(gè)具體的示例來說明用數(shù)據(jù)庫(kù)來分析NS運(yùn)行數(shù)據(jù)的優(yōu)越性。

4.1 場(chǎng)景配置

表1為NS模擬的場(chǎng)景配置。

表1 NS模擬的場(chǎng)景配置

參數(shù)取值參數(shù)取值

節(jié)點(diǎn)個(gè)數(shù)50理想無線信號(hào)傳輸距離250 m

模擬時(shí)間100 sCBR鏈路條數(shù)500

節(jié)點(diǎn)最大運(yùn)動(dòng)速度Vmax=15 m/s數(shù)據(jù)包大小512 Byte/packet

節(jié)點(diǎn)最小運(yùn)動(dòng)速度Vmin=1 m/s信道帶寬11 Mbps

模擬場(chǎng)景尺寸1 000 m×1 000 m

4.2 查詢CBR(constant bit rate)具體流程

CBR是NS提供的一種數(shù)據(jù)流模擬，能夠產(chǎn)生等時(shí)間間隔的應(yīng)用數(shù)據(jù)流。

查詢38-30的鏈路建立過程如下:

a)首先查看RREQ的過程，查詢r(jià)ecord_dsr_rreq表從packet表中查出這個(gè)RREQ的uid=11。

selectfrom NS_mysql.record_dsr_rreq where packet=11 and (operation=‘s’ or operation=‘f’)

查詢結(jié)果如表2所示。

表2 RREQ的查詢結(jié)果

operationtimesizenext_hoppacketcurrent_nodehead_addrs_cnt

s0.106 232-111381

f0.107 748-111202

f0.107 848-11112

f0.144 2272-111239

f0.150 1272-11189

字段說明:time 表示處理動(dòng)作所進(jìn)行的時(shí)刻;operation為操作 s表示發(fā)送，f表示轉(zhuǎn)發(fā)，r表示接受;next_hop表示下一跳地址，-1表示廣播;packet指的是分組序號(hào);head_addrs_cnt表示源路由包頭中的地址數(shù);current_node表示當(dāng)前處理該報(bào)文的節(jié)點(diǎn);rreq_seq表示該RREQ的序列號(hào)。

表2中陰影部分的記錄表示38號(hào)節(jié)點(diǎn)始發(fā)RREQ。

從上可以看出，在38號(hào)節(jié)點(diǎn)查詢30號(hào)節(jié)點(diǎn)時(shí)包括源節(jié)點(diǎn)在內(nèi)有43個(gè)節(jié)點(diǎn)參與了洪泛，源路由頭的長(zhǎng)度最大達(dá)到9個(gè)，可見洪泛對(duì)網(wǎng)絡(luò)的帶寬消耗極大，而且還會(huì)產(chǎn)生超長(zhǎng)的源路由。

b)接著看一下路由回復(fù)RREP的過程，查詢r(jià)ecord_dsr_rrep表，結(jié)果如表3所示。

selectfrom record_dsr_rrep where (operation=‘s’ or operation=‘f’ or (operation=‘r’ and current_node=38))and packet in(select packet from NS_mysql.record_dsr_rrep where rrep_seq=2 and operation=‘s’ and current_node=30 and packet in(select packet_uid from NS_mysql.packet where src=30 and dst=38)

)order by packet

表3 RREP的查詢結(jié)果

operationtimenext_hophead_addrs_cntrrep_seqrrep_length

s0.128 56816525

f0.145 3775525

f0.163 34920525

f0.233 27738525

r0.238 63538525

s0.132 78131626

f0.149 00316626

s0.142 53936626

f0.185 12816626

s0.14 17115626

f0.164 90416626

s0.159 3537626

f0.193 30416626

字段說明:time 表示處理動(dòng)作所進(jìn)行的時(shí)刻;operation為操作，s表示發(fā)送，f表示轉(zhuǎn)發(fā)，r表示接收;next_hop表示下一跳地址，-1表示廣播;packet指的是分組序號(hào);head_addrs_cnt表示源路由包頭中的地址數(shù);current_node表示當(dāng)前處理該報(bào)文的節(jié)點(diǎn);rrep_seq是RREP的序列號(hào);rrep_length是RREP的長(zhǎng)度。

從目的節(jié)點(diǎn)30回復(fù)的RREP來看，它一共回復(fù)了五條路由，只有一條是成功回復(fù)給38號(hào)節(jié)點(diǎn)的。這是一條5跳長(zhǎng)路由，路徑為30→16→5→20→38，從圖5的網(wǎng)絡(luò)拓?fù)渖蟻砜催@基本上是一條最短路由。另外在送出了這個(gè)5跳的路由后還回復(fù)了四條6跳的路由，說明DSR路由協(xié)議有一定的效率缺陷，如果是為了備份考慮，也只需多回復(fù)一條即可，而不是收到的每個(gè)RREP都要回復(fù)。

c)另外，上面五條RREP中只有一條成功回復(fù)，那另外四條到底怎么了呢?看第二條RREP，在30號(hào)節(jié)點(diǎn)傳到31號(hào)節(jié)點(diǎn)后，31號(hào)轉(zhuǎn)發(fā)失敗，轉(zhuǎn)向研究record_dsr_rrer表。結(jié)果如表4所示。

selectfrom record_dsr_rrer where current_node=31 and tell_node=30

表4 RERR的查詢結(jié)果

operationtimenext_hoptell_nodecurrent_nodehead_addrs_cnt

s0.309 1983030312

s8.474 8493030312

字段說明:time 表示處理動(dòng)作所進(jìn)行的時(shí)刻;operation為操作，s表示發(fā)送，f表示轉(zhuǎn)發(fā)，r表示接受;next_hop表示下一跳地址，-1表示廣播;packet指的是分組序號(hào);head_addrs_cnt表示源路由包頭中的地址數(shù);rerr_num表示包中含有的RERR個(gè)數(shù);current_node表示當(dāng)前處理該報(bào)文的節(jié)點(diǎn);tell_node是RERR的目的節(jié)點(diǎn)。

可以看到31號(hào)節(jié)點(diǎn)轉(zhuǎn)發(fā)失敗后，它轉(zhuǎn)而發(fā)了一個(gè)RERR報(bào)文給30號(hào)節(jié)點(diǎn)，通知這條路由已經(jīng)失效。其他幾條失效路由回復(fù)亦可類似分析得出。

d)最后，38號(hào)節(jié)點(diǎn)有了去30號(hào)節(jié)點(diǎn)的路由，現(xiàn)在可以看一看最開始的那個(gè)CBR數(shù)據(jù)包是如何傳送的，查詢r(jià)ecord_agt_rtp表，結(jié)果如表5所示。

selectfrom record_agt_rtp where packet in (select packet_uid from packet where src=38 and dst=30) and (operation=‘s’ or operation=‘s’ or (operation=‘r’ and current_node=30))

表5 CBR的查詢結(jié)果

operationtimesizenext_hopnum_forwordscurrent_node

s0.042 6500-2038

s0.238 6354820038

f0.244 925485120

f0.258 125481625

f0.263 3354830316

r0.275 4254830430

r0.275 4250030430

字段說明:time 表示處理動(dòng)作所進(jìn)行的時(shí)刻;operation為操作，s表示發(fā)送，f表示轉(zhuǎn)發(fā)，r表示接受;next_hop表示下一跳地址，-1表示廣播，-2表示未知;packet指的是分組序號(hào);current_node表示當(dāng)前處理該報(bào)文的節(jié)點(diǎn);num_forwards是已經(jīng)轉(zhuǎn)發(fā)的節(jié)點(diǎn)數(shù);rh_seq是CBR的序列號(hào)。

可以看出這個(gè)包最先在38號(hào)節(jié)點(diǎn)的AGT(傳輸層)發(fā)送。由于沒有路由，先緩存在路由層RTR中，在0.238 635 s時(shí)刻獲得路由后發(fā)送該包，途中經(jīng)過30→16→5→20→38數(shù)個(gè)節(jié)點(diǎn)并于0.275 425 s傳送給30號(hào)節(jié)點(diǎn)。由此一個(gè)數(shù)據(jù)包的傳送過程結(jié)束。

可以計(jì)算出尋找路由用了 0.238 635-0.0 426=0.196 s，而之后的數(shù)據(jù)包傳送用了0.275 425-0.238 625=0.0 368 s，總共時(shí)延為0.196+0.0 368=0.233 s，尋找路由的耗時(shí)占了0.196 / 0.233= 84.1%。

4.3 協(xié)議正確性驗(yàn)證

用數(shù)據(jù)庫(kù)分析大量數(shù)據(jù)的一大優(yōu)點(diǎn)就是比較容易根據(jù)數(shù)據(jù)之間的關(guān)聯(lián)挖掘出其中隱藏的細(xì)節(jié)。對(duì)于網(wǎng)絡(luò)協(xié)議即使設(shè)計(jì)得再完善，某些細(xì)節(jié)方面的漏洞也在所難免。比如在分析DSR協(xié)議時(shí)，就通過數(shù)據(jù)庫(kù)的篩選發(fā)現(xiàn)了NS-2實(shí)現(xiàn)DSR協(xié)議中的一個(gè)bug。

重新回到4.2節(jié)中RREQ的查詢過程，其中篩選出了如下幾條記錄，如表6所示。

表6 RREQ的查詢結(jié)果

operationtimesizedelta_sizecorrect_size

s0.106 25832 32

f0.107 751481636

f0.119 037682040

f0.121 055922444

f0.126 0261202848

f0.129 0231523252

f0.131 9431883656

f0.136 1852284060

f0.140 9762724464

隨著包在網(wǎng)絡(luò)中的洪泛導(dǎo)致源路由頭的節(jié)點(diǎn)記錄數(shù)不斷增加，head_addr_cnt從1一直增加到9，包大小size也隨之增大。但是觀察size一欄，包大小似乎每經(jīng)過一跳會(huì)增加很多，而且在delta-size一欄中，算出了每?jī)商g包大小的變化大小，可以看出每次的增加值并不固定，而且增加值都很大。這與通常理解的DSR協(xié)議似乎有點(diǎn)出入，因?yàn)槊總€(gè)節(jié)點(diǎn)轉(zhuǎn)發(fā)一次RREQ只須在原報(bào)文的源路由頭中附加上自己的地址即可，每個(gè)節(jié)點(diǎn)地址占用4 Byte，所以每過一個(gè)節(jié)點(diǎn)其包頭的值應(yīng)該只是增加4 Byte。于是轉(zhuǎn)而分析DSR的源代碼，每個(gè)節(jié)點(diǎn)接受轉(zhuǎn)發(fā)RREQ報(bào)文的流程如圖6所示。

首先從recv()函數(shù)進(jìn)入，如果是RREQ報(bào)文執(zhí)行handle RouteRequest()函數(shù)，handleRouteRequest最后通過sendOutPacketWithRoute() 函數(shù)將報(bào)文轉(zhuǎn)發(fā)出去。

在handleRouteRequest(SRPacket p) 中轉(zhuǎn)發(fā)節(jié)點(diǎn)將自己的地址添加到源路由包頭中，sendOutPacketWithRoute(SRPacket p， bool fresh， Time delay) 函數(shù)中對(duì)包的大小進(jìn)行了如下處理:“cmnh→size() += srh→size();”后便轉(zhuǎn)發(fā)出去了。但是研究發(fā)現(xiàn)srh→size()是當(dāng)前DSR源路由報(bào)文頭的大小，而不是前后兩次增加值的大小，問題就出在這里，應(yīng)該在handleRouteRequest(SRPacket p) 中先減去原來源路由報(bào)文頭的大小即加入cmnh→size() -= srh→size(); 再在sendOutPacketWithRoute(SRPacket p， bool fresh， Time delay)函數(shù)中添加現(xiàn)在源路由報(bào)文頭的大小，這樣才能得出正確的包頭大小值。

說明:NS的源代碼中處理RREP與RRER的流程中都減去了原有報(bào)文的大小，而在處理RREQ的時(shí)候卻出現(xiàn)了上述紕漏。

最后更正的報(bào)文大小correct_size見correct_size列。

由此可見數(shù)據(jù)庫(kù)分析對(duì)協(xié)議實(shí)現(xiàn)細(xì)節(jié)的捕獲能力，而靠NS原有的trace文件是很難找出其中漏洞的。

4.4 計(jì)算遞交率

對(duì)分組遞交率的計(jì)算只需查詢r(jià)ecord_agt_rtp表即可。

1)計(jì)算發(fā)送的包數(shù)

select count()from NS_mysql.record_agt_rtp where trace_name=‘AGT’ and operation=‘s’;

結(jié)果910

2)計(jì)算收到的包數(shù)

結(jié)果為863;遞交率即為 863 / 910=0.948。

select count() from NS_mysql.record_agt_rtp where trace_name=‘AGT’ operation=‘s’;

5 結(jié)束語

本文是用筆者在做了大量NS仿真實(shí)驗(yàn)后感覺缺乏一套行之有效的工具去分析模擬后撰寫的，旨在將NS的數(shù)據(jù)分析由文件記錄提升至關(guān)系數(shù)據(jù)庫(kù)體系進(jìn)行分析，從而方便實(shí)驗(yàn)者對(duì)NS運(yùn)行的數(shù)據(jù)進(jìn)行高效分析。同時(shí)由于關(guān)系數(shù)據(jù)庫(kù)的關(guān)系相扣特性，這對(duì)于在NS下設(shè)計(jì)新的網(wǎng)絡(luò)協(xié)議也有檢驗(yàn)與驗(yàn)證效果。

本方法相對(duì)于NS原有的trace文件記錄以及第1章中提到的分析方法具有如下特點(diǎn):

a)引入數(shù)據(jù)庫(kù)模式代替NS原有的文件記錄分析模式。數(shù)據(jù)庫(kù)記錄較之文件記錄的科學(xué)性與先進(jìn)性在數(shù)據(jù)庫(kù)理論中已經(jīng)得以證明。

b)體系結(jié)構(gòu)開放，符合NS開源軟件的精神。本文提供了NS與MySQL數(shù)據(jù)庫(kù)的接口連接，而接口上層的數(shù)據(jù)庫(kù)關(guān)系模式設(shè)計(jì)部分與數(shù)據(jù)導(dǎo)入部分完全可以根據(jù)用戶自己的具體仿真實(shí)例來進(jìn)行設(shè)計(jì)與添加相關(guān)的插入記錄的語句，這充分利用了NS開源軟件的優(yōu)勢(shì)，從而使得使用者能夠靈活地選擇需要統(tǒng)計(jì)的記錄表項(xiàng)并在恰當(dāng)?shù)娜肟谔帉?shù)據(jù)導(dǎo)入至數(shù)據(jù)庫(kù)中。這相比于某些分析工具一整套的打包封裝并只能提供一些固定參數(shù)統(tǒng)計(jì)的做法顯然更具有靈活性與可擴(kuò)展性。

c)比較適合于NS的研究人員使用。NS的使用者一般都具有數(shù)據(jù)庫(kù)的相關(guān)背景。最終的分析只需一些簡(jiǎn)單的SQL查詢語句即可實(shí)現(xiàn)視圖顯示與參數(shù)統(tǒng)計(jì)等的分析工作。由于數(shù)據(jù)庫(kù)的關(guān)系模式是開發(fā)人員自行設(shè)計(jì)的，對(duì)于具體的查詢流程與邏輯會(huì)十分熟悉，而且目前還有mysql-gui-tools與OpenOffice等圖形化的工具可以輔助編寫SQL語句，這將使得分析工作對(duì)于NS的研究人員來說十分便捷高效。

參考文獻(xiàn):

[1]KURKOWSKI S， CAMP T， MUSHELL N， et al. A visualization and analysis tool for NS-2 wireless simulations:iNSpect[C]//Proc of the 13th IEEE International Symposium or Modeling， Analysis， and Simu-lation of Computer and Telecommunication Systems. Washington DC: IEEE Computer Society， 2005:503-506.