王曉東,楊學(xué)海

(中國西南電子技術(shù)研究所, 成都610036)

1 引 言

現(xiàn)有的航天地面測控系統(tǒng)中,監(jiān)控系統(tǒng)通過采用C/S架構(gòu)的方式基本實(shí)現(xiàn)了遠(yuǎn)程中心對各套地面站設(shè)備的遠(yuǎn)程監(jiān)控管理。遠(yuǎn)程客戶端通過本地服務(wù)端對地面站設(shè)備運(yùn)行狀態(tài)與參數(shù)進(jìn)行監(jiān)視與控制,本地服務(wù)端將采集到的設(shè)備狀態(tài)參數(shù)信息傳送到遠(yuǎn)程客戶端進(jìn)行相應(yīng)顯示,遠(yuǎn)程客戶端則向用戶提供良好的人機(jī)操作界面,并且發(fā)送各種操控命令到本地服務(wù)端,通過本地服務(wù)端對本地設(shè)備或數(shù)據(jù)庫進(jìn)行相應(yīng)的操控。但是,由于遠(yuǎn)程客戶端和本地服務(wù)端之間的信息傳輸沒有一套標(biāo)準(zhǔn)、統(tǒng)一的應(yīng)用層協(xié)議,致使遠(yuǎn)程中心的監(jiān)控效率受到一定的影響,給用戶的使用帶來不便。

本文提出選擇簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)作為遠(yuǎn)程客戶端與本地服務(wù)端之間進(jìn)行網(wǎng)絡(luò)通信的應(yīng)用層協(xié)議,并以此為基礎(chǔ)構(gòu)建C/S(Client/Server)模式下的遠(yuǎn)程監(jiān)控管理系統(tǒng)。通過原型系統(tǒng)的設(shè)計(jì)及實(shí)現(xiàn),以及仿真試驗(yàn)的驗(yàn)證,從而研究并探討了SNMP在遠(yuǎn)程監(jiān)控中的應(yīng)用。

2 SNMP簡介

簡單網(wǎng)絡(luò)管理協(xié)議(Simple Network Management Protocol, SNMP)是一系列協(xié)議組和規(guī)范的集合, 20世紀(jì)80年代末期由IETF開發(fā)后,開始被廣泛應(yīng)用在各類網(wǎng)絡(luò)設(shè)備中,成為一種網(wǎng)管的工業(yè)標(biāo)準(zhǔn),它被設(shè)計(jì)成為一種應(yīng)用層協(xié)議,規(guī)定了網(wǎng)絡(luò)信息傳輸?shù)姆椒?、格式?具有簡單、靈活、擴(kuò)展性好等優(yōu)點(diǎn),適合于管理員對不同種類的設(shè)備、不同廠家生產(chǎn)的設(shè)備、不同型號的設(shè)備、不同物理空間的設(shè)備進(jìn)行統(tǒng)一的管理,是一種從網(wǎng)絡(luò)設(shè)備中收集網(wǎng)絡(luò)管理信息的有效簡便的方法。

SNMP采用管理者(manager)/代理(agent)模型。管理者(一般是運(yùn)行網(wǎng)絡(luò)管理系統(tǒng)的計(jì)算機(jī))通過向代理(一般是包含SNMP管理信息的設(shè)備)發(fā)送相應(yīng)的命令獲得代理中指定的信息,代理負(fù)責(zé)響應(yīng)管理者發(fā)出的各種信息,或者以主動(dòng)上報(bào)的方式向管理者提供必要的信息,從而實(shí)現(xiàn)管理者與代理之間的信息通信。

SNMP通常由管理信息結(jié)構(gòu)(SMI)、管理信息庫(MIB)和管理協(xié)議(SNMP)[1]等幾個(gè)部分組成。

SMI是一套描述 SNMP如何訪問信息的標(biāo)準(zhǔn)[2],定義了SNMP框架所用信息的組織和標(biāo)識(shí),其中,被管理對象的定義要用抽象語句定義ASN.1來描述。SMI約束了抽象語句定義ASN.1的范圍,用于描述SNMP協(xié)議數(shù)據(jù)報(bào)和管理信息庫(MIB)。

