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