專利名稱：利用周期重復(fù)序列壓縮通過udp傳輸snmp消息的方法和裝置的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及使用UDP(用戶數(shù)據(jù)報協(xié)議的簡稱)傳輸消息的方法，例如傳輸 SNMP (簡單網(wǎng)絡(luò)管理協(xié)議)消息。這些消息是在數(shù)據(jù)通信網(wǎng)絡(luò)，例如互聯(lián)網(wǎng)中產(chǎn)生并傳輸?shù)摹；ヂ?lián)網(wǎng)協(xié)議的結(jié)構(gòu)基 于四個邏輯層，即應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和連接層。SNMP消息在網(wǎng)絡(luò)管理系統(tǒng)(匪S)和被管理的節(jié)點(diǎn)之間執(zhí)行一種簡單的通信機(jī)制。 這使得分別位于稱作“網(wǎng)絡(luò)管理器”的匪S上的以及位于稱作“代理”的節(jié)點(diǎn)上的特定應(yīng)用 成為可能。因此SNMP消息能在UDP級上發(fā)生，并為該目的使用UDP來傳輸。
背景技術(shù)：
對SNMP消息具有獨(dú)立的網(wǎng)絡(luò)管理器的稱作“代理”的應(yīng)用(以下均為代理)和 當(dāng)前稱作“管理信息庫”或簡稱為MIB的數(shù)據(jù)庫相結(jié)合。在這個數(shù)據(jù)庫中，根據(jù)相應(yīng)節(jié)點(diǎn)或 網(wǎng)絡(luò)單元的管理和監(jiān)控，進(jìn)行相應(yīng)的信息收集。這種信息特別包括下列部分一MIB變量，可由網(wǎng)絡(luò)管理器讀取，并獲得關(guān)于網(wǎng)絡(luò)單元的信息；一可由網(wǎng)絡(luò)管理器寫入的MIB變量，能引起網(wǎng)絡(luò)單元上的動作；以及一同一代理根據(jù)特定的情況對網(wǎng)絡(luò)管理器(管理器)引起的事件(陷阱)。因此SNMP級上的通信主要包括一請求讀 / 寫上述變量的消息(GetRequest，GetNextRequest, SetRequest, GetBulk)，由網(wǎng)絡(luò)管理器發(fā)送出去，以及一響應(yīng)消息(GetResponse)和陷阱消息，由代理發(fā)送。一個代理管理的所有變量/陷阱的集合與網(wǎng)絡(luò)單元有關(guān)，并明確地表示了相應(yīng)的 MIB，即它們能向網(wǎng)絡(luò)管理器展示網(wǎng)絡(luò)單元的操作模式和固有特性。每個變量或陷阱分別由ASN. 1表示法(第一抽象語法表示法)中的一個字符串進(jìn) 行標(biāo)識，稱作對象標(biāo)識符或0ID。該字符串的框架結(jié)構(gòu)表明ASN. 1表示法根據(jù)等級樹結(jié)構(gòu)允許對對象進(jìn)行描述，例 如 “1. 3. 6. 1. 2. 1. 4. 21” 類型。MIB的一部分定義為一個標(biāo)準(zhǔn)，支持任何代理，但是其他變量和一些陷阱對每個制 造商都是特定的，在一些情況下還成為特定裝置類型的獨(dú)有特征。1988年誕生的SNMP協(xié)議這些年來經(jīng)過了幾次發(fā)展。特別是定義了代理必須能夠 理解的新的消息類型。每個代理必須支持的MIB標(biāo)準(zhǔn)也被擴(kuò)充了。在本發(fā)明的申請日，使 用的版本是第一版和第二版，而第三版標(biāo)準(zhǔn)正在進(jìn)行中。MIB的大小根據(jù)裝置類型而不同，對于相應(yīng)的幾百個0ID，甚至可達(dá)到幾百K字節(jié)
3大小。附圖的圖1中的示意圖顯示了一個SNMP消息的典型組成部分。每個組成部分的 內(nèi)容是用ASCII字符寫成，且它的最大允許尺寸和UDP消息的最大尺寸是相等的，數(shù)據(jù)體傳 送消息的組成部分，等于65，507字節(jié)或八位位組(需傳送的信息被設(shè)計(jì)為大約64K字節(jié))。在圖1中的同一個示意圖中，特別要注意到存在一個消息頭和一個PDU(協(xié)議數(shù)據(jù) 單元)部分，其中數(shù)字1表示的部分收集如GetRequest，GetNextRequest，SetRequest以及 GetResponse等消息，數(shù)字2表示的部分收集GetBulk消息，而數(shù)字3表示的部分一般涉及 到陷阱類型消息。更特別的是，在SNMP消息頭中有下列信息一版本號用于消息合成的SNMP版本號(VI，V2, V3，...)以及一共用名稱一種密碼，能允許對MIB模塊中包含的對象通過讀和寫進(jìn)行訪問。下列信息是PDU內(nèi)可用的—PDU類型消息類型，在版本1中包括的指令例如為GetRequest， GetNextRequest, SetRequest以及Request，而在版本2還可包含的指令例如為 GetBulkRequest 禾口 InformRequest ；一請求標(biāo)識符管理器分配的消息的個人標(biāo)識符，并在應(yīng)答時被代理使用，目的在 于管理器能夠把請求的響應(yīng)和適當(dāng)?shù)膮⒖蓟鶞?zhǔn)結(jié)合起來；一錯誤狀態(tài)除了響應(yīng)消息之外所有的消息類型都設(shè)成0，其中如果設(shè)成1，意味
著存在錯誤；—錯誤索引它能夠指示出被請求的變量(0ID)中發(fā)生錯誤的變量，以及一變量結(jié)這些變量結(jié)是0ID/數(shù)值對；在請求的情況下數(shù)值為“空”，在消息響應(yīng) 的情況下進(jìn)行編譯。圖1中左邊部分特別顯示了收集上述變量結(jié)部分的典型結(jié)構(gòu)。本發(fā)明中以及一些附圖的標(biāo)題中，對于需考慮的不同元件，可根據(jù)英語中提及的 相應(yīng)的首字母縮寫/名稱/首字母來進(jìn)行選擇。這樣做的目的是為了得到清晰和直觀的描述。上述首字母縮寫詞、名稱和首字母 現(xiàn)在被本領(lǐng)域技術(shù)人員在國際間運(yùn)用，因?yàn)檫@些年來沒有開發(fā)翻譯成不同國家的語言。通過UDP可能實(shí)現(xiàn)的SNMP消息的傳送，允許在連接到網(wǎng)絡(luò)上的兩臺計(jì)算機(jī)之間進(jìn) 行數(shù)據(jù)包的交換。UDP消息格式即包含了一個消息頭，它的主要數(shù)據(jù)是發(fā)送消息的計(jì)算機(jī)的 IP地址、目標(biāo)計(jì)算機(jī)的IP地址以及被傳送的PDU的大小。接下來，PDU格式由一個頭部分 和一個數(shù)據(jù)部分構(gòu)成，現(xiàn)在稱為“有效載荷”或“八位數(shù)據(jù)”。因此消息頭包含下列數(shù)據(jù)源 端口、目標(biāo)端口、傳送單元的大小、數(shù)據(jù)單元的完整性檢驗(yàn)(CHECKSUM)?，F(xiàn)在通過UDP (從管理器至代理，以及相反路徑)傳送SNMP消息采用的方法實(shí)質(zhì) 上是基于整個SNMP消息是使用BER(基本編碼規(guī)則)方法進(jìn)行編碼的事實(shí)。這種操作方法 能夠把構(gòu)成SNMP消息的字節(jié)轉(zhuǎn)換成UDP消息的有效載荷適用的十六進(jìn)制結(jié)構(gòu)。這樣獲得的數(shù)據(jù)UDP傳送服務(wù)基本上設(shè)想為一在發(fā)送階段為了通過UDP發(fā)送消息，先讀取SNMP消息，隨后對該消息進(jìn)行十六 進(jìn)制編碼(BER編碼)，以及一在接收階段通過UDP接收消息之后，對PDU進(jìn)行十六進(jìn)制解碼(BER解碼)，隨
4后對消息進(jìn)行重建。目前的應(yīng)用實(shí)踐證明了在數(shù)據(jù)通信網(wǎng)絡(luò)如互聯(lián)網(wǎng)中產(chǎn)生了這樣的需求即要以 SNMP消息的格式傳送大量的請求/響應(yīng)信息。由于信息的總體大小決定了相應(yīng)的傳輸和網(wǎng)絡(luò)業(yè)務(wù)量所需的時間，以標(biāo)準(zhǔn)格式傳 輸SNMP消息的常規(guī)解決方案一般效率相當(dāng)?shù)汀Ｒ驗(yàn)檫@個原因已經(jīng)提出了三個IEFT標(biāo)準(zhǔn)(處在草案階段)來解決該難點(diǎn)。第一個建議(稱為SNMP對象標(biāo)識符壓縮，2001年4月修訂版，draft-ietf-eos-oidcompression-00. txt)基于的概念是MIB中包含的大部分信息通過0ID來索引，相當(dāng)大 部分是常數(shù)格式，而很小部分是變量格式。根據(jù)這個原則出發(fā)，該建議的目標(biāo)是根據(jù)一種算 法通過一個較短的編號方式對0ID的常數(shù)部分進(jìn)行編碼。這種方案只能部分地優(yōu)化需傳送 的信息量，而沒有大量減少信息的大小。第二個建議(稱為“大量SNMP數(shù)據(jù)的有效傳輸，2001年4月修訂版， draft-ietf-eos-snmpbulk-00. txt”)面對的問題是GetBulk指令管理可允許對給定信息 集的同步收集。SNMP版本2中引入的指令不能優(yōu)化信息收集，因?yàn)楣芾砥鞅仨毬暶魉枋?集的單元數(shù)量，而不知道被請求的信息集由多少單元構(gòu)成。UDP協(xié)議的修正曾建議改進(jìn)消 息的編碼算法(從BER改為PER，它支持分組編碼規(guī)則)或采取FTP (文件傳輸協(xié)議的首字 母縮寫)類型的傳送模式。上面引用的文件中描述的方案在代理端引入了新的指令，叫做 GetColsRequest，還在管理器端引入了相關(guān)消息，能夠識別需傳送的單元的數(shù)量，能識別出 被請求的信息集的結(jié)束，從而優(yōu)化了請求和網(wǎng)絡(luò)業(yè)務(wù)量。但是，這個方案也不能優(yōu)化對需發(fā) 送的消息的大小和數(shù)量的管理。第三個考慮的方案(稱為“SNMP有效荷載壓縮，2001年4月修訂版，draft-irtf -nmrg-snmp-compression-01. txt”)在原理上和第一個建議相似，因?yàn)樗岢隽艘环N差分 編碼算法，叫做“0ID Delta Compression”或簡稱為0DC。這種方案從一個0ID根出發(fā)，設(shè) 想能夠存儲隨后的0ID，并把和0ID根相關(guān)的代碼分配給該0ID，隨后是0ID的變化的部分。 實(shí)質(zhì)上，這些變化以與根單元相比較的差分增量形式被存儲起來。該方案的缺點(diǎn)是和以前 的協(xié)議版本不兼容。另外，它特別對求遞歸0ID值(即數(shù)據(jù)陣列)時估計(jì)能夠節(jié)省30%，而 它在遞歸項(xiàng)數(shù)目很少的情況下效率是很低的。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種和以前實(shí)行的解決方案相比的另一種可選擇的替代方 案，且能夠通過UDP對如SNMP的消息進(jìn)行優(yōu)化傳輸，而不會影響協(xié)議以及代理端和管理器 端的執(zhí)行性能。根據(jù)本發(fā)明，實(shí)現(xiàn)這個目的的方法具有權(quán)利要求中特定的技術(shù)特征。本發(fā)明還以 獨(dú)立的方式，涉及到相關(guān)系統(tǒng)和數(shù)據(jù)處理產(chǎn)品，當(dāng)上述數(shù)據(jù)處理產(chǎn)品在計(jì)算機(jī)上運(yùn)行時，能 夠直接載入到計(jì)算機(jī)的內(nèi)部存儲器中，并包括執(zhí)行本發(fā)明所述方法的軟件代碼部分。本質(zhì)上，本發(fā)明的方案是基于整個消息(消息頭和PDU)的壓縮。特別能夠預(yù)見兩種不同的傳送模式。第一個模式把SNMP消息封裝成一種新的特 有類型的SNMP消息，并使用UDP以一種標(biāo)準(zhǔn)模式發(fā)送該消息。第二個模式直接通過驅(qū)動器來驅(qū)動UDP，得到的結(jié)果是把SNMP消息壓縮為八位數(shù)據(jù)。所述壓縮技術(shù)實(shí)質(zhì)上基于對消息中周期性出現(xiàn)的序列進(jìn)行識別。特別地，在本發(fā)明的優(yōu)選實(shí)施例中，使用的壓縮技術(shù)是已知的LZ77技術(shù)的 ^ ( JAL Ziv. J. , Lempel A.白勺胃 # “A Universal Algorithm forSequential Data Compression，，，IEEE Transactions on InformationTheory, Vol. 23, No. 3, PP. 337-343), 在UNIX環(huán)境中是很有名的，叫做gzip(gzip格式一RFC 1952)，也被更流行的PKZIP所使 用。這種技術(shù)規(guī)范是眾所周知的，同時還可使用源庫，用于不同的開發(fā)環(huán)境和操作系統(tǒng)來執(zhí) 行和使用這個方案，如 HP-UX，Digital, Beos, Linux, OS/2, Java, Win32, WinCE。特別在Win32上可通過使用“zLib”庫來使用該算法的接口。作為參考，可以參見 站點(diǎn)httD://www. info-zip. org/pub/infozip/zlib/0這個庫的主要特征是可以對二進(jìn)制 數(shù)據(jù)結(jié)構(gòu)和字符串進(jìn)行實(shí)時和聯(lián)機(jī)存儲器壓縮，這成為和系統(tǒng)性能相關(guān)的一個重要因素。


現(xiàn)在通過一個不受限的實(shí)例，參照附圖對本發(fā)明進(jìn)行描述，其中一圖1和背景技術(shù)有關(guān)，前面已作了描述；一圖2是根據(jù)本發(fā)明的方案的一個典型應(yīng)用結(jié)構(gòu)的一般結(jié)構(gòu)框圖的形式；一圖3至圖5，每個圖再分成兩部分，分別是發(fā)送(a部分)和接收(b部分)，以流 程圖的形式闡釋了本發(fā)明的方案的不同類型的實(shí)施例；一圖6是一個補(bǔ)充的流程圖，闡釋了本發(fā)明的方案的一般特性；以及一圖7和圖8根據(jù)基本上類似于圖1中采用的特征，通過兩種可行的變型，描述了 本發(fā)明的方案的實(shí)施例標(biāo)準(zhǔn)。
具體實(shí)施例方式圖2的一般框圖中，符號N表示了根據(jù)本發(fā)明的方案的一個規(guī)定了典型應(yīng)用環(huán)境 的數(shù)據(jù)通信網(wǎng)絡(luò)(可以考慮互聯(lián)網(wǎng)作為一個直接的例子)。符號A表示了現(xiàn)在稱作“代理”的模塊，它實(shí)現(xiàn)的功能是對網(wǎng)絡(luò)N的相應(yīng)單元進(jìn)行 控制和監(jiān)視，并與相應(yīng)的管理器M以一種雙向?qū)υ捘Ｊ竭M(jìn)行操作。后者和一個更高等級水平上的附加代理A’ 一起確定了一個端口或網(wǎng)關(guān)G，它隨即 和另一個更高等級水平上的附加管理器M’相對接。后者和一個相應(yīng)應(yīng)用一起確定了一個觀測模塊或觀測器0。符號C1和C2表示兩個雙向通信信道，一個信道在代理A和網(wǎng)關(guān)G之間在較低等 級水平上執(zhí)行通信，另一個信道在網(wǎng)關(guān)G和觀測器0之間在較高等級水平上執(zhí)行通信。在上面提到的信道CI、C2上進(jìn)行SNMP消息傳輸。圖3中的流程圖描述了 SNMP消息壓縮(圖3a)和解壓縮(圖3b)的特征。圖4中的流程圖(仍然參照圖4a中的發(fā)送和圖4b中的接收)闡釋了第一個方案， 其中設(shè)想通過對SNMP進(jìn)行封裝，然后發(fā)送壓縮后的SNMP消息。圖5中的流程圖是另一種通過UDP封裝的傳輸方案。這個圖仍然參照發(fā)傳(圖 5a)和接收(圖5b)。圖7和圖8中的結(jié)構(gòu)圖描述了和圖1中相同格式的0ID表示形式，并且參照壓縮和傳輸操作集，分別舉例說明圖3和4(圖7)中的a)部分以及圖3和5(圖8)中的a)部 分。首先來看圖3中的流程圖，在符號100表示的步驟中，整個SNMP消息(消息頭 +PDU)被讀出，用于在隨后由102表示的步驟中轉(zhuǎn)換或編碼成十六進(jìn)制格式。這是采用一種 BER編碼類型的代碼來實(shí)現(xiàn)的。這樣編碼后的消息再通過一種基于對遞歸序列進(jìn)行識別的壓縮技術(shù)進(jìn)行壓縮，例 如前面已經(jīng)提及的zLib庫中提到的技術(shù)。這是在104表示的步驟中發(fā)生的，目的是在106表示的步驟中獲得準(zhǔn)備用于發(fā)送 的壓縮后的數(shù)據(jù)單元。以一種完全對稱的方式，圖3的b部分的流程圖也包括四個步驟，即206，204，202 和200 (根據(jù)示出的順序來執(zhí)行)，其中接收到的壓縮數(shù)據(jù)單元(步驟206)被解壓縮(步驟 204)，隨后進(jìn)行十六進(jìn)制解碼(步驟202)，其后對整個SNMP消息進(jìn)行重建(步驟200)。圖3中b部分的流程圖的數(shù)字符號順序和它們的執(zhí)行順序是相反的，這樣做的唯 一目的是強(qiáng)調(diào)這個過程和步驟100到106的壓縮過程的對稱性。圖4和圖5的流程圖中也 選擇了同樣的方式。如圖所示，圖4和圖7涉及到一種發(fā)送方案，設(shè)想將壓縮后的數(shù)據(jù)單元封裝成一個 標(biāo)準(zhǔn)SNMP消息，其特征在于專有的或特殊的“變量結(jié)”，以及通過UDP的標(biāo)準(zhǔn)發(fā)送性質(zhì)。壓縮數(shù)據(jù)單元的封裝形式在步驟106處獲得，還包括一個用108表示的初始化步 驟，在該步驟中壓縮后的數(shù)據(jù)單元按字節(jié)讀出，然后再隨后用110表示的編碼步驟中轉(zhuǎn)換 成相應(yīng)的ASCII字符集。在下面一個步驟112中(可能在此之前加上輔助功能，例如ACKTAB+NULL-見圖 7中模塊110a)，第一個0ID和專有的或特殊的編號方式(例如1. 3. 6. 1. 4. 666. 1)構(gòu)成的 消息生成了“變量結(jié)”，其包含的數(shù)值是字符串_zip_XXXX，其中XXXX表示原文件的大小。 上面引用的例子中，特定代碼666. 1表示此時還沒有在IANA(Internet AssignedNumbers Authority)注冊，但其他任何沒有注冊過的代碼都可以使用。其后適時地轉(zhuǎn)換成ASCII字符的包含有壓縮數(shù)據(jù)單元的變量結(jié)單元由0ID/數(shù)值 對構(gòu)成。其數(shù)值包括壓縮數(shù)據(jù)單元轉(zhuǎn)換成ASCII字符的部分，最大為255個字符。然后SNMP消息的消息頭進(jìn)行重建。這都發(fā)生在步驟112中，其后是步驟114，執(zhí)行 一個根據(jù)BER方法的額外的編碼，用于生成數(shù)據(jù)發(fā)送(步驟116)中所需的UDP消息的PDU 載荷(PDU-UDP的有效載荷)。還是在這種情況下，圖4的b)部分中重復(fù)出現(xiàn)的步驟216，214，212，210和208被 設(shè)計(jì)為根據(jù)前面所引用的順序來執(zhí)行，這些步驟表示出接收端實(shí)現(xiàn)的涉及到發(fā)送操作的步 驟108到116的雙重功能。采用圖4和圖7中提及的方案，壓縮后的SNMP消息具有一個標(biāo)準(zhǔn)的邏輯SNMP格 式，但是內(nèi)容是專有的或特殊的。因此，它需要代理管理器的功能擴(kuò)充，盡管很小，從而能夠 進(jìn)識別和編碼/解碼。申請人:進(jìn)行的實(shí)驗(yàn)證明這種方案是完全可行的，不會影響網(wǎng)絡(luò)結(jié)構(gòu)。圖5和圖8提到的另一種方案，設(shè)想根據(jù)圖3所示的性質(zhì)，準(zhǔn)備來自SNMP消息的 壓縮數(shù)據(jù)單元，然后把上述數(shù)據(jù)單元直接封裝PDU-UDP的有效載荷中。
7
很明顯對于正確的操作，這個方案需要使用專用的發(fā)送器和接收器，例如前提條 件是要確保UDP端口的可用性和標(biāo)準(zhǔn)端口不同。因此發(fā)送器必須能識別接收器使用的UDP 端口，反過來也是一樣。使用的端口信息可根據(jù)下文中將要詳細(xì)解釋的標(biāo)準(zhǔn)，通過一種標(biāo)準(zhǔn) SNMP格式的同步消息在更高層上進(jìn)行交換。采用圖5和圖8中描述的另一個替代方案時，在步驟108處得到的用于替代消息 的BER的壓縮數(shù)據(jù)單元成為PDU-UDP消息的有效載荷。圖5和圖8中相關(guān)的操作用標(biāo)號為118、120的步驟表示，上述步驟在發(fā)送步驟122 之前，用于接收器的各個專用端口( 一般稱作端口 X)。還是在這種情況下，其余操作包括三個步驟，分別是222 (該時刻用作接收器的模 塊的端口 Y的接收)、220 (PDU-UDP有效載荷的提取)、218 (接收到壓縮數(shù)據(jù)單元，用于傳送 至圖3中b)部分流程圖的步驟206處)。同樣在這種情況下，步驟222、220、218按照上面已經(jīng)提及的順序來執(zhí)行。前面提到的同步消息由管理器按照“應(yīng)用到應(yīng)用”的基本原則發(fā)至SNMP代理，使 用了含有專用或特殊的“變量結(jié)”的標(biāo)準(zhǔn)SNMP格式。被傳送的信息可能的類型為0ID數(shù)值 管理器向SNMP管理器發(fā)送一個專用消息，把用于UDP傳輸?shù)亩丝谔?例如1024) 編譯成<UDP_TX_P0RT>值，并且把用于UDP接收的端口號(例如1224)編譯成<UDPR_X_ PORT〉值。代理向管理器答復(fù)一個類似的包含自身信息的消息。這種方法增加了技術(shù)方案的 效率，從而減少了處理時間。圖6中的框圖還顯示了對上面描述的方案的推廣，以適用于任何使用UDP作為傳 輸端口的消息類型(例如SNMP、PING等等)。這種推廣使得能夠?qū)崿F(xiàn)一種取代目前正在使 用的UDP驅(qū)動器。這種方案能夠估計(jì)要傳送的有效載荷的大小，并使用此處提到的方法進(jìn)一步處理 (假定大小是足夠大的(例如大于20字節(jié)))。為了表明發(fā)送至接收端的UDP消息的簡潔 性，例如一或多個比特時，可以把UDP消息頭中(目前這些比特沒有使用，缺省設(shè)置為0)第 62個比特到第69個比特之間的8個比特置為1。特別是圖6的框圖中，符號300表示出現(xiàn)發(fā)送能夠通過UDP傳輸?shù)南⒌男枨蟮?任何步驟，隨后是對有效載荷進(jìn)行壓縮的步驟302，根據(jù)圖3中描述的特性來實(shí)現(xiàn)。接下來的步驟304中設(shè)想了根據(jù)上面提到的原則生成UDP消息頭，同時下面的步 驟306對應(yīng)了整個UDP消息的創(chuàng)建，考慮了 IP傳輸，在步驟308中實(shí)現(xiàn)。提及的方法能夠?qū)崿F(xiàn)一種一般用途的解決方案，能夠支持任何一種使用UDP-IP 協(xié)議棧的應(yīng)用類型。上述方案特別適用于硬件實(shí)現(xiàn)或“on-chip ”方案。上述方案的一個功能性延伸能夠獨(dú)立于用于數(shù)據(jù)傳輸?shù)姆椒▉韺?shí)現(xiàn)，以及消息的
8編碼或等效的BER或八位數(shù)據(jù)UDP。對此考慮采用了一種安全有效的方法，現(xiàn)在稱為“block cipher Ri jndael ”，也叫做 “AES，，。這里描述的方案的優(yōu)點(diǎn)在于允許對SNMP消息進(jìn)行壓縮，以一種組合的方式，既參 考了一種靈活的壓縮技術(shù)，又參考了其他壓縮技術(shù)(如MPEG)克服了說明書中提到的缺點(diǎn)。 這種技術(shù)及其算法可在多個操作系統(tǒng)下使用，使該方案成為一個可以再次使用和重復(fù)實(shí)現(xiàn) 的方案。另外，上述方案對管理器和代理端的影響都是最小的，因?yàn)樗枰⑾嚎s和 解壓縮的一個簡單的上層結(jié)構(gòu)。該方案證明是高效率的，因?yàn)樗軌驅(qū)W(wǎng)絡(luò)業(yè)務(wù)量進(jìn)行優(yōu)化，時間間隔相等時，能 夠通過較小的消息數(shù)量來傳送相同數(shù)量或更大量的信息。它也是個安全的解決方案，因?yàn)?信息被壓縮和編碼之后，在網(wǎng)絡(luò)中以明文進(jìn)行傳輸。顯然，在本發(fā)明的原理不改變的情況下，考慮到此處描述和闡釋的方面，具體實(shí)施 方式以及實(shí)施例可能會不同，這并沒有偏離權(quán)利要求所限定的本發(fā)明的主旨和范圍。
權(quán)利要求
傳輸用戶數(shù)據(jù)報協(xié)議(UDP)消息的方法，包括對來自第一UDP消息的數(shù)據(jù)單元進(jìn)行壓縮；將壓縮后的數(shù)據(jù)單元配置為第二UDP消息的協(xié)議數(shù)據(jù)單元有效載荷；并且根據(jù)UDP發(fā)送第二UDP消息，其中第二UDP消息包括對壓縮的指示。
2.如權(quán)利要求1中所述的方法，其中所述壓縮是gzip壓縮。
3.如權(quán)利要求1中所述的方法，還包括使用第二UDP消息的UDP包頭的一個比特字段 來指示壓縮步驟的執(zhí)行。
4.如權(quán)利要求3中所述的方法，其中來自第二UDP消息的UDP包頭的比特62到比特 69的比特被用作指示壓縮步驟的執(zhí)行的比特字段。
5.如權(quán)利要求3中所述的方法，還包括將第二UDP消息的UDP包頭的一個壓縮指示比 特設(shè)置為值1，其中該壓縮指示比特是來自UDP包頭的比特62至比特69的比特之一。
6.如權(quán)利要求1中所述的方法，還包括將第二UDP消息從發(fā)送器的所識別的發(fā)送端口 發(fā)送到接收器的所識別的接收端口。
7.如權(quán)利要求6中所述的方法，還包括在所述接收端口處接收所述第二UDP消息； 從所述第二 UDP消息提取所述協(xié)議數(shù)據(jù)單元有效載荷；以及對所述協(xié)議數(shù)據(jù)單元有效載荷進(jìn)行解壓，以得到原始消息的數(shù)據(jù)單元。
全文摘要
本發(fā)明涉及使用UDP傳輸來傳送信息。一個典型的例子是SNMP消息，用于在管理數(shù)據(jù)通信網(wǎng)絡(luò)，如互聯(lián)網(wǎng)的系統(tǒng)內(nèi)的管理器單元(M，M’)和代理單元(A，A’)之間進(jìn)行通信(C1，C2)。消息的有效荷載，最好是作為一個整體的消息，基于在消息中周期性出現(xiàn)的序列的識別，進(jìn)行壓縮操作。
文檔編號H04L29/06GK101854252SQ20101013438
公開日2010年10月6日 申請日期2002年8月9日 優(yōu)先權(quán)日2001年8月13日
發(fā)明者毛利茲奧·齊拉迪 申請人:意大利電信股份公司