MIB用來貯存管理信息,定義了可以通過網(wǎng)絡(luò)管理協(xié)議進(jìn)行訪問的管理對象的集合,也即代理進(jìn)程中所有可被查詢和修改的參數(shù)。MIB是一個(gè)樹形結(jié)構(gòu)的數(shù)據(jù)庫, MIB中的每個(gè)被管理資源都由一個(gè)對象來表示,每一個(gè)對象信息都是管理信息樹下的一個(gè)節(jié)點(diǎn),擁有唯一的對象標(biāo)識(shí)。管理者與代理之間都使用同一個(gè)MIB作為接口結(jié)構(gòu),可實(shí)現(xiàn)相互信息的理解與管理。

SNMP協(xié)議是管理者和代理之間的異步請求和響應(yīng)協(xié)議,定義了管理者如何對代理進(jìn)程的MIB對象進(jìn)行讀寫操作,定義了所使用的傳輸層協(xié)議、支持的操作、操作相關(guān)的PDU結(jié)構(gòu)等。網(wǎng)絡(luò)管理信息的數(shù)據(jù)由SNMP從MIB庫中獲取,再經(jīng)過網(wǎng)絡(luò)管理系統(tǒng)應(yīng)用程序進(jìn)行過濾、分析、加工等處理。 SNMP通常使用無連接的UDP進(jìn)行通信,使用命令的方式來訪問MIB數(shù)據(jù)庫,每個(gè)SNMP命令稱為協(xié)議數(shù)據(jù)單元(PDU)。典型的PDU包括GetRequest、GetNextRequest、SetRequest、Trap、Response等幾種類型。

3 SNMP在遠(yuǎn)程監(jiān)控管理中的應(yīng)用

3.1 遠(yuǎn)程監(jiān)控系統(tǒng)模型

目前,航天地面測控系統(tǒng)中,通過采用C/S模式構(gòu)建的遠(yuǎn)程監(jiān)控管理系統(tǒng),部署在遠(yuǎn)程中心的遠(yuǎn)程客戶端已可基本實(shí)現(xiàn)對各個(gè)地面測控站設(shè)備進(jìn)行遠(yuǎn)程操控。地面站的本地服務(wù)端采集本地設(shè)備所有的參數(shù)、狀態(tài)信息,并將信息上報(bào)至遠(yuǎn)程客戶端;遠(yuǎn)程客戶端向用戶提供人機(jī)操作界面,同時(shí)將遠(yuǎn)程控制命令發(fā)送到本地服務(wù)端,再由本地服務(wù)端對設(shè)備進(jìn)行統(tǒng)一的分發(fā)控制?；赟NMP構(gòu)建C/S模式的遠(yuǎn)程監(jiān)控管理系統(tǒng),并未改變既有遠(yuǎn)程監(jiān)控的框架,只是采用了SNMP作為遠(yuǎn)程客戶端與服務(wù)端之間的網(wǎng)絡(luò)信息交互的基礎(chǔ)。遠(yuǎn)程監(jiān)控管理系統(tǒng)模型如圖1所示。

圖1 遠(yuǎn)程監(jiān)控管理系統(tǒng)模型Fig.1 Remotemonitoring and controlmanagementsystem model

監(jiān)控服務(wù)端可被看作是SNMP中的代理角色,遠(yuǎn)程客戶端可被看作是SNMP中的管理者角色,這時(shí)的遠(yuǎn)程中心客戶端軟件同地面站的本地服務(wù)端軟件之間的網(wǎng)絡(luò)信息交互即是采用SNMP的方式來實(shí)現(xiàn)。

3.2 監(jiān)控M IB庫設(shè)計(jì)

