專利名稱：一種分布式架構(gòu)數(shù)據(jù)通信設(shè)備的消息保護系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分布式架構(gòu)的數(shù)據(jù)通信設(shè)備，具體地說，是涉及一種分布式 架構(gòu)數(shù)據(jù)通信設(shè)備的消息保護系統(tǒng)及方法。
背景技術(shù)：
隨著互聯(lián)網(wǎng)的發(fā)展和壯大，各種各樣的互聯(lián)網(wǎng)設(shè)備相繼出現(xiàn)。在網(wǎng)絡(luò)的 匯聚層和核心層，為了緩解巨大業(yè)務(wù)量對設(shè)備性能的要求，分布式架構(gòu)設(shè)備 的應(yīng)用已經(jīng)得到了普及。
如圖1所示，分布式架構(gòu)主要由系統(tǒng)主控單元110、若千業(yè)務(wù)處理單元 120、系統(tǒng)主控單元110和業(yè)務(wù)處理單元120之間及各業(yè)務(wù)處理單元120之間 的數(shù)據(jù)通道130組成，各業(yè)務(wù)處理單元120都能獨立完成某種業(yè)務(wù)的處理， 而系統(tǒng)資源的統(tǒng)一調(diào)度管理由系統(tǒng)主控單元110完成，其中
系統(tǒng)主控單元110，負責管理和維護整個設(shè)備，并對系統(tǒng)資源進行統(tǒng)一 調(diào)度，對筒單網(wǎng)絡(luò)管理協(xié)議(simple network management protocol，縮寫為 SNMP)等協(xié)議的各種消息的最后處理及響應(yīng)均是在這里完成的；
業(yè)務(wù)處理單元120,負責接收數(shù)據(jù)并根據(jù)數(shù)據(jù)內(nèi)容進行諸如轉(zhuǎn)發(fā)、上送 給業(yè)務(wù)處理單元中央處理器(CPU)或者丟棄等處理；
數(shù)據(jù)通道130:主要負責系統(tǒng)主控單元110和業(yè)務(wù)處理單元120以及各 業(yè)務(wù)處理單元120之間的消息、數(shù)據(jù)交換等，根據(jù)分布式系統(tǒng)設(shè)備不同而各 有區(qū)別，比如可以根據(jù)實際情況分為多個處理單元，如業(yè)務(wù)處理單元120之 間的數(shù)據(jù)交換可以由專門的交換單元來處理等等。
為了更好地管理網(wǎng)絡(luò)中的各種設(shè)備，開發(fā)了各種各樣的網(wǎng)絡(luò)協(xié)議，如使 用網(wǎng)絡(luò)時間協(xié)議(network time protocol,縮寫為NTP)同步網(wǎng)絡(luò)里各設(shè)備的 時間、使用SNMP實現(xiàn)網(wǎng)絡(luò)設(shè)備的遠程集中管理等等。
然而隨著網(wǎng)絡(luò)設(shè)備和網(wǎng)絡(luò)協(xié)議的不斷涌現(xiàn)，利用網(wǎng)絡(luò)協(xié)議針對網(wǎng)絡(luò)設(shè)備
的攻擊也不斷出現(xiàn)，如最常見的"拒絕月良務(wù)"(Denial of Service,縮寫為DOS) 攻擊(一種通過發(fā)送大量模擬協(xié)議報文來占用被攻擊設(shè)備的CPU資源，使其 它正常業(yè)務(wù)受到影響甚至中斷的方法)等等。針對這些攻擊，網(wǎng)絡(luò)釆取了一 些保護措施，如包限速功能，在業(yè)務(wù)處理單元上限制各種協(xié)議包上送CPU處 理的速度，從而達到保護CPU的目的。
針對集中式的設(shè)備，現(xiàn)階段釆用的技術(shù)能比較有效地實現(xiàn)對CPU的保 護。但是在分布式環(huán)境中，各業(yè)務(wù)處理單元盡管得到了保護，但是從業(yè)務(wù)處 理單元CPU到系統(tǒng)主控單元CPU卻沒有任何保護措施，而是直接上送。存 在某些協(xié)議(如SNMP、 NTP等)，在業(yè)務(wù)處理單元處理后需要上送給系統(tǒng) 主控單元進行進一步處理，在這個過程中，存在以下問題
因為各業(yè)務(wù)處理單元CPU只要判斷是否為SNMP或者NTP等協(xié)議報文， 是則上送給系統(tǒng)主控單元CPU進一步處理，這樣各業(yè)務(wù)處理單元CPU利用 率可能還很低，但是系統(tǒng)主控單元的CPU可能已經(jīng)不堪重負。以SNMP協(xié)議 為例現(xiàn)在SNMP管理器(manager) —端常用的一種由很多個讀取下一個請 求(GetNextRequest)消息組合而成的讀取批量請求(GetBulkRequest)消息， 當GetBulkRequest中請求的管理對象在代理(agent)的管理信息庫(MIB) 中不存在，系統(tǒng)主控單元仍然需要完整地檢索整個MIB庫后，才能確定需要 查找的MIB文件不存在。由于一個數(shù)據(jù)包內(nèi)攜帶多個請求消息，這將導(dǎo)致主 控CPU利用率居高不下，甚至停止響應(yīng)其它正常請求如telnet和console 口等。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是在于需要提供一種分布式架構(gòu)數(shù)據(jù)通信設(shè) 備的消息保護系統(tǒng)及相應(yīng)的保護方法，以有效保護分布式架構(gòu)數(shù)據(jù)通信設(shè)備 的CPU。
為了解決上述技術(shù)問題，本發(fā)明首先提供了一種分布式架構(gòu)數(shù)據(jù)通信設(shè) 備的消息保護系統(tǒng)，包括轉(zhuǎn)發(fā)模塊、協(xié)議分析模塊、內(nèi)部服務(wù)質(zhì)量模塊、管 理才莫塊及協(xié)議處理模塊，其中
所述轉(zhuǎn)發(fā)才莫塊，位于所述分布式架構(gòu)數(shù)據(jù)通信設(shè)備的業(yè)務(wù)處理單元上， 用于接收并上送需要CPU處理的待處理才艮文；
所述協(xié)議分析才莫塊，與所述轉(zhuǎn)發(fā)才莫塊相連，用于對所述待處理才艮文進行 協(xié)議分析，獲得所述待處理報文的協(xié)議類型；
所述管理才莫塊，用于獲取所迷系統(tǒng)主控單元CPU和緩存的利用率；
所述內(nèi)部服務(wù)質(zhì)量模塊，與所述協(xié)議分析模塊及管理模塊相連，用于向 所述協(xié)議處理模塊轉(zhuǎn)發(fā)所述待處理報文，并根據(jù)所述系統(tǒng)主控單元CPU和緩 存的利用率，對所述待處理報文中需要系統(tǒng)主控單元CPU處理的報文進行服 務(wù)質(zhì)量限速處理；及
所述協(xié)議處理模塊，與所述內(nèi)部服務(wù)質(zhì)量模塊相連，用于根據(jù)所述待處 理報文的協(xié)議類型，對所述待處理報文進行處理。
如上所述的系統(tǒng)中，所述轉(zhuǎn)發(fā)才莫塊，可以進一步與所述協(xié)議處理才莫塊相 連，用于反饋所述協(xié)議處理模塊處理所述待處理報文后的響應(yīng)。
如上所述的系統(tǒng)中，所述內(nèi)部服務(wù)質(zhì)量模塊，可以根據(jù)所述系統(tǒng)主控單 元CPU和緩存的利用率，利用服務(wù)質(zhì)量的約定訪問速率原理，對所述需要系 統(tǒng)主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理。
進一步地，所述內(nèi)部服務(wù)質(zhì)量模塊，可以根據(jù)所述系統(tǒng)主控單元CPU的 性能及所述數(shù)據(jù)通信設(shè)備可能面對的突發(fā)業(yè)務(wù)流對所述系統(tǒng)主控單元CPU占 用綜合權(quán)衡后，設(shè)置承諾訪問速率和順從突發(fā)量的值，根據(jù)所述承諾訪問速 率和順從突發(fā)量的值，對所述需要系統(tǒng)主控單元CPU進行處理的報文進行服 務(wù)質(zhì)量限速處理。
為了解決上述技術(shù)問題，本發(fā)明還提供了 一種分布式架構(gòu)數(shù)據(jù)通信設(shè)備 的消息保護方法，包括步驟
分布式架構(gòu)數(shù)據(jù)通信設(shè)備的業(yè)務(wù)處理單元收到報文之后，分析出需要 CPU處理的待處理才艮文；
對所述待處理報文進行協(xié)議分析，獲得所述待處理報文的協(xié)議類型；
獲得所述分布式架構(gòu)數(shù)據(jù)通信設(shè)備的系統(tǒng)主控單元CPU和緩存的利用
率；
根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率，對所述待處理報文中需要 系統(tǒng)主控單元CPU處理的才艮文進行服務(wù)質(zhì)量限速處理；及
根據(jù)所述待處理報文的協(xié)議類型，對所述待處理報文進行處理。
如上所述的方法中，所述待處理報文，可以包括廣播包、協(xié)議包、目的 地址為設(shè)備本身、或者已經(jīng)標識需要上送的報文。
進一步地，所述待處理凈艮文可以包括簡單網(wǎng)絡(luò)管理協(xié)議報文或者網(wǎng)絡(luò)時 間協(xié)議凈艮文。
如上所述的方法中，可以根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率， 利用服務(wù)質(zhì)量的約定訪問速率原理，對所述需要系統(tǒng)主控單元CPU處理的報 文進行服務(wù)質(zhì)量限速處理。
進一步地，可以根據(jù)所述系統(tǒng)主控單元CPU的性能及所述數(shù)據(jù)通信設(shè)備 可能面對的突發(fā)業(yè)務(wù)流對所述泉統(tǒng)主控單元CPU占用綜合權(quán)衡后，設(shè)置承諾 訪問速率和順從突發(fā)量的值，根據(jù)所述承諾訪問速率和順從突發(fā)量的值，對 所述需要系統(tǒng)主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理。
如上所述的方法中，對所述待處理報文進行處理時，可以進一步對所述 待處理才艮文進行正確性檢查及版本匹配。
與現(xiàn)有技術(shù)相比，本發(fā)明提供了一種在分布式架構(gòu)的設(shè)備中基于服務(wù)質(zhì) 量(QOS)的消息保護機制，結(jié)合各業(yè)務(wù)處理單元上針對各種協(xié)議才艮文的限 速，從而控制各業(yè)務(wù)處理單元消息上送主控CPU的速率。對業(yè)務(wù)處理單元 CPU和主控CPU進行保護后，避免了因為消息的處理造成CPU的繁忙對其 它正常業(yè)務(wù)的影響。


