- 相關(guān)推薦
面向物聯(lián)網(wǎng)環(huán)境的網(wǎng)絡(luò )設備消息轉換機制分析
物聯(lián)網(wǎng)在當前互聯(lián)網(wǎng)的基礎上有了許多新的特點(diǎn)，因此對于物聯(lián)網(wǎng)網(wǎng)絡(luò )管理提出了新的需求，下面是小編搜集的一篇相關(guān)論文范文，歡迎閱讀借鑒。
1引言
ISO定義的網(wǎng)絡(luò )管理5個(gè)系統管理功能在物聯(lián)網(wǎng)時(shí)代難以滿(mǎn)足新的需求，傳統的基于簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP，SimpleNetworkManagementPro-tocol)的網(wǎng)絡(luò )管理系統，不管在擴展性方面還是管理效率方面的局限性日益突出，因此迫切需要新的網(wǎng)絡(luò )管理系統模型.可擴展標記語(yǔ)言[1](XML，eXtensibleMarkupLanguage)的出現為構建物聯(lián)網(wǎng)環(huán)境下的網(wǎng)絡(luò )管理模型提供了可能.基于XML的網(wǎng)絡(luò )管理系統具有其他網(wǎng)絡(luò )管理系統無(wú)法比擬的特性，這些特性使得它非常適用于物聯(lián)網(wǎng)網(wǎng)絡(luò )管理.基于上述優(yōu)勢，為了統一規范基于XML的網(wǎng)絡(luò )管理，IETF在2006年提出了基于XML技術(shù)的NETCONF[3](RFC4741)協(xié)議.NETCONF的提出不僅使基于XML新一代網(wǎng)絡(luò )管理配置方面的功能得以加強，形成了結構明晰的規范，也使得XML網(wǎng)絡(luò )管理的效率得到顯著(zhù)提升.基于NETCONF的網(wǎng)絡(luò )管理已經(jīng)得到廣泛認可，事實(shí)上一些IT公司也開(kāi)發(fā)并實(shí)現了支持NETCONF的相關(guān)系統，如Juniper公司的JU-NO[4]產(chǎn)品、Cisco公司的IOS[5]產(chǎn)品，相關(guān)開(kāi)源產(chǎn)品有en-suite[6]的yencap+manager和yuma[7]等.
對于物聯(lián)網(wǎng)這種融入各種異構網(wǎng)絡(luò )的網(wǎng)絡(luò )系統，更加迫切需要基于NETCONF的網(wǎng)絡(luò )管理系統實(shí)現對網(wǎng)絡(luò )設備跨網(wǎng)絡(luò )、跨系統的高效管理.物聯(lián)網(wǎng)相對于傳統的互聯(lián)網(wǎng)具有自身的一些顯著(zhù)特征，比如，網(wǎng)絡(luò )拓撲變化很快;網(wǎng)絡(luò )節點(diǎn)可以高速移動(dòng);節點(diǎn)間的鏈路狀態(tài)變化頻繁;節點(diǎn)能量、計算能力、存儲能力有限等.NETCONF取代事實(shí)上的工業(yè)標準SNMP協(xié)議將會(huì )是一個(gè)漫長(cháng)的過(guò)程，有必要通過(guò)一種轉換機制，實(shí)現既能管理SNMP的網(wǎng)絡(luò )設備，又能對基于其他網(wǎng)絡(luò )協(xié)議的設備進(jìn)行有效管理.將NETCONF應用于物聯(lián)網(wǎng)網(wǎng)絡(luò )管理，首先必須實(shí)現對SNMP的兼容，能將基于NETCONF的管理報文轉換為SNMP管理報文.目前，協(xié)議轉換研究吸引了許多網(wǎng)絡(luò )管理專(zhuān)家的注意，但是大多數停留在理論階段，或者研發(fā)的系統擴展性較差，針對物聯(lián)網(wǎng)這一復雜網(wǎng)絡(luò )環(huán)境下的消息轉換方法研究很少.本文設計的消息轉換機制可以實(shí)現對目前廣泛采用的SNMP協(xié)議，非SNMP協(xié)議(比如ANMP，NETCONF)的支持，并且結合物聯(lián)網(wǎng)特點(diǎn)設計NETCONF管理端、代理端，便于今后在物聯(lián)網(wǎng)這個(gè)大環(huán)境下實(shí)現網(wǎng)絡(luò )設備的統一管理.
2相關(guān)工作
在轉換網(wǎng)關(guān)方面，為了彌補SNMP協(xié)議在網(wǎng)絡(luò )管理擴展性以及效率上的不足，文獻[8]提出一種SNMPMIB到XML的轉換算法，并將轉換算法應用于SNMP-XML轉換網(wǎng)關(guān).文獻[9]重點(diǎn)討論了SNMP-XML翻譯網(wǎng)關(guān)中的MIB轉換技術(shù)，并實(shí)現了MIB文件到XML文件的轉換.文獻[10]提出一種基于NETCONF的網(wǎng)絡(luò )管理系統對SNMP和CLI設備進(jìn)行管理的方法，文章主要分析數據模型的轉換以及消息映射.文獻[11]提出了一種通用網(wǎng)關(guān)模型，實(shí)現基于XML網(wǎng)絡(luò )管理對SNMP代理和非SNMP代理的統一管理.在NETCONF協(xié)議的分析和應用開(kāi)發(fā)方面，文獻[12]通過(guò)實(shí)驗分析證明了NETCONF在復雜網(wǎng)絡(luò )環(huán)境下的強大性能，實(shí)驗結果顯示了NETCONF相對于SNMP和CLI，在網(wǎng)絡(luò )管理上更高效、更安全、擴展性更強、更容易開(kāi)發(fā)新的應用.文獻[13]對NETCONF的三種建模語(yǔ)言XMLSchema、RelaxNG和YANG進(jìn)行了對比分析，得出盡管YANG是專(zhuān)門(mén)為NET-CONF設計的建模語(yǔ)言，但是仍然有些地方考慮不足，比如轉換工具設計得并不完善.上述文獻大多數停留在理論架構階段，或者僅僅對某個(gè)單一功能進(jìn)行實(shí)現，例如文獻[8]提出的轉換器安全性不高，數據在傳輸過(guò)程中容易被劫取，而且使用的XML管理報文沒(méi)有形成統一規范.文獻[9-10]主要針對數據模型轉換，文獻[11]主要停留在管理消息轉換的架構設計上，在實(shí)現方面只做了簡(jiǎn)單的描述.盡管NETCONF有眾多優(yōu)點(diǎn)，但是SNMP作為事實(shí)上的網(wǎng)絡(luò )管理工業(yè)標準有很多不可替代的特性，比如它的簡(jiǎn)易性、實(shí)用性，以及它對設備的實(shí)時(shí)監控性?xún)?yōu)于NET-CONF協(xié)議，這些決定了未來(lái)SNMP協(xié)議將長(cháng)期存在于網(wǎng)絡(luò )環(huán)境中，單純地將NETCONF應用于物聯(lián)網(wǎng)不切實(shí)際.本文基于NETCONF協(xié)議，提出面向物聯(lián)網(wǎng)網(wǎng)絡(luò )管理的消息轉換機制，實(shí)現對SNMP的兼容，同時(shí)也考慮了對其他網(wǎng)絡(luò )管理協(xié)議的支持和系統的擴展性，為物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò )設備的統一管理提供了參考.
3基于NETCONF網(wǎng)絡(luò )管理架構
3.1基于NETCONF管理端
管理端一共包含3個(gè)模塊，如圖1所示，分別是交互界面、管理消息處理層、會(huì )話(huà)通信層.交互界面負責與管理員進(jìn)行信息交互.消息處理層是管理端的核心模塊，負責將管理消息封裝成基于NETCONF的管理報文，并傳送給會(huì )話(huà)通信層.另外還負責驗證收到的報文格式，解析出操作結果.內容層封裝是根據采用的數據模型對報文進(jìn)行封裝.操作層封裝、RPC封裝則根據用戶(hù)選擇的操作類(lèi)型將報文封裝到相應的RPC報文中去.會(huì )話(huà)通信層對應NETCONF邏輯模型中傳輸層，負責將管理消息傳輸給消息轉換器，并等待消息轉換器的響應，將響應結果返回給消息處理層.【1】
3.2消息轉換器架構
本文的消息轉換器基于WebService進(jìn)行通信.基于對XML的廣泛接受，WebService成為使用標準傳輸、編碼和協(xié)議來(lái)交換信息的應用程序.選擇WebService作為管理端與消息轉換器之間報文的傳遞，符合在物聯(lián)網(wǎng)下網(wǎng)絡(luò )管理消息傳遞的特性要求，更容易實(shí)現跨平臺、跨設備、跨網(wǎng)絡(luò )對網(wǎng)絡(luò )設備的監管.消息轉換器對發(fā)送過(guò)來(lái)的管理報文進(jìn)行相應轉換，使得網(wǎng)絡(luò )管理端可以與不同類(lèi)型的代理端進(jìn)行通信，消息轉換器以WebService的方式發(fā)布，實(shí)現與管理端交互，并且直接與物聯(lián)網(wǎng)環(huán)境下不同類(lèi)型的代理進(jìn)行信息交互.消息轉換器的整體架構如下頁(yè)圖2所示.主要分為三個(gè)功能模塊，即消息分類(lèi)器SNMP，報文轉換模塊，其它代理報文轉換模塊.
3.2.1NETCONF-SNMP管理消息轉換負責將NETCONF管理報文轉換為SNMP管理報文的轉換器主要由6個(gè)模塊構成，分別是請求分析器、MIB-XML翻譯器、XMLDOM、XML詢(xún)問(wèn)器、trap處理模塊(由trap接收器、trap分析器和trap過(guò)濾器組成)以及報文生成器.請求分析器結合XMLSchema判斷管理報文的合法性，并且結合操作類(lèi)型映射表提取操作類(lèi)型.MIB-XML翻譯器負責將SMIMIB轉換為XML，轉換后的XML，可以實(shí)現查找操作對象對應的OID，和操作對象的映射.XMLDOM是轉換器的核心，對XML文件進(jìn)行分析，將得到的設備地址、操作類(lèi)型，操作對象OID等，傳給SNMP輪詢(xún)器，還負責接收trap，實(shí)現trap中參數映射后，傳遞給XML報文生成器.SNMP輪詢(xún)器將得到的參數包裝成SNMPPDU傳給SNMP代理，并且接受來(lái)自SNMP代理的響應.為了減少管理端與轉換器之間的通信流量，對SNMPtrap處理上采用過(guò)濾機制，trap處理器由3個(gè)模塊組成，將接收到的trap進(jìn)行分類(lèi)，并建立分級制度來(lái)判斷緊急程度，最后過(guò)濾掉一些重復或者失效的trap報文，并傳遞給XMLDOM報文生成器生成相應的響應報文或通知報文后傳給NETCONF管理端.NETCONF-SNMP轉換器也可以實(shí)現對ANMP代理的兼容性，這在于A(yíng)NMP使用與SNMP相同的PDU格式，而且同樣使用UDP作為傳輸協(xié)議來(lái)發(fā)送ANMP消息，在數據收集和控制方面，ANMP擴展了SNMPMIB以便記錄AdHoc網(wǎng)絡(luò )特有的信息.若要對ANMP代理進(jìn)行管理，首先管理端載入對應的MIB文件，消息分類(lèi)器判斷管理報文中的IP地址，若對應的是ANMP代理時(shí)，將管理報文傳給轉換器，可以實(shí)現對ANMP代理對應設備的有效管理.
3.2.2對其他網(wǎng)絡(luò )管理協(xié)議的支持考慮到物聯(lián)網(wǎng)環(huán)境下存在少量其他網(wǎng)絡(luò )管理協(xié)議，本文加入了一種支持其他網(wǎng)絡(luò )管理協(xié)議的理論構架，下面對這種架構進(jìn)行闡述.如圖2所示，架構主要有四部分組成，分別是數據表、適配器、消息產(chǎn)生器、Trap接收器.其中三個(gè)數據表和三個(gè)適配器是架構的關(guān)鍵，設備信息表記錄代理的相關(guān)信息，用以區分管理端與哪個(gè)代理通信;私有數據表將NETCONF的屬性映射為代理的私有屬性;操作表則將NETCONF的操作類(lèi)型映射為代理的私有操作類(lèi)型.報文適配器實(shí)現報文格式對應;傳輸適配器負責轉換器與多種代理進(jìn)行通信;trap適配器則負責代理如何主動(dòng)與管理端進(jìn)程通信，通知管理進(jìn)程有某些事情發(fā)生.【2】
當管理端與代理通信時(shí)，轉換器首先載入該代理的XML配置文件，生成三個(gè)數據表，分別是設備信息表、操作類(lèi)型表、私有數據表.通過(guò)數據表生成上述三個(gè)適配器的具體實(shí)現，適配管理器負責初始化適配器并在合適的時(shí)候調用適配器.在適配管理器的協(xié)調下，消息產(chǎn)生器就能將管理端傳遞過(guò)來(lái)的NETCONF配置報文通過(guò)適配器轉化為代理能夠識別的PDU，返回的PDU也能通過(guò)管理消息產(chǎn)生器轉換為基于NETCONF的響應報文.
3.3代理端架構設計
目前Cisco，Juniper等網(wǎng)絡(luò )設備生產(chǎn)商都實(shí)現了基于RFC4741的代理，并嵌入到了它們最新的路由器當中.NETCONF采用XML進(jìn)行數據傳輸和模塊表達，具有較強的可擴展性，網(wǎng)絡(luò )設備提供商可以使用此協(xié)議獲取、設置所有的配置數據，適合物聯(lián)網(wǎng)下的不同類(lèi)型設備快速添加和高效管理.這些功能很大一部分依賴(lài)于代理端的實(shí)現，如何將基1對其進(jìn)行網(wǎng)絡(luò )管理是一個(gè)迫切需要解決的問(wèn)題，這關(guān)系到NETCONF在物聯(lián)網(wǎng)網(wǎng)絡(luò )管理的生命力.本文將代理分為三種類(lèi)型，分別是SNMP代理、NETCONF代理和其他代理.本節結合物聯(lián)網(wǎng)的特征分析了NETCONF代理架構設計，按照RFC4741中規定，一個(gè)基本的NETCONF代理分四層結構來(lái)設計.另外代理必須完成對能力特性、三種數據庫狀態(tài)和事件通知的支持，基于NETCONF的代理架構如圖3所示.【3】
會(huì )話(huà)通信層負責與管理端交互，代理端啟動(dòng)后會(huì )監聽(tīng)來(lái)自管理端的管理消息.消息處理器接受來(lái)自會(huì )話(huà)通信層的管理消息后，能夠解析出操作類(lèi)型和操作對象并傳給操作處理器，也能將操作處理器操作后的結果封裝成基于NETCONF的響應報文.操作處理器執行消息處理器解析出來(lái)的具體操作.管理對象信息庫中配置信息狀態(tài)分為3個(gè)階段，對應3種數據庫狀態(tài):運行狀態(tài)(running)、啟動(dòng)狀態(tài)(startup)和候選狀態(tài)(candidate).能力(capabilities)是NETCONF的新特性，這種特性允許客戶(hù)端發(fā)現服務(wù)端支持的協(xié)議擴展集，“能力”的提出豐富了基本操作集，增加新的操作使代理端擴展性得到提高.被管理設備將能力集傳遞給管理數據庫存儲，在管理端發(fā)出“HELLO”報文后，傳遞給管理端以告知管理端被管設備支持的協(xié)議擴展集.通知(Notification)模塊負責將被管理設備主動(dòng)發(fā)出的消息傳遞給消息處理器，再由消息處理器封裝后，通過(guò)會(huì )話(huà)通信層傳遞給管理端.本文并沒(méi)有將重點(diǎn)放在討論“能力”和“通知”這種兩種特性上，但這兩種特性對于將NETCONF應用到物聯(lián)網(wǎng)環(huán)境中至關(guān)重要，因為物聯(lián)網(wǎng)環(huán)境需要“能力”來(lái)支持可擴展性，“通知”來(lái)支持對被管設備的實(shí)時(shí)監控，這也是我們未來(lái)工作討論的重點(diǎn).
4轉換算法流程設計
4.1數據模型分析
與SNMP相比，NETCONF是一個(gè)全新的XML配置管理協(xié)議.NETCONF協(xié)議在概念上分為四層，分別是內容層、操作層、RPC層和傳輸協(xié)議層.目前操作層、RPC層、傳輸協(xié)議層都有相應的標準和規范，內容層并沒(méi)有給出具體要求，允許單獨定義NETCONF數據模型，使得它的靈活性增強，但是另一方面也阻礙了NETCONF的廣泛應用，數據模型定義與傳統數據模型的轉換是目前各大國際化標準研究的重點(diǎn)和熱點(diǎn).2009年，NETMOD工作組提出將YANG[14]作為標準的NET-CONF數據建模方法目前還處于討論和驗證中.現有的數據模型語(yǔ)言，如XMLSchemaDefinition(XSD)和RelaxNG可以用于其數據模型.正因為NETCONF基于XML，所以XSD是其一種比較理想的選擇，本文也是采用XSD作為數據建模語(yǔ)言來(lái)開(kāi)展實(shí)驗.IETF組織，特別是NETCONF工作組將XMLSchema列入考慮之中.【4】
德國開(kāi)發(fā)的LIBSMI[15]是比較成功的案例，得到了廣泛的認可，它將MIB樹(shù)轉換為公認較好的四層結構，如圖4所示.前兩層與具體MIB無(wú)關(guān)，只有下兩層才依賴(lài)于具體MIB，第三層為表結點(diǎn)的ENTRY結點(diǎn)，或者是標量結點(diǎn)的容器結點(diǎn)，第四層是葉子結點(diǎn).對于非MIB樹(shù)形式的管理對象也可以建立這樣的四層結構模型，這樣統一了網(wǎng)絡(luò )被管對象的描述.本文在實(shí)驗中便采用了該四層結構來(lái)規范管理對象數據.
4.2關(guān)鍵類(lèi)設計
為了實(shí)現基于XML的NETCONF報文到SNMP報文的轉換，需要對NETCONF報文進(jìn)行解析.基于第2節中的轉換器架構，本文設計的關(guān)鍵類(lèi)有:ParseXML類(lèi)、XmlDocument類(lèi)、Oper-ations類(lèi)以及UdpTarget類(lèi)，關(guān)鍵類(lèi)圖如圖5所示.ParseXML類(lèi)用于對NETCONF報文進(jìn)行解析，其實(shí)現依賴(lài)于其他三個(gè)關(guān)鍵類(lèi);XmlDocument類(lèi)主要用來(lái)提取基于XML的NETCONF報文的關(guān)鍵信息，如設備IP地址、操作對象OID、操作類(lèi)型等;Operations類(lèi)提供三種基本SNMP操作:GetRequest、GetBulkRequest和SetRequest，這為實(shí)現SNMP的基本功能提供了可能;UdpTarget類(lèi)主要用來(lái)構造SNMPPDU，并依據具體操作發(fā)送相應SNMP請求報文.
5實(shí)驗與分析
5.1實(shí)驗環(huán)境和參數
采用VisualStudio2010作為開(kāi)發(fā)平臺，編程語(yǔ)言是C#.實(shí)驗選擇了四臺機器，一臺機器作為基于NETCONF的網(wǎng)絡(luò )管理端，一臺機器作為報文轉換器，一臺機器作為SNMP代理，一臺作為NETCONF代理，SNMP代理端和NETCONF代理端分別通過(guò)RS232與匯聚節點(diǎn)相連，通過(guò)USB與和RFID讀卡器相連，匯聚節點(diǎn)通過(guò)ZigBee協(xié)議與靜態(tài)節點(diǎn)相連.實(shí)驗環(huán)境如圖7(見(jiàn)下頁(yè))所示.
5.2運行實(shí)例
本文選取SNMP代理和NETCONF代理進(jìn)行實(shí)驗，目標是通過(guò)基于NETCONF管理端是獲取設備的sysUpTime.點(diǎn)擊“importobjectofmanagement”，管理對象以樹(shù)形結構顯示在對象瀏覽器窗口中選擇管理設備.輸入代理的IP地址再分別選擇操作類(lèi)型，數據庫狀態(tài)，操作對象，點(diǎn)擊“cre-ateMessage”，管理端產(chǎn)生基于NETCONF管理報文并顯示在發(fā)送窗口中.點(diǎn)擊“sendMessage”，發(fā)送報文，等待轉換器響應后，響應報文顯示在報文接收窗口中.若對應的是SNMP代理，接收窗口直接顯示結果，發(fā)送報文以及返回報文如圖8(見(jiàn)下頁(yè))所示.若對應的是NETCONF代理，接收窗口顯示基于NET-CONF的rpc-reply報文，發(fā)送報文及返回報文如圖9所示.若對應的是NETCONF代理并且發(fā)送報文缺少message-id，則返回基于NETCONF的rpc-error報文，封裝在rpc-reply中，發(fā)送和返回的報文如圖10所示.
5.3實(shí)驗分析結果與改進(jìn)
圖11和圖12分別表示系統測試20組，每組100次隨機get-config操作的響應時(shí)間比較.測試的響應時(shí)間類(lèi)型分別是響應總時(shí)間Tall、管理端到轉換器傳輸時(shí)間TMT、轉換器處理時(shí)間TTR、轉換器到代理端響應時(shí)間TTA.本文在測試時(shí)，第一次響應時(shí)間作為特例不考慮，這是因為轉換器以Web服務(wù)的方式發(fā)布，通過(guò)TCP三次握手與管理端建立連接，而轉換器與代理之間通過(guò)UDP通信，UDP不需要建立連接.由圖11和圖12可知，四種類(lèi)型響應時(shí)間在一個(gè)相對穩定的區間內波動(dòng)，但是Tall和TMT明顯高于TTR和TTA.經(jīng)過(guò)分析，這主要是因為兩方面原因，首先基于TCP的報文傳輸時(shí)間明顯高于基于UDP的報文傳輸時(shí)間，另外在包的大小方面，基于NETCONF的管理端發(fā)送的是XML報文，相對于SNMP只需變量綁定要復雜.圖12表示的是管理端發(fā)送的報文與經(jīng)過(guò)轉換后的報文大小的變化比較，實(shí)驗只考慮TCP或UDP報文段的數據部分.
本文測試用mib-2中前8個(gè)基本對象組，對于MIB樹(shù)中非葉子結點(diǎn)的實(shí)例，轉換器自動(dòng)調用GetBulkOperation與代理交互.由圖13可知，NETCONF管理端的管理報文大小幾乎是穩定不變的，通過(guò)轉換器轉換后的SNMP管理報文大小的變化波動(dòng)相對較大.通過(guò)分析，這主要因為考慮到8個(gè)基本對象組中標量對象的個(gè)數不盡相同，權衡代理的處理時(shí)間和轉換后報文數量后，實(shí)驗將SNMPv2GetBulk報文的NonRepeaters字段設置為0，MaxRepetitions字段設置為20，對于標量對象大于20的對象組需要發(fā)送多個(gè)GetBulk請求.今后這部分可以?xún)?yōu)化，根據實(shí)際需要自動(dòng)生成這兩個(gè)參數來(lái)減少轉換后的報文大小.測試轉換前后報文大小變化為今后轉化器位置部署提供了參考.圖13(見(jiàn)上頁(yè))表示的是隨機產(chǎn)生20組，每組10000次管理報文得到正確響應報文的成功率，失敗的操作將會(huì )返回錯誤類(lèi)型.通過(guò)實(shí)驗發(fā)現兩種操作的成功率穩定在99.4%以上，通過(guò)返回的錯誤類(lèi)型發(fā)現，失敗與否主要與當前網(wǎng)絡(luò )和系統狀況有關(guān).get-congfig操作的成功率總體上高于edit-config的成功率，這是因為配置操作相對于取值操作受限更多.實(shí)驗選擇了響應時(shí)間、報文大小變化、成功率來(lái)評價(jià)系統的性能.實(shí)驗主要考慮的是NETCONF管理端與SNMP代理的兼容性，數據模型采用的是在4.1節介紹的基于XML的四層結構，即將MIB-2庫通過(guò)smidump轉換成實(shí)驗所需要的模型.實(shí)驗過(guò)程中還發(fā)現，在轉換過(guò)程中存在MIB樹(shù)中間結點(diǎn)丟失的情況，由此可見(jiàn)轉換MIB信息表達效率不夠精確.
6結論
為了在物聯(lián)網(wǎng)環(huán)境中部署一種基于NETCONF的統一網(wǎng)絡(luò )管理系統，考慮到當前SNMP在配置性能、安全性和擴展性方面的不足，以及SMI語(yǔ)法復雜和靈活性差等問(wèn)題，文章提出了面向物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò )管理消息轉換機制，它能夠自適應地對各種設備進(jìn)行管理，特別是將這種轉換機制通過(guò)WebService的方式提供給管理端，在安全性、可擴展性、配置效率上有很大程度提高.本文還提出了管理端、轉換器、代理端的設計架構，通過(guò)實(shí)驗驗證了系統對SNMP代理的兼容性，能夠對SNMP設備進(jìn)行有效管理.未來(lái)工作中我們將研究重點(diǎn)集中在數據模型、可擴展性、被管設備監控性能優(yōu)化三個(gè)方面，最終實(shí)現物聯(lián)網(wǎng)環(huán)境下網(wǎng)絡(luò )設備的統一高效管理.
【面向物聯(lián)網(wǎng)環(huán)境的網(wǎng)絡(luò )設備消息轉換機制分析】相關(guān)文章：
無(wú)線(xiàn)通信技術(shù)與物聯(lián)網(wǎng)技術(shù)分析論文09-18
分析物聯(lián)網(wǎng)技術(shù)在電力智能在線(xiàn)監測的應用08-20
MFC中消息映射機制分析08-18
基于物聯(lián)網(wǎng)環(huán)境下的供應鏈庫存管理研究論文10-20
物聯(lián)網(wǎng)營(yíng)銷(xiāo)“未來(lái)派”08-04
面向對象的液壓系統分析研究09-13