在采用SNMP進(jìn)行C/S模式遠(yuǎn)程監(jiān)控管理系統(tǒng)的構(gòu)建中,重要的一個(gè)工作是遠(yuǎn)程監(jiān)控MIB庫的設(shè)計(jì),以使得在管理者與代理之間使用同一個(gè)MIB作為網(wǎng)絡(luò)信息傳輸?shù)幕A(chǔ)。圖2是遠(yuǎn)程監(jiān)控MIB庫的對象標(biāo)識(shí)命名樹結(jié)構(gòu)示意圖,可按路徑尋找到設(shè)備DC的對象標(biāo)識(shí)(OID)為1.3.6.1.4.1.100000.1,或者也可表示為iso.org.dod.internet.private.enterprises.station.dc。

圖2 對象標(biāo)識(shí)命名樹示例Fig.2 Named tree of objects identificationmodel

SNMP版本2中提供了多種命令類型的PDU操作,在遠(yuǎn)程監(jiān)控軟件中實(shí)際用到最多的是Trap操作與SetRequest操作兩種。在應(yīng)用程序運(yùn)行時(shí),所有的Trap操作都在程序的某一個(gè)入口處接收數(shù)據(jù),所有的SetRequest操作又在程序的另一個(gè)入口處接收數(shù)據(jù)。而在同一個(gè) PDU操作命令中(例如 SetRequest操作)劃分出具體是遠(yuǎn)程監(jiān)控命令或數(shù)據(jù)的哪一種,則需要應(yīng)用程序本身提供一種處理機(jī)制來進(jìn)行解析。一種方式是,可以將收到的數(shù)據(jù)進(jìn)行全MIB庫元素的遍歷,直至找到對應(yīng)的元素,其缺點(diǎn)為進(jìn)行遍歷操作將要消耗大量的資源,尤其在秒定時(shí)及大數(shù)據(jù)量傳輸時(shí)表現(xiàn)更為明顯。為了解決此問題,在進(jìn)行遠(yuǎn)程監(jiān)控MIB庫設(shè)計(jì)時(shí),將同一條命令或返回響應(yīng)的數(shù)據(jù)集合在一個(gè)對象節(jié)點(diǎn)下,在節(jié)點(diǎn)內(nèi)的第1個(gè)元素設(shè)計(jì)為本節(jié)點(diǎn)的名稱,通過查找第1個(gè)元素標(biāo)識(shí)即可識(shí)別這一節(jié)點(diǎn)內(nèi)的數(shù)據(jù)具體是哪一個(gè)設(shè)備的什么類型的數(shù)據(jù)或者是哪一類型的命令操作等。程序數(shù)據(jù)接收入口處收到響應(yīng)或命令時(shí),首先將收到的第1個(gè)元素解出,得到此識(shí)別標(biāo)識(shí)后,再根據(jù)標(biāo)識(shí)調(diào)用對應(yīng)的處理方法即可對其后的MIB元素?cái)?shù)據(jù)進(jìn)行處理,不再需要對MIB庫對象進(jìn)行全部遍歷操作。

在進(jìn)行遠(yuǎn)程監(jiān)控的MIB庫設(shè)計(jì)時(shí),以DC設(shè)備為例,總共需要進(jìn)行控制的元素為兩項(xiàng),包括dcDNLFreq、dcNCAttenLevel;需要設(shè)備上報(bào)的參數(shù)與狀態(tài)元素為8項(xiàng),包括控制參數(shù)兩項(xiàng)以及狀態(tài)參數(shù)(dc-MonMode、 dcLO1Status、 dcLO2Status、 dcPower1Ind、dcPower2Ind、dcPower3Ind)6 項(xiàng)。所有參數(shù)定義為Integer32型, DC的MIB庫設(shè)計(jì)如圖3所示。

圖3 MIB庫中設(shè)備DC的定義Fig.3 The difinition fo DC in MIB