圖1為分布式架構(gòu)的框架示意圖。
圖2為本發(fā)明系統(tǒng)實施例的組成示意圖。
圖3為本發(fā)明方法實施例的流程示意圖。
具體實施例方式
以下將結(jié)合附圖及實施例來詳細說明本發(fā)明的實施方式，借此對本發(fā)明 如何應(yīng)用技術(shù)手段來解決技術(shù)問題，并達成技術(shù)效果的實現(xiàn)過程能充分理解 并據(jù)以實施。
圖2示出了本發(fā)明基于內(nèi)部服務(wù)質(zhì)量(QOS)流控的消息保護系統(tǒng)一實 施例的組成意圖，該系統(tǒng)實施例包括轉(zhuǎn)發(fā)模塊210、協(xié)議分析模塊220、管 理模塊230、內(nèi)部QOS模塊240及協(xié)議處理^t塊250,其中
轉(zhuǎn)發(fā)才莫塊210，位于各業(yè)務(wù)處理單元上，用于接收并處理本業(yè)務(wù)處理單 元接收的報文。如果為能夠正常轉(zhuǎn)發(fā)的正確的報文，則查找轉(zhuǎn)發(fā)表、路由表 后根據(jù)查詢結(jié)果轉(zhuǎn)發(fā)，丟棄錯誤的報文；如果報文為廣播包、協(xié)議包，或者 報文的目的地址為設(shè)備本身，或者其它業(yè)務(wù)已經(jīng)標識需要上送CPU處理的待 處理報文，則先上送給業(yè)務(wù)處理單元CPU進行處理；如果業(yè)務(wù)處理單元CPU 不能處理則進一步上送給系統(tǒng)主控單元CPU進行處理(如SNMP);
協(xié)議分析模塊220，與轉(zhuǎn)發(fā)才莫塊210相連，用于對轉(zhuǎn)發(fā)模塊210上送的 待處理報文進行分析及預(yù)處理，分析該待處理報文的協(xié)議類型；如用戶數(shù)據(jù) 報協(xié)議(UDP)端口號為161或162的報文，發(fā)送給協(xié)議處理模塊250進行 SNMP協(xié)議的處理；協(xié)議分析模塊220主要工作在各個業(yè)務(wù)處理單元上；
管理模塊230，與內(nèi)部QOS模塊240相連，主要用于對系統(tǒng)主控單元CPU 和緩存進行監(jiān)控管理，以便系統(tǒng)實時掌握系統(tǒng)主控單元CPU和緩存的利用率， 根據(jù)系統(tǒng)終端單元CPU和緩存的利用率，輔助內(nèi)部QOS模塊240完成對報 文的QOS限速處理；
內(nèi)部QOS模塊240，工作在各個業(yè)務(wù)處理單元CPU到系統(tǒng)主控單元CPU 之間，與協(xié)議分析模塊220及管理模塊230相連，主要用于根據(jù)管理模塊230 獲取的系統(tǒng)主控單元CPU和緩存的利用率，對需要上送給系統(tǒng)主控單元CPU 的報文進行QOS限速處理；在分布式架構(gòu)中，協(xié)議分析才莫塊220完成對報文 的分析后，如果是業(yè)務(wù)處理單元不能處理的協(xié)議報文，則需要進一步上送系 統(tǒng)主控單元CPU處理，通過該QOS模塊230的限速作用，限制了從業(yè)務(wù)處 理單元CPU上送到系統(tǒng)主控單元CPU報文的速率；協(xié)議處理模塊250，與內(nèi)部QOS模塊240相連，首先對報文進行正確性 檢查及版本匹配，對于正確的待處理報文則進行相應(yīng)處理，如果需要進行響 應(yīng)，則產(chǎn)生相應(yīng)響應(yīng)發(fā)送給發(fā)送請求的設(shè)備，比如對于SNMP報文，完成 SNMP agent的任務(wù)，在正確性檢查及版本匹配通過之后，根據(jù)SNMP manager 發(fā)送的SNMP請求(request)消息進行處理，并根據(jù)處理結(jié)果反饋SNMP響 應(yīng)(response)，通過轉(zhuǎn)發(fā)模塊210反饋給發(fā)送SNMP request消息的SNMP manager,或者主動向SNMP manager發(fā)送SNMP陷阱(trap )消息。
上述內(nèi)容雖然以SNMP協(xié)議報文為例對本發(fā)明的技術(shù)方案進行說明，但 是本發(fā)明并不局限于SNMP協(xié)議的待處理報文，其應(yīng)包括所有需要進行類似 處理的協(xié)議報文如NTP協(xié)議報文等等。
結(jié)合圖1和圖2,圖3示出了本發(fā)明方法一實施例的流程圖，該實施例 包括如下步驟
步驟310，業(yè)務(wù)處理單元120上的轉(zhuǎn)發(fā)模塊210從端口接收到報文之后， 對報文進行分析，如果為需要正常轉(zhuǎn)發(fā)的報文則查找轉(zhuǎn)發(fā)表、路由表，并根 據(jù)查找的轉(zhuǎn)發(fā)結(jié)果和路由結(jié)果進行轉(zhuǎn)發(fā)或丟棄，如果為需要進一步處理的報 文，如廣播包、協(xié)議包，或者報文的目的地址為設(shè)備本身，或者其它業(yè)務(wù)已 經(jīng)標識需要上送CPU處理的待處理報文，則經(jīng)由協(xié)議分析模塊220上送給業(yè) 務(wù)處理單元CPU進4于處理；
步驟320,協(xié)議分析模塊220接收轉(zhuǎn)發(fā)模塊210轉(zhuǎn)發(fā)的待處理報文后， 分析出待處理報文的協(xié)議類型，并根據(jù)預(yù)先定義好的處理方式對數(shù)據(jù)進行處 理(如以太網(wǎng)中可以4艮據(jù)目的MAC、 IP地址、源、目的端口號將不同的l艮文 發(fā)給不同的處理單元)；比如協(xié)議分析模塊220分析出轉(zhuǎn)發(fā)模塊210轉(zhuǎn)發(fā)的 為UDP報文，且端口號為161和162時，則轉(zhuǎn)發(fā)才莫塊210轉(zhuǎn)發(fā)的為SNMP協(xié) 議報文，需要經(jīng)內(nèi)部QOS模塊240上送給協(xié)議處理模塊250進行相應(yīng)的處理； 對于業(yè)務(wù)處理單元CPU不能處理的報文，需要系統(tǒng)主控單元CPU進行處理， 此部分報文經(jīng)由協(xié)議分析模塊220轉(zhuǎn)發(fā)給內(nèi)部QOS模塊240;
步驟330,內(nèi)部QOS模塊240利用QOS的約定訪問速率(Committed Access Rate,縮寫為CAR)原理對上送系統(tǒng)主控單元CPU的報文進行限速處理，可選用的一種限速方式比如根據(jù)CPU的性能及設(shè)備可能面對的突發(fā)業(yè)務(wù) 流對CPU占用綜合權(quán)衡后設(shè)置承諾訪問速率(Committed Information Rate, 縮寫為CIR)和順從突發(fā)量(或稱令牌桶大小)(Conformed burst size,縮寫 為CBS)的值，以SNMP協(xié)議報文為例，其操作方式為
步驟3a，設(shè)定一個CIR及CBS桶，并按CIR向CBS桶中放入令牌；同 時如果有SNMP協(xié)議報文經(jīng)過，則CBS桶中令牌相應(yīng)減少；具體每個報文對 應(yīng)多少令牌可以根據(jù)實際情況進行設(shè)置；
步驟3b，當CBS桶中還有令牌時，內(nèi)部QOS模塊240將SNMP協(xié)議報 文直接上送給系統(tǒng)主控單元CPU;
步驟3c，當CBS桶中沒有令牌時，內(nèi)部QOS模塊240調(diào)用管理模塊230 檢查當前系統(tǒng)主控單元CPU的利用率，當系統(tǒng)主控單元CPU的利用率較小 (小于某個預(yù)設(shè)的閥值M)時，內(nèi)部QOS模塊240可以通過向CBS桶中一 次性注入一定數(shù)量(T)的令牌，以保證SNMP協(xié)議包的正常上送，如果當 前系統(tǒng)主控單元CPU的利用率較高(大于等于閾值M),則調(diào)用管理才莫塊 230查看當前系統(tǒng)主控單元的緩存，如果還有足夠的緩存，則內(nèi)部QOS模塊 240將SNMP協(xié)議包緩存起來，等待CBS桶中有令牌時再上送給系統(tǒng)主控單 元CPU處理，如果系統(tǒng)主控單元緩存不足，則內(nèi)部QOS模塊240丟棄協(xié)議 報文；
步驟340，協(xié)議處理模塊250接收到內(nèi)部QOS模塊240轉(zhuǎn)發(fā)的待處理報 文后，對該報文進行合法性檢查，如果檢查失敗則直接丟棄報文，如果合法 性檢查通過，則根據(jù)待處理報文的協(xié)議類型對待處理報文進行處理，如果需 要則根據(jù)處理結(jié)果產(chǎn)生一個相應(yīng)的響應(yīng)(response),通過調(diào)用轉(zhuǎn)發(fā)i^莫塊210 發(fā)送給相應(yīng)請求(request)的服務(wù)器。
本發(fā)明針對分布式架構(gòu)系統(tǒng)，在各個業(yè)務(wù)處理單元和主控之間設(shè)置QOS 限速，緩解了多個業(yè)務(wù)處理單元同時上送給主控出現(xiàn)主控CPU繁忙從而影響 一些其它重要業(yè)務(wù)。本發(fā)明以SNMP為例，但并不局限于SNMP協(xié)議消息， 所有分布式系統(tǒng)中需要從業(yè)務(wù)處理單元上送主控的其它協(xié)議消息的限速處 理，都在前述本發(fā)明的思想范圍內(nèi)。
雖然本發(fā)明所揭露的實施方式如上，但所述的內(nèi)容只是為了便于理解
發(fā)明而采用的實施方式，并非用以限定本發(fā)明。任何本發(fā)明所屬技術(shù)領(lǐng)域內(nèi) 的技術(shù)人員，在不脫離本發(fā)明所揭露的精神和范圍的前提下，可以在實施的 形式上及細節(jié)上作任何的修改與變化，^旦本發(fā)明的專利保護范圍，仍須以所 附的權(quán)利要求書所界定的范圍為準。
權(quán)利要求
1、一種分布式架構(gòu)數(shù)據(jù)通信設(shè)備的消息保護系統(tǒng)，其特征在于，包括轉(zhuǎn)發(fā)模塊、協(xié)議分析模塊、內(nèi)部服務(wù)質(zhì)量模塊、管理模塊及協(xié)議處理模塊，其中所述轉(zhuǎn)發(fā)模塊，位于所述分布式架構(gòu)數(shù)據(jù)通信設(shè)備的業(yè)務(wù)處理單元上，用于接收并上送需要CPU處理的待處理報文；所述協(xié)議分析模塊，與所述轉(zhuǎn)發(fā)模塊相連，用于對所述待處理報文進行協(xié)議分析，獲得所述待處理報文的協(xié)議類型；所述管理模塊，用于獲取所述系統(tǒng)主控單元CPU和緩存的利用率；所述內(nèi)部服務(wù)質(zhì)量模塊，與所述協(xié)議分析模塊及管理模塊相連，用于向所述協(xié)議處理模塊轉(zhuǎn)發(fā)所述待處理報文，并根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率，對所述待處理報文中需要系統(tǒng)主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理；及所述協(xié)議處理模塊，與所述內(nèi)部服務(wù)質(zhì)量模塊相連，用于根據(jù)所述待處理報文的協(xié)議類型，對所述待處理報文進行處理。
2、 如權(quán)利要求l所述的系統(tǒng)，其特征在于所述轉(zhuǎn)發(fā)^f莫塊，進一步與所述協(xié)議處理^^莫塊相連，用于反饋所述協(xié)議處 理模塊處理所述待處理凈艮文后的響應(yīng)。
3、 如權(quán)利要求l所述的系統(tǒng)，其特征在于所述內(nèi)部服務(wù)質(zhì)量模塊，根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率， 利用服務(wù)質(zhì)量的約定訪問速率原理，對所述需要系統(tǒng)主控單元CPU處理的報 文進行服務(wù)質(zhì)量限速處理。
4、 如權(quán)利要求2所述的系統(tǒng)，其特征在于所述內(nèi)部服務(wù)質(zhì)量模塊，根據(jù)所述系統(tǒng)主控單元CPU的性能及所述數(shù)據(jù) 通信設(shè)備可能面對的突發(fā)業(yè)務(wù)流對所述系統(tǒng)主控單元CPU占用綜合權(quán)衡后， 設(shè)置承諾訪問速率和順從突發(fā)量的值，根據(jù)所述承諾訪問速率和順從突發(fā)量 的值，對所述需要系統(tǒng)主控單元CPU進行處理的報文進行服務(wù)質(zhì)量限速處理。
5、 一種分布式架構(gòu)數(shù)據(jù)通信設(shè)備的消息保護方法，其特征在于，包括步驟分布式架構(gòu)數(shù)據(jù)通信設(shè)備的業(yè)務(wù)處理單元收到報文之后，分析出需要 CPU處理的待處理報文；對所述待處理報文進行協(xié)議分析，獲得所述待處理報文的協(xié)議類型；獲得所述分布式架構(gòu)數(shù)據(jù)通信設(shè)備的系統(tǒng)主控單元CPU和緩存的利用率；根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率，對所述待處理報文中需要 系統(tǒng)主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理；及根據(jù)所述待處理報文的協(xié)議類型，對所述待處理報文進行處理。
6、 如權(quán)利要求5所述的方法，其特征在于所述待處理報文，包括廣播包、協(xié)議包、目的地址為設(shè)備本身、或者已 經(jīng)標識需要上送的報文。
7、 如權(quán)利要求6所述的方法，其特征在于所述待處理報文包括簡單網(wǎng)絡(luò)管理協(xié)議才艮文或者網(wǎng)絡(luò)時間協(xié)"^i艮文。
8、 如權(quán)利要求5所述的方法，其特征在于根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率，利用服務(wù)質(zhì)量的約定訪問 速率原理,對所述需要系統(tǒng)主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理。
9、 如權(quán)利要求8所述的方法，其特征在于根據(jù)所述系統(tǒng)主控單元CPU的性能及所述數(shù)據(jù)通信設(shè)備可能面對的突 發(fā)業(yè)務(wù)流對所述系統(tǒng)主控單元CPU占用綜合權(quán)衡后，設(shè)置承諾訪問速率和順 從突發(fā)量的值，根椐所述承諾訪問速率和順從突發(fā)量的值，對所述需要系統(tǒng) 主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理。
10、 如權(quán)利要求5所述的方法，其特征在于，對所述待處理報文進行處 理時，進一步對所述待處理才艮文進行正確性檢查及版本匹配。
全文摘要
本發(fā)明公開了一種分布式架構(gòu)數(shù)據(jù)通信設(shè)備的消息保護系統(tǒng)及方法，以有效保護分布式架構(gòu)數(shù)據(jù)通信設(shè)備的CPU。該方法中，業(yè)務(wù)處理單元收到報文之后分析出需要CPU處理的待處理報文；對所述待處理報文進行協(xié)議分析，獲得所述待處理報文的協(xié)議類型；獲得系統(tǒng)主控單元CPU和緩存的利用率；根據(jù)所述系統(tǒng)主控單元CPU和緩存的利用率，對所述待處理報文中需要系統(tǒng)主控單元CPU處理的報文進行服務(wù)質(zhì)量限速處理；根據(jù)所述待處理報文的協(xié)議類型，對所述待處理報文進行處理。本發(fā)明控制各業(yè)務(wù)處理單元消息上送主控CPU的速率，避免了因為消息的處理造成CPU的繁忙對其它正常業(yè)務(wù)的影響。
文檔編號H04L12/56GK101355585SQ20081021058
公開日2009年1月28日 申請日期2008年9月2日 優(yōu)先權(quán)日2008年9月2日
發(fā)明者劉宗穎 申請人:中興通訊股份有限公司