【文章內(nèi)容簡(jiǎn)介】 果出錯(cuò)，則創(chuàng)建一個(gè)Response包并將相關(guān)出錯(cuò)消息、發(fā)回給請(qǐng)求者。PDU類型請(qǐng)求標(biāo)識(shí)}錯(cuò)誤狀態(tài)0}錯(cuò)誤索引0}變量綁定值 變量綁定字段中規(guī)定所需的對(duì)象標(biāo)識(shí)符。 Response協(xié)議數(shù)據(jù)單元 Response命令是代理能夠?qū)?lái)自管理系統(tǒng)的所有Get Next, Set Request, GetBulk或Get Request查詢進(jìn)行響應(yīng)。如果代理能夠用指定的值正確操作，則錯(cuò)誤狀態(tài)和錯(cuò)誤索引的值為0。否則錯(cuò)誤狀態(tài)和錯(cuò)誤索引的值被設(shè)為原先預(yù)定的值。PDU類型請(qǐng)求標(biāo)識(shí)}錯(cuò)誤狀態(tài){錯(cuò)誤索引}變量綁定值為錯(cuò)誤狀態(tài)字段規(guī)定的值在下表中列出:┌────────────┬─┬────────────────┬─┐│名稱 │值│名稱 │值│├────────────┼─┼────────────────┼─┤│tooBig(太大) │1 │wrongValue(錯(cuò)誤值) │10││noSuchName(無(wú)此名) │2 │noCreation(不可創(chuàng)建) │11││badValue(壞值) │3 │inconsistentValuP(不一致值) │12││readOnly(只讀) │4 │resourceUnavailable(資源不可用) │13││genErr(一般錯(cuò)) │5 │mitFailed(提交失敗) │14││noAccess(不可訪問(wèn)) │6 │undoFailed(撤銷失敗) │15││wrongType(錯(cuò)誤類型) │7 │authorizationError(授權(quán)失敗) │16││wrongLength(錯(cuò)誤長(zhǎng)度) │8 │notWritable(不可寫(xiě)) │17││wrongl:ncoding(錯(cuò)誤編碼)│9 │inconsistentName(不一致名) │18│└────────────┴─┴────────────────┴─┘如果Response協(xié)議數(shù)據(jù)單元中的錯(cuò)誤狀態(tài)字段為非0值，則說(shuō)明在剛進(jìn)行的請(qǐng)求中檢測(cè)到有錯(cuò)誤發(fā)生。錯(cuò)誤索引字段中含有的附加信J自、有助于標(biāo)示錯(cuò)誤的原因。錯(cuò)誤索引字段值的定義如下:┌─────────────┬─┐│名字 │值│├─────────────┼─┤│ NoSuchObject(無(wú)此對(duì)象) │0 ││NoSuchInstance(無(wú)此實(shí)例) │1 ││EndOfMibView tMib View尾) │2 │└─────────────┴─┘ Trap協(xié)議數(shù)據(jù)單元 SNMPv2中，如果代理探測(cè)到特殊情況，它就向管理站發(fā)出陷阱類型(traptype的報(bào)文。PD川}}卜一—一叫類型}請(qǐng)求標(biāo)識(shí)i錯(cuò)誤狀態(tài)0}錯(cuò)誤索引O}sysUpTime 了}}}} 變量綁定值SnmpTrapOID}對(duì)象標(biāo)識(shí)符變量綁定字段結(jié)構(gòu)如下: .SysUpTime定義了自上次設(shè)備重新引導(dǎo)以來(lái)所經(jīng)過(guò)的時(shí)間。 .SnmpTrapOID表示相應(yīng)陷阱的固定名。 .對(duì)象標(biāo)識(shí)符表示一個(gè)或多個(gè)對(duì)象。在RFC1450中，SNMPv2預(yù)先定義了若干陷阱: 1. Traps Group陷阱組，那種可以進(jìn)行配置以便發(fā)送SNMPv2 Trap PDL的代 理預(yù)先規(guī)定的所有對(duì)象均包含在這個(gè)陷阱組中。 2. Well Known Traps(周知陷阱)，包括: 11 a) coldStart一冷啟動(dòng)陷阱指示某SNMPv2代理已經(jīng)因配置變化而重新初 始化。 b) warmStart一熱啟動(dòng)陷阱指示某SNMPv2代理己重新初始化，但沒(méi)有改 變配置。 c) LinkDown一鏈路斷陷阱指示SNMPv2代理已檢測(cè)到某條鏈路出了差錯(cuò)。 d) LinkupLinkup陷阱指示配置的某SNMPv2代理的鏈路己被激活。 e) authenticationFailure一該陷阱指示SNMPv2代理已檢測(cè)到在其收到 的數(shù)據(jù)包中有驗(yàn)證錯(cuò)。 f) egpNeighborLoss一該陷阱指示SN39。MPv2代理已將通信進(jìn)程讓于某EGP 鄰居。 Inform Request協(xié)議數(shù)據(jù)單元 與SNMPvl不同，SN1vtPv2掘棄了代理和網(wǎng)絡(luò)管理者的嚴(yán)格劃分，引入了管理者一管理者通信，從而使網(wǎng)絡(luò)管理者既可以作為客戶進(jìn)程也可以作為服務(wù)器進(jìn)程運(yùn)行。利用管理者一管理者通信，通過(guò)為對(duì)象變量的值規(guī)定上限和下限可以在管理者/代理上設(shè)置告警(alarm)。如果閉值被突破，則高層管理站會(huì)通過(guò)Inform Request得知這一事件。Inform Request總是被接收者以Response Request加以確認(rèn)。工。formRequest協(xié)議數(shù)據(jù)單元與Trap協(xié)議數(shù)據(jù)單元相對(duì)應(yīng)。請(qǐng)求標(biāo)識(shí){錯(cuò)誤狀態(tài)of錯(cuò)誤索引0} sysupTime變量綁定值st}mpTrapOID…對(duì)象標(biāo)識(shí)符第3章系統(tǒng)總體設(shè)計(jì) 在對(duì)SNMPv2進(jìn)行細(xì)致分析的基礎(chǔ)上，我設(shè)計(jì)了面向應(yīng)用軟件的網(wǎng)絡(luò)監(jiān)控系統(tǒng)。管理信息庫(kù)的組織方式采取類似于SNMP的管理信息組織方式一MIB樹(shù)的方式來(lái)組織被管對(duì)象。協(xié)議數(shù)據(jù)單元方面，我決定在保持SNMP基本操作的基礎(chǔ)上，對(duì)S\v1P協(xié)議數(shù)據(jù)單元進(jìn)行一些修改。力求在管理站點(diǎn)上提供給網(wǎng)絡(luò)管理員一個(gè)整個(gè)管理區(qū)域內(nèi)的MIB樹(shù)的直觀映射，以方便網(wǎng)絡(luò)管理員對(duì)被管對(duì)象的監(jiān)控。整個(gè)系統(tǒng)設(shè)計(jì)分為3個(gè)層次: 。 。 。 本文僅對(duì)第一個(gè)層次所涉及的問(wèn)題進(jìn)行討論。系統(tǒng)共有三個(gè)組成部分:監(jiān)控模塊、管理代理、管理站點(diǎn)。管理站點(diǎn) 監(jiān)控模塊是提供給軟件開(kāi)發(fā)人員使用的一個(gè)通用模塊。在其內(nèi)部封裝了與管理代理進(jìn)行通信和對(duì)本地MIB子樹(shù)進(jìn)行管理的的內(nèi)部實(shí)現(xiàn)，這些內(nèi)部實(shí)現(xiàn)對(duì)于軟件開(kāi)發(fā)人員是完全透明的。同時(shí)該模塊向軟件開(kāi)發(fā)人員提供了一系列接口來(lái)操作該模塊。如Create)用于對(duì)模塊的初始化，AddMibNode()用于添加MIB節(jié)點(diǎn)，De1MibNode ()用于刪除MIB節(jié)點(diǎn)等等。該模塊實(shí)際上就是提供給軟件開(kāi)發(fā)人員的一個(gè)外部類，使開(kāi)發(fā)人員能夠在正常開(kāi)發(fā)應(yīng)用軟件的同時(shí)，花費(fèi)比較少的時(shí)間和精力就可以開(kāi)發(fā)出可以被監(jiān)控的軟件。 管理代理位于每一個(gè)受控站點(diǎn)中，負(fù)責(zé)與本機(jī)的各應(yīng)用程序?qū)嵗ㄐ牛占鲬?yīng)用程序?qū)嵗谋O(jiān)控信息，同時(shí)與管理站點(diǎn)聯(lián)絡(luò)，發(fā)送本地的節(jié)點(diǎn)信息，并接受管理站點(diǎn)傳來(lái)的控制信息。管理代理在計(jì)算機(jī)中并不是顯式運(yùn)行的。它是在第一個(gè)被監(jiān)控的應(yīng)用程序?qū)嵗_(kāi)始運(yùn)行時(shí)，由該應(yīng)用程序?qū)嵗{(diào)用的一個(gè)子進(jìn)程，并且在主進(jìn)程結(jié)束后繼續(xù)運(yùn)行，直到關(guān)機(jī)。 管理站點(diǎn)在其內(nèi)部主要負(fù)責(zé)與服務(wù)范圍內(nèi)的所有管理代理進(jìn)行通信，搜集監(jiān)控信息，并下發(fā)各種控制指令。在外部，它具有監(jiān)控系統(tǒng)的主要用戶界面，提供了整個(gè)服務(wù)范圍內(nèi)的MIB樹(shù)的映射，網(wǎng)絡(luò)管理員可以在該映射上得到他所感興趣的信息。 MIB信息的擴(kuò)展 在SI}39。MP中，其MIB樹(shù)定義在管理樹(shù)的因特網(wǎng)分支((. 1)下的管理分支(標(biāo)號(hào)“mgmt (2))下。該分支下的節(jié)點(diǎn)都是一些標(biāo)準(zhǔn)節(jié)點(diǎn)，存儲(chǔ)了一些己經(jīng)形成公認(rèn)標(biāo)準(zhǔn)的信息。我們的應(yīng)用軟件監(jiān)控系統(tǒng)的MIB子樹(shù)可以在管理樹(shù)的因特網(wǎng)分支()下私有分支(標(biāo)號(hào)“private (4))的企業(yè)分支(標(biāo)號(hào)“enterprisesC1)。)下申請(qǐng)一個(gè)節(jié)點(diǎn)MCS。在MCS節(jié)點(diǎn)下構(gòu)造我們自己的MIB樹(shù)。Internet (1)directory (1) mgmt(2) experimental (3) private (4) security (5) (6)enterprises (1)MCS(500)IP1(1) IP2 (2)，二IPn (n)Applicationl(1) Application2(2) Application (3) /入\、classl class2/伙\、variablel variable2 IP1...IPn是受控站點(diǎn)的IP地址，Applicationl...ApplicationN是在受控站點(diǎn)中運(yùn)行的應(yīng)用程序?qū)嵗?，classN是應(yīng)用程序?qū)嵗齼?nèi)部的類名，variablel}}是應(yīng)用程序?qū)嵗齼?nèi)的類中的成員變量名。 M工B樹(shù)中，同一層的MIB節(jié)點(diǎn)不允許同名。受控站點(diǎn)的工P唯一，應(yīng)用程序?qū)嵗齼?nèi)部的類名唯一，類中的成員變量名唯一，而一個(gè)受控站點(diǎn)中的應(yīng)用程)宇一可以同時(shí)存在多個(gè)實(shí)例，它們具有相同的實(shí)例名。如何使相同的實(shí)例具有不同的實(shí)例名，是我們需要解決的一個(gè)問(wèn)題。其解決方法在技術(shù)問(wèn)題解決章節(jié)內(nèi)有所講解。 MIB樹(shù)是一個(gè)多叉樹(shù)，在內(nèi)存中將其表示成一棵二叉樹(shù)，樹(shù)中每一個(gè)節(jié)點(diǎn)都是一個(gè)MIB節(jié)點(diǎn)。其中多叉樹(shù)到二叉樹(shù)的轉(zhuǎn)換關(guān)系是:二叉樹(shù)中的每一個(gè)節(jié)點(diǎn)的左孩子是多叉樹(shù)中相應(yīng)節(jié)點(diǎn)的第一個(gè)孩子節(jié)點(diǎn)，該節(jié)點(diǎn)的右孩子是多叉樹(shù)中相應(yīng)節(jié)點(diǎn)的相鄰兄弟節(jié)點(diǎn)。當(dāng)需要傳輸該MIB樹(shù)時(shí)，則將該二叉樹(shù)進(jìn)行中序遍歷，加入空節(jié)點(diǎn)信息，將遍歷后得到的數(shù)據(jù)串傳輸出去。當(dāng)數(shù)據(jù)串到達(dá)另一端后，再將該串恢復(fù)成二叉樹(shù)。在管理站點(diǎn)上，由于存在一個(gè)MIB樹(shù)的映射，因此需要將二叉樹(shù)轉(zhuǎn)換成多叉樹(shù)的形式顯示出來(lái)。M工B節(jié)點(diǎn)的數(shù)據(jù)組織形式:struct MIBNode{ CString Name。 CString Describe。 VariableType Type。 CString Value: void* Address。 RestrictTrain *Train: int ItemNum。 B001, Writable。 MIBPJode*LChi 1d。 MIBNode*RChild://MIB節(jié)點(diǎn)的名字刀M工B節(jié)點(diǎn)的描述刀M工B節(jié)點(diǎn)的類型刀MIB節(jié)點(diǎn)的值//M工B節(jié)點(diǎn)的地址刀M工B節(jié)點(diǎn)的閡值鏈表//MIB節(jié)點(diǎn)的數(shù)據(jù)項(xiàng)項(xiàng)數(shù)刀M工B節(jié)點(diǎn)是否可寫(xiě)//MIB節(jié)點(diǎn)的左孩子//M工B節(jié)點(diǎn)的右孩子對(duì)于該結(jié)構(gòu)有以下幾點(diǎn)說(shuō)明:.MIB節(jié)點(diǎn)的類型有Ih}TEGER(整型)，DFLOAT(浮點(diǎn)型)，STRING(字符串型)， N0}39。E(空類型)等。.存儲(chǔ)MIB節(jié)點(diǎn)的值是為了對(duì)MIB節(jié)點(diǎn)進(jìn)行新舊值的對(duì)比，從而確定哪些M工E 節(jié)點(diǎn)屬于更新數(shù)據(jù)的MIB節(jié)點(diǎn)。.M工B節(jié)點(diǎn)的閉值鏈表是為了紀(jì)錄在該MIB節(jié)點(diǎn)上設(shè)置的閨值。因?yàn)橐粋€(gè)管 理代理可能對(duì)多個(gè)管理站點(diǎn)負(fù)責(zé)，多個(gè)管理站點(diǎn)都可能對(duì)同一個(gè)MIB節(jié)點(diǎn) 設(shè)置閉值，所以要用鏈表形式紀(jì)錄這些閨值的設(shè)置。.MIB節(jié)點(diǎn)的數(shù)據(jù)項(xiàng)項(xiàng)數(shù)如果大于1，則該M工B節(jié)點(diǎn)為一個(gè)數(shù)組變量，其基本 類型在Type中指定。.M工B節(jié)點(diǎn)的左右孩子節(jié)點(diǎn)是與M工B子樹(shù)在內(nèi)存中的二叉樹(shù)儲(chǔ)存形式相適應(yīng) 的。 由于系統(tǒng)要提供給監(jiān)控站點(diǎn)一個(gè)整個(gè)管理范圍內(nèi)的MIB樹(shù)的直觀映射，因此需要對(duì)SNMP中的協(xié)議數(shù)據(jù)單元加以擴(kuò)充。同時(shí)，由于管理站點(diǎn)有了這一M工B樹(shù)的映射，管理站點(diǎn)對(duì)于每一個(gè)被管對(duì)象都有其詳細(xì)的信息，不再存在SNMP中管理站點(diǎn)對(duì)于代理上的被管對(duì)象不了解的現(xiàn)象，而SNMP中Get Vext Request操作帶來(lái)的遍歷各個(gè)表或快速查詢連續(xù)數(shù)據(jù)對(duì)象比較方便的優(yōu)點(diǎn)可以由擴(kuò)充了的Get Data Request(合并了 Bulk操作)來(lái)提供。所以SNMP協(xié)議數(shù)據(jù)單元中的Get Next Request在我們的監(jiān)控系統(tǒng)中并不存在。 網(wǎng)絡(luò)應(yīng)用軟件監(jiān)控系統(tǒng)提供了如下幾種協(xié)議數(shù)據(jù)單元:Register Request, Get 16Data Request、Set Data Request、Set Setting Request、Response、Trap和Informo 監(jiān)控系統(tǒng)中的傳輸協(xié)議建立在TCP/IP協(xié)議的基礎(chǔ)上。UDP和TCP作為IP協(xié)議層上的兩種協(xié)議，分別提供了非連接的和面向連接的兩種不同的服務(wù)。在TCP協(xié)議傳輸模式下，傳輸?shù)膬啥酥g首先要建立一條連接。然后，數(shù)據(jù)就在這條已經(jīng)建好的連接上傳輸。而在UDP協(xié)議的傳輸模式下，并不存在上述的連接。監(jiān)控軟件基于客戶/服務(wù)器(C/S 模式。客戶端向服務(wù)端發(fā)送數(shù)據(jù)請(qǐng)求，服務(wù)端向客戶提供數(shù)據(jù)，一問(wèn)一答。網(wǎng)絡(luò)傳輸是由客戶端發(fā)起的，主動(dòng)權(quán)在客戶端，如果客戶端沒(méi)有收到服務(wù)端回答的數(shù)據(jù)，客戶可以再次向服務(wù)器發(fā)送數(shù)據(jù)請(qǐng)求，除非確認(rèn)網(wǎng)絡(luò)傳輸失敗。對(duì)于服務(wù)端來(lái)說(shuō)，它是不需要考慮數(shù)據(jù)是否傳到了客戶端?？梢?jiàn)，基于客戶/服務(wù)器模式的監(jiān)控軟件的網(wǎng)絡(luò)傳輸適合使用UDP協(xié)議傳輸。同時(shí)，使用TCP協(xié)議進(jìn)行傳輸時(shí)，建立連接一般需要3次“握手”，而監(jiān)控軟件的一次數(shù)據(jù)傳輸一般只有兩個(gè)數(shù)據(jù)包，可見(jiàn)無(wú)效傳輸過(guò)多:使用UDP協(xié)議傳輸時(shí)，可以避免多余的建立連接的數(shù)據(jù)包。因此，采用UDP協(xié)議作為監(jiān)控系統(tǒng)傳輸協(xié)議的下一層協(xié)議比較合適。但由于UDP協(xié)議并不象TCP協(xié)議那樣保