設(shè)備DC的節(jié)點(diǎn)名稱定義為“dc”,節(jié)點(diǎn)下定義的第1個(gè)元素dcNameID為此設(shè)備的String類型的元素,在發(fā)送控制命令或上報(bào)參數(shù)狀態(tài)時(shí),填入一個(gè)相應(yīng)的識(shí)別字符串,例如,對于設(shè)備DC狀態(tài)與參數(shù)的返回填入“DCStatus”,避免應(yīng)用程序在對接收數(shù)據(jù)進(jìn)行處理時(shí)對全MIB庫進(jìn)行遍歷操作。在接收到服務(wù)端Trap上報(bào)的數(shù)據(jù)時(shí),解出第1個(gè)元素對象,如設(shè)備DC上報(bào)“DCStatus”時(shí),即可知道Trap的數(shù)據(jù)為設(shè)備DC的參數(shù)狀態(tài),直接調(diào)用相應(yīng)的處理過程即可,節(jié)省全MIB遍歷所需的處理時(shí)間和資源。

MIB中對所有設(shè)備監(jiān)控、業(yè)務(wù)管理和數(shù)據(jù)庫操作的設(shè)計(jì)均采用同樣的方式。

3.3監(jiān)控軟件設(shè)計(jì)及實(shí)現(xiàn)

遠(yuǎn)程監(jiān)控管理系統(tǒng)設(shè)計(jì)主要體現(xiàn)在監(jiān)控軟件的設(shè)計(jì)上,監(jiān)控軟件分為兩部分:一部分為監(jiān)控服務(wù)端軟件,它實(shí)現(xiàn)對所有需要管理的設(shè)備進(jìn)行參數(shù)的采集,將采集到的參數(shù)實(shí)時(shí)上報(bào)到遠(yuǎn)程監(jiān)控客戶端軟件,或者接收遠(yuǎn)程客戶端軟件發(fā)出的控制命令,對設(shè)備進(jìn)行控制操作以及對數(shù)據(jù)庫數(shù)據(jù)的操作;另一部分為遠(yuǎn)程監(jiān)控客戶端軟件,提供一個(gè)良好的人機(jī)圖形界面供用戶操作控制設(shè)備。

SNMPv2提供了GetRequest、GetNextRequest、SetRequest、Trap、Response、InformRequest、GetBulkRequest等7種命令類型的PDU操作,結(jié)合遠(yuǎn)程監(jiān)控軟件的功能特點(diǎn)以及所傳送數(shù)據(jù)的特點(diǎn),將使用到GetRequest、SetRequest和Trap等3種操作方式,其中,又主要會(huì)大量的使用到SetRequest和Trap這兩種操作方式。監(jiān)控服務(wù)端采用Trap操作方式定時(shí)(如每秒)將采集的數(shù)據(jù)上報(bào)至客戶端進(jìn)行顯示;監(jiān)控客戶端對監(jiān)控服務(wù)端采用SetRequest操作方式進(jìn)行監(jiān)控命令的下達(dá),對部分需要獲得少量返回參數(shù)的監(jiān)控命令使用GetRequest操作方式進(jìn)行下達(dá)。監(jiān)控信息流程如圖4所示。

圖4 監(jiān)控信息流程圖Fig.4 The flow chart of information onmonitoring＆control

根據(jù)實(shí)際遠(yuǎn)程監(jiān)控管理的功能需求,主要包括設(shè)備參數(shù)與狀態(tài)的監(jiān)視、設(shè)備參數(shù)控制、數(shù)據(jù)庫操作、用戶信息管理、圖像傳輸?shù)葞讉€(gè)部分。對監(jiān)控軟件實(shí)現(xiàn)上述功能的操作將根據(jù)各自的功能特點(diǎn)采用不同方式進(jìn)行實(shí)現(xiàn)。

在本原型系統(tǒng)的實(shí)現(xiàn)過程中, SNMP的開發(fā)平臺(tái)采用AdventNet API,編程語言采用C#。

3.3.1 設(shè)備參數(shù)與狀態(tài)監(jiān)視

監(jiān)控服務(wù)端創(chuàng)建單獨(dú)的一個(gè)線程,以每秒主動(dòng)發(fā)送Trap的方式將設(shè)備參數(shù)與狀態(tài)上報(bào)至監(jiān)控客戶端。在Trap的PDU中將所有的參數(shù)、狀態(tài)進(jìn)行一次性綁定并發(fā)送。服務(wù)端與客戶端使用相同的MIB庫文件,在接收的時(shí)候只需將收到的Trap包中數(shù)據(jù)的OID對應(yīng)至MIB庫文件中的相應(yīng)部分,即可解析出所需元素的數(shù)值,填入已經(jīng)定義好的數(shù)據(jù)結(jié)構(gòu)中以便監(jiān)控客戶端使用。發(fā)送設(shè)備參數(shù)與狀態(tài)線程部分程序示例如下:

3.3.2 設(shè)備參數(shù)控制

獲得監(jiān)控客戶端界面中需要更改的參數(shù)并將其填入對應(yīng)的控制數(shù)據(jù)結(jié)構(gòu)中,發(fā)送命令方式采用SetRequest操作。設(shè)備參數(shù)控制命令類型依靠所定義的不同的命令代碼表示,將所需控制的命令代碼與所需要傳送的命令參數(shù),綁定在SetRequest操作的PDU中進(jìn)行發(fā)送。監(jiān)控服務(wù)端在收到SetRequest命令后,首先將命令類型數(shù)據(jù)解出,判斷出具體是哪一條命令,再由具體對應(yīng)的命令解碼方法解出余下的命令參數(shù)并控制到設(shè)備或進(jìn)行相應(yīng)的操作。

3.3.3 數(shù)據(jù)庫操作

在設(shè)定的數(shù)據(jù)庫中,主要記錄設(shè)備的參數(shù)狀態(tài),因此對于監(jiān)控客戶端來說,操作數(shù)據(jù)庫實(shí)際上更多的是對數(shù)據(jù)庫內(nèi)容的瀏覽與刪除兩項(xiàng)操作。對數(shù)據(jù)庫操作,監(jiān)控客戶端采用SetRequest方式將查詢或刪除數(shù)據(jù)庫命令發(fā)出,在發(fā)出的命令中綁定了兩個(gè)日期參數(shù),監(jiān)控服務(wù)端收到命令后,在處理刪除數(shù)據(jù)庫命令時(shí),直接將兩個(gè)日期之間的所有數(shù)據(jù)記錄刪除。處理查詢命令時(shí)需要將數(shù)據(jù)記錄讀出后全部返回到監(jiān)控客戶端。因一條記錄可能包含有多個(gè)參數(shù)狀態(tài),因此在返回查詢數(shù)據(jù)記錄時(shí),采用Trap方式上報(bào),一次返回一條記錄的方式進(jìn)行。監(jiān)控服務(wù)端單獨(dú)創(chuàng)建一個(gè)線程用于循環(huán)返回?cái)?shù)據(jù)記錄,一次返回發(fā)送50條記錄到監(jiān)控客戶端進(jìn)行顯示。如查詢的數(shù)據(jù)記錄大于50條,則可在監(jiān)控客戶端進(jìn)行翻頁操作,每點(diǎn)擊一次翻頁事件,查詢下面50條記錄并返回,以解決數(shù)據(jù)記錄過多可能造成的獲取與顯示問題。

3.3.4 用戶信息管理

對用戶信息的增加、刪除操作采用SetRequest方式發(fā)送到監(jiān)控服務(wù)端即可,已登錄用戶實(shí)時(shí)信息綁定在設(shè)備參數(shù)與狀態(tài)獲取的Trap包中一并返回,不需要進(jìn)行單獨(dú)的處理。在用戶信息中最重要的處理為漢字的傳輸,對于用戶信息,使用漢字進(jìn)行描述,而使用的AdventNet API無法支持String型傳輸漢字,因此處理漢字時(shí)需要在綁定至PDU上之前將漢字進(jìn)行編碼轉(zhuǎn)換,轉(zhuǎn)換為能夠正常傳輸?shù)木幋a再綁定到PDU上發(fā)送,監(jiān)控客戶端收到漢字后需要進(jìn)行一次逆轉(zhuǎn)換,轉(zhuǎn)換為正常的漢字編碼再進(jìn)行顯示。

3.3.5 圖像傳輸

監(jiān)控軟件中對圖像傳輸?shù)囊笾饕獮椴ㄐ螆D像,用于設(shè)備頻譜儀圖像的實(shí)時(shí)監(jiān)視。圖像傳輸標(biāo)志置為開始后一直進(jìn)行傳送,因此監(jiān)控服務(wù)端單獨(dú)創(chuàng)建傳輸線程,并使用Trap方式進(jìn)行圖像數(shù)據(jù)的傳輸。頻譜儀圖像采用每秒600點(diǎn)的采樣率進(jìn)行波形采集,對每點(diǎn)的數(shù)據(jù)存儲(chǔ)方式為N[X][ Y],即把X與Y軸位置進(jìn)行存儲(chǔ),發(fā)送到監(jiān)控客戶端后進(jìn)行相應(yīng)的還原、重繪以恢復(fù)圖像顯示。由于SNMP在對數(shù)據(jù)的傳輸時(shí),需要將對象的OID與對象數(shù)據(jù)一起綁定,若單獨(dú)設(shè)定一個(gè)對象OID對應(yīng)一個(gè)點(diǎn)的方式進(jìn)行綁定,按圖像數(shù)據(jù)每秒更新一次計(jì)算,即每秒需要進(jìn)行600 個(gè)點(diǎn)的數(shù)據(jù)傳輸,在MIB庫中,對圖像的傳輸就要設(shè)定600個(gè)元素,這樣導(dǎo)致MIB過于冗長,因此這里采用在MIB中只設(shè)定6個(gè)String型元素對象,每100 個(gè)點(diǎn)轉(zhuǎn)換為一個(gè)String型數(shù)據(jù)進(jìn)行傳輸,一秒內(nèi)傳輸6個(gè)String型(分為6個(gè)數(shù)據(jù)包)即可完成。在監(jiān)控客戶端收到數(shù)據(jù)后進(jìn)行一個(gè)循環(huán)依次解包,待6個(gè)數(shù)據(jù)包全部接收完畢并解碼完成后,即可對圖像進(jìn)行重繪顯示。

3.4 SNMP在遠(yuǎn)程監(jiān)控中的應(yīng)用分析

采用基于SNMP協(xié)議的方式實(shí)現(xiàn)客戶端和服務(wù)端之間的網(wǎng)絡(luò)信息傳輸,可以規(guī)范統(tǒng)一各地面站對外的信息接口,提高接口的可擴(kuò)展性,有利于遠(yuǎn)程監(jiān)控中心收集、處理分布在異地的各地面站的各種設(shè)備監(jiān)控信息。

通過原型系統(tǒng)的設(shè)計(jì)及試驗(yàn)驗(yàn)證,采用SNMP的方式可以實(shí)現(xiàn)遠(yuǎn)程監(jiān)控管理的設(shè)備參數(shù)與狀態(tài)的監(jiān)視、設(shè)備參數(shù)控制、數(shù)據(jù)庫操作、用戶信息管理、圖像獲取等幾個(gè)主要功能。其中,控制命令發(fā)出后設(shè)備或數(shù)據(jù)返回的響應(yīng)時(shí)間均小于2.5 s,并且響應(yīng)時(shí)間可通過對程序內(nèi)部數(shù)據(jù)處理邏輯的優(yōu)化進(jìn)行縮減;監(jiān)控軟件模擬實(shí)際系統(tǒng)運(yùn)行情況,進(jìn)行操作測試,在600 s內(nèi)統(tǒng)計(jì)對24種不同設(shè)備的共870個(gè)元素進(jìn)行監(jiān)視,并進(jìn)行30次不同設(shè)備的控制操作,總共產(chǎn)生9 487 500 byte數(shù)據(jù)量,監(jiān)控客戶端與監(jiān)控服務(wù)端之間的網(wǎng)絡(luò)信息傳輸?shù)钠骄加脦挒? 487 500/600=126.5 kbit/s。

采用SNMP方式構(gòu)建的C/S模式遠(yuǎn)程監(jiān)控管理系統(tǒng)中,對設(shè)備的參數(shù)與狀態(tài)的監(jiān)視、對設(shè)備的參數(shù)控制以及自動(dòng)化測試等功能均能得到良好的實(shí)現(xiàn)。但在進(jìn)行數(shù)據(jù)庫操作與圖像傳輸時(shí),由于數(shù)據(jù)本身的信息含量很大,網(wǎng)絡(luò)傳輸?shù)臅r(shí)效性將受到一定的影響。特別是在進(jìn)行數(shù)據(jù)庫瀏覽、查詢時(shí),數(shù)據(jù)量超過規(guī)定帶寬(例如256 kbit)時(shí),將會(huì)出現(xiàn)傳輸延遲現(xiàn)象,根據(jù)數(shù)據(jù)量的多少,完全傳輸一張表的內(nèi)容需要幾秒至幾十秒不等。

基于SNMP構(gòu)建C/S模式遠(yuǎn)程監(jiān)控管理系統(tǒng)具有一定的可行性,雖然在數(shù)據(jù)庫操作、圖像傳輸?shù)葞讉€(gè)特殊方面表現(xiàn)有所欠佳,但這主要還是由于其功能本身的特點(diǎn)以及網(wǎng)絡(luò)傳輸帶寬等因素所決定的。

4 結(jié)束語

本文提出了將SNMP協(xié)議與基于C/S結(jié)構(gòu)的遠(yuǎn)程監(jiān)控管理系統(tǒng)進(jìn)行融合,實(shí)現(xiàn)了監(jiān)控服務(wù)端與監(jiān)控客戶端之間的網(wǎng)絡(luò)傳輸采用標(biāo)準(zhǔn)的SNMP協(xié)議進(jìn)行通信,構(gòu)建C/S模式的遠(yuǎn)程監(jiān)控管理方式。同時(shí),提出了遠(yuǎn)程監(jiān)控主要功能在SNMP協(xié)議下的實(shí)現(xiàn)方式以及MIB中相應(yīng)的功能與設(shè)備的對象元素的設(shè)計(jì)方式,通過試驗(yàn)驗(yàn)證監(jiān)控服務(wù)端與監(jiān)控客戶端之間采用SNMP協(xié)議實(shí)現(xiàn)遠(yuǎn)程監(jiān)控功能的可行性、占用帶寬及性能等。在SNMP協(xié)議下,客戶端與服務(wù)端之間的網(wǎng)絡(luò)通信為點(diǎn)對點(diǎn)方式,因此,我們在對多遠(yuǎn)程客戶端自由接入服務(wù)端的功能支持上并不完善,這將是后續(xù)研究的主要方向。

[ 1] 曾凡鋒.基于SNMP的網(wǎng)絡(luò)流量統(tǒng)計(jì)分析系統(tǒng)[ J].北方工業(yè)大學(xué)學(xué)報(bào), 2003, 15(1):17-20.

ZENG Fan-feng.The Netflow Statistical and Analytical System Based on SNMP[J].Journal of North China University of Technology, 2003, 15(1):17 -20.(in Chinese)

[ 2] 劉翔, 沈明玉.基于 SNMP與Web的服務(wù)監(jiān)控系統(tǒng)[ J] .合肥工業(yè)大學(xué)學(xué)報(bào), 2008, 31(1):44-47.

LIU Xiang, SHEN Ming-yu.Design of a server monitoring system based on the SNMP and Web[J].Journal of Hefei University of Technology, 2008, 31(1):44-47.(in Chinese)