一種簡單網絡管理協議消息傳送方法及裝置的製作方法
2023-05-30 03:32:36
專利名稱：一種簡單網絡管理協議消息傳送方法及裝置的製作方法
技術領域：
本發明涉及通信領域，具體地講涉及到一種簡單網絡管理協議消息傳送方法及裝置。
背景技術：
簡單網絡管理協議(Simple Network Management Protocol，SNMP)是由網際網路工程任務組(Internet Engineering Task Force，IETF)制訂的一套網絡管理協議。根據SNMP協議，一個管理工作站可以遠程管理所有支持這種協議的網絡設備，包括監視網絡狀態、修改網絡設備配置、接收網絡事件警告等。
SNMP採用了客戶端/伺服器端模型的特殊形式代理/管理站模型。對網絡的管理與維護是通過SNMP管理站與SNMP代理間的交互工作完成的。每個SNMP代理負責應答SNMP管理站對管理信息庫(Management InformationBase，MIB)所定義信息的各種查詢。
SNMP代理和SNMP管理站通過SNMP協議中的標準消息進行通信，每個消息都是一個單獨的數據報，SNMP採用用戶數據報協議(User DatagramProtocol，UDP)作為傳輸協議。
在實際應用中，SNMP管理站通過獲取請求消息Get-Request消息從具有SNMP代理功能的網絡設備中檢索信息，SNMP代理採用獲取響應消息Get-Response消息響應，獲取下一個請求消息Get-Next-Request和Get-Request組合使用可以用於查詢特定的表對象中的元素，SNMP管理站採用設置請求消息Set-Request來對具有SNMP代理功能的網絡設備進行遠程配置，例如配置設備名、設置設備屬性、添加或刪除設備等。
而當SNMP代理需要向SNMP管理站發送網絡狀況消息和告警消息等非請求消息時，則採用陷阱Trap消息來向SNMP管理站發送這些消息。Trap通知方式為不可靠傳輸，接收者在收到一條Trap通知後無需回復任何確認信息，所以發送者無法知道Trap通知是否已經被正確接收。
在實際應用中，SNMP協議通常使用在上下級電信網管之間，上級網管系統是管理站，下級網管系統是SNMP代理，用來實現上下級網管系統之間的消息的傳送。由於這種協議基於UDP協議傳輸，而UDP協議是一種不可靠的傳輸協議，它不提供數據傳送的保證機制，也即如果在從發送方到接收方的傳遞過程中出現數據報的丟失，協議本身並不能做出任何檢測或提示；另外，Trap消息也不對所接收的消息回復確認。所以當下級網管系統向上級網管系統採用SNMP發送trap消息的時候，就會出現因上下級網管系統通訊異常、網絡擁擠或上下級網管系統本身異常等故障導致消息丟失而上下級網管系統無法檢測到的情況，最終造成傳送的數據包丟失等問題。
為了解決這個問題，現有技術主要採用了以下兩種方法第一種方法是管理站採用SNMP Get-Request消息定時輪詢的方式。SNMP代理髮送trap消息給管理站，當管理站和SNMP代理之間的通信出現故障時，所發送的trap消息沒有按預期到達管理站，管理站主動地定時向SNMP代理髮送Get-Request消息定時輪詢SNMP代理所發送的trap消息，從而來解決消息丟失的問題。
第二種方法是管理站採用SNMP Set-Request消息定時觸發SNMP代理重發消息的方式。SNMP代理髮送trap消息給管理站，當管理站和SNMP代理之間的通信出現故障時，所發送的trap消息沒有按預期到達管理站，管理站主動地向SNMP代理髮送Set-Request消息觸發SNMP代理重新發送trap消息，從而來解決消息丟失的問題。
但是，儘管上述兩種方法在一定程度上解決了消息丟失的問題，但還是存在著一些問題。根據上面所述的管理站的輪詢和重發請求，SNMP代理使用SNMP發送trap消息給管理站，由於trap消息無應答的特性和SNMP所採用的UDP傳輸協議的不可靠性，SNMP代理仍然無法確認管理站是否接收到消息，而管理站也無法得知SNMP代理是否已經發送了某個消息。因此，尤其是在管理站和SNMP代理通信中斷的情況下，SNMP代理向管理站發送了Trap消息後，管理站還認為SNMP代理還沒有發送消息，會向SNMP代理查詢或觸發SNMP代理重發丟失的消息，當SNMP代理比較多時，會大大增加管理站複雜性和負荷；另外，SNMP代理也會因為不知道通信出現故障，會依舊發送消息，特別是當網絡擁擠的時候，影響了網絡的性能。
為了解決上述由於採用Trap方式發送消息的不可靠性所產生了問題，現有技術又採用了一種Inform-Request的方式來傳送消息。
Inform-Request方式也採用UDP的傳輸協議，但與trap方式不同的是Inform-Request方式有響應機制，當SNMP代理向管理站通過Inform-Request方式發送一條消息後，如果管理站正確地接收到這條消息，就向SNMP代理回復一條確認信息，如果管理站沒有接收到這條消息，經過一段時間後，SNMP代理會重新發送該消息，直到接收到管理站的回覆或者重新發送消息的次數超過預設的重發次數為止。通過這種消息發送方式，SNMP代理知道管理站是否已經成功地接收到消息，保證了消息被可靠地傳送到管理站，同時，在管理站和SNMP代理間的通信出現故障時也能夠停止消息的發送，避免不停地向管理站發送消息。
雖然Inform-Request消息發送方式解決了Trap消息發送方式的可靠性問題，但是其自身也還是存在一些問題。
Inform-Request發送方式的響應機制和消息重傳機制，增加了網絡數據流量。正常情況下的數據流量時採用Trap方式的兩倍(因為響應消息)，在突發情況下，例如在因為電力供應問題導致設備重新啟動時，SNMP代理設備會在很短的時間內向各個上級管理站突發的大量的消息，大大增加了管理站的處理負擔，因為會導致大量的Inform-Request消息得不到及時處理而出現Inform-Request消息重傳的問題，造成了網絡流量的劇增，同時由於需要處理大量的響應消息和重傳大量的消息，也大大增加了增加SNMP代理的工作負擔，影響了設備運行的穩定性。
另外，由於Inform-Request發送方式的消息重傳機制，會造成有些經過了重傳後的消息無法按照順序到達管理站，這樣就不適合於對消息先後順序有依賴關係的管理站系統的處理。
發明內容
本發明解決的技術問題是提出一種簡單網絡管理協議消息傳送方法及裝置，應用於客戶端向伺服器端傳送簡單網絡管理協議消息的網絡環境中，用來減小現有技術的Inform-Request消息發送方式對設備運行性能和網絡運行性能的影響，同時也用來解決現有技術中消息無法按照順序到達管理站的問題。
為解決上述問題，本發明提出了以下的技術方案。
該方案包括一種簡單網絡管理協議消息傳送方法，包括將客戶端中待發送消息按照順序存儲在消息隊列中，客戶端中設置有多個與伺服器端分別對應的消息分發單元a)消息分發單元從消息隊列中獲取一個消息；b)判斷所述獲取的消息是否是發送給與所述消息分發單元對應的伺服器端，如果是，向所對應的伺服器端發送該消息，執行步驟c)，否則，執行步驟d)；c)判斷所述伺服器端是否接收到所發送的消息，如果是，執行步驟d)，否則，執行步驟e)；d)從所述消息隊列中按照順序獲取下一個消息，然後執行步驟b)；e)重新發送所述消息，並執行步驟c)。
其中，步驟d)包括步驟d1)判斷當前所獲取的消息是否是隊列內最後一個消息，如果是，停止消息發送，否則，執行步驟d2)；d2)從隊列中按照順序獲取下一個消息，並執行步驟b)。
步驟e)具體地包括步驟e1)判斷客戶端與該伺服器端的鏈路是否正常，如果是，執行步驟e2)，否則，等待一個預設的時間，重新執行步驟e1)；e2)重新發送該消息，並執行步驟c)。
相應地，本方案還包括簡單網絡管理協議消息傳送裝置，包括存儲單元以及分別與各伺服器對應的消息分發單元，其中存儲單元，用於按照順序存儲待發送消息；消息分發單元，用於將所述存儲單元內、待發送給與該消息分發單元對應的伺服器端的消息按照順序發送給該伺服器。
其中，消息分發單元又進一步包括消息獲取單元、判斷單元、消息收發單元以及故障處理模塊消息獲取單元，用於按照順序從存儲單元中獲取待發送消息；
判斷單元，用於判斷消息獲取單元所獲取的消息是否是發送給與其對應的伺服器的消息，如果是，將該消息發送給消息收發單元，否則，通知消息獲取單元獲取下一個消息；消息收發單元，用於將從判斷單元接收的消息發送給與其對應的伺服器端，並判斷伺服器端是否接收到所發送的消息，如果是，通知消息獲取單元獲取下一個消息，否則，通知故障處理單元處理；通信檢測單元，與消息收發單元相連，用來檢測客戶端和伺服器之間的通信是否正常，如果通信正常，通知消息收發單元重新發送當前消息，否則，等待一個預設的時間，繼續檢測客戶端和伺服器之間的通信狀態。
此外，消息分發單元還包括發送結束判斷單元，與消息獲取單元相連，在消息獲取單元獲取下一個消息之前，用於判斷當前發送的消息是否是隊列內最後一個消息，如果是，停止從隊列中獲取消息，否則，按照順序獲取下一個消息。
所述的消息收發單元又包括消息確認單元用於判斷是否接收到伺服器端回復的確認接收到消息的響應消息，如果判斷為是，確定伺服器端接收到所發送的消息，否則，確定伺服器端未接收到所發送的消息。
所述的消息確認單元又包括回復確認單元用於判斷客戶端是否接收到伺服器端回復的確認接收到消息的響應消息，如果判斷為是，確定伺服器端接收到所發送的消息，否則，客戶端向伺服器端重複發送該消息，判斷客戶端是否在預設的重複發送次數內接收到伺服器端回復的確認接收到消息的響應消息，如果判斷為是，確定伺服器端接收到所發送的消息，否則，確定伺服器端未接收到所發送的消息。
上述方案中，所述的消息收發單元均通過通知請求的方式向伺服器端發送消息。
上述方案中，客戶端按照消息生成的時間先後順序將客戶端中待發送消息存儲在消息隊列中。
與現有技術相比，本發明將所有待發送消息按照順序存儲在一個公共的隊列中，由消息分發單元分別向各個管理站依次分發消息，簡化了SNMP代理髮送消息的流程；同時，由於SNMP代理依次向管理站發送消息，不會向管理站突發大量的消息，避免了大量的突發消息對SNMP代理和管理站的運行的影響，也避免了大量的突發消息對網絡性能的影響；此外，本發明SNMP代理嚴格按照消息的順序向管理站發送消息，並保證消息被正確接收後再發送下一個消息，能夠保證消息按照順序到達管理站，適合於對消息的先後順序有依賴性的管理站的處理；而且，本發明還能夠在SNMP代理和管理站之間的通信出現故障時，暫停消息發送，對故障進行檢測，故障恢復後能夠恢復消息的發送。
圖1是本發明的簡單網絡管理協議消息傳送方法流程圖；圖2是本發明簡單網絡管理協議消息傳送方法實施例流程圖；圖3是本發明簡單網絡管理協議消息傳送裝置結構示意圖；圖4是本發明簡單網絡管理協議消息傳送裝置消息分發單元結構圖；圖5是本發明簡單網絡管理協議消息傳送裝置實施例流程圖。
具體實施例方式
下面根據附圖對本發明的實施例作出詳細的說明。
本發明主要應用於SNMP網絡中客戶端向伺服器端傳送SNMP消息的網絡環境中。它的主要發明思路為將客戶端中待發送消息依次按照順序存儲在一個公共的隊列中，與每個與伺服器端分別有一個消息分發單元與其對應，如圖1所示，這些消息分發單元分別執行以下步驟a)消息分發單元從消息隊列中獲取一個消息；b)判斷所述獲取的消息是否是發送給與所述消息分發單元對應的伺服器端，如果是，向所對應的伺服器端發送該消息，執行步驟c)，否則，執行步驟d)；c)判斷所述伺服器端是否接收到所發送的消息，如果是，執行步驟d)，否則，執行步驟e)；d)從所述消息隊列中按照順序獲取下一個消息，然後執行步驟b)；e)重新發送所述消息，並執行步驟c)。
在實際應用中，上面的客戶端體現為SNMP代理，伺服器端體現為SNMP管理站。下面是本發明的上述步驟應用在網管系統中的具體實現原理在SNMP代理設備中，每條消息都有一個從小到大的有序的消息流水號，該流水號為整數或者字符串等能夠表示先後順序的數據形式，並且在該設備全局範圍內是唯一的。採用該有序的流水號，就可以唯一地標識該設備所有產生的消息以及消息產生的先後順序。
為了給每個生成的消息分配這樣的流水號，SNMP代理設備中始終保存著一個按照順序生成的最新的全局當前消息流水號，當SNMP代理設備生成一個新的消息時，系統就將全局當前消息流水號分配給該新生成的消息作為其流水號，同時，又按照順序生成一個新的流水號作為新的全局當前消息流水號。也即，全局當前消息流水號始終標識著下一個即將生成的消息的流水號。新生成的消息按照順序被存儲在一個待發消息隊列裡，隊列裡存儲著待發送到管理站的消息。
針對一個SNMP代理有多個管理站的情況，SNMP代理中有一個消息分發單元，用於向多個管理站分別分發消息。該消息分發單元對每一個管理站都有與其相對應的消息分發線程，而且各個消息分發線程獨立地工作。
當然，在實際應用中，該發明也可以應用於多個SNMP代理向一個管理站發送SNMP消息的情況。只不過在多個SNMP代理中都採用該發明，針對每個SNNP代理來說，只有一個管理站。
為了標明SNMP代理向各個管理站的分發消息的情況，在SNMP代理中保存著分別與各個管理站相對應的管理站專有當前消息流水號。該管理站專有當前消息流水號用來表示該流水號及該流水號之前的消息都已經成功發送給了該管理站。所以，該流水號記錄的是最近一個成功發送給對應管理站的消息的流水號。
為了保證一個消息能夠被成功地發送到伺服器端，本發明採用SNMP通知請求(SNMP Inform-Request)的消息傳送方式。Inform-Request方式也採用UDP的傳輸協議，但與trap方式不同的是Inform-Request方式有響應包，當SNMP管理站接收到一條Inform消息後它需要向SNMP代理回復一條確認信息。通過這種方式，SNMP代理知道管理站是否已經成功地接收到消息，從而保證了消息被可靠地傳送到管理站。
在消息發送的過程中，為了避免當SNMP代理和管理站之間的通信出現故障時SNMP代理繼續向管理站發送消息，當SNMP代理所發送的消息沒有被管理站正確接收到的時候，SNMP代理暫停向管理站發送消息，該消息分發線程進入休眠狀態。
另外，為了保證在SNMP代理和管理站之間的通信恢復的情況下客戶端能夠恢復向伺服器端發送消息，SNMP代理有一個檢測管理站和SNMP代理之間通訊是否正常的通訊檢測模塊。在該消息分發線程處於休眠狀態的過程中，如果通信檢測模塊檢測到管理站和SNMP代理之間的通信恢復正常，SNMP代理就喚醒該處於休眠狀態的分發線程，恢復向該管理站發送消息。
根據以上的實現原理，下面是對本發明的一個具體實施例的說明。該實施例描述的是SNMP代理的一個消息分發線程通過SNMP Inform-Request方式向管理站分別發送消息，當管理站和SNMP代理出現通信故障時，該消息分發線程會暫停發送消息，當故障恢復時，該消息分發線程又會恢復發送消息。對於有多個管理站的情況，每一個管理站在SNMP代理內均有一個消息分發線程分別與其對應，這些線程都獨立工作，並執行相同的流程。
如圖2所示，每一個消息分發線程的具體消息發送流程如下10)從待發送消息隊列中獲取該管理站專有當前消息流水號對應的下一個消息。
在開始發送消息之前，管理站專有當前消息流水號確定了第一個被發送的待發送消息。在一個典型的消息發送過程中，該消息分發線程按照順序獲取隊列中的第一個消息，因此，在該線程開始發送消息之前，應該預設一個合理的管理站專有當前消息流水號，使得該消息流水號的下一個消息是隊列內的第一個消息。當然，本發明也支持從隊列的任何一個位置開始獲取消息，在這種情況下，消息分發線程只對從該消息開始的後面的消息進行分發。
20)判斷所獲取的消息是否是發送給與該線程對應的管理站的，如果是，則向該管理站發送該消息，並執行步驟30)，否則，執行步驟40)。
在SNMP代理中，發送給所有管理站的待發送消息都存儲在一個隊列中，對於所有的待發送消息，各消息分發線程在發送消息之前都要對其進行過濾，對於不是發送給該線程所對應的管理站的消息，都會被過濾掉，忽略不進行處理，對於是發送該線程所對應的管理站的消息，則進行進一步處理。
在每一個待發送消息內都攜帶有發送目的地信息，通過查詢該目的地信息可以判斷該消息是否是發送給與某各線程對應的管理站的。
30)判斷管理站是否接收到所發送的消息，如果是，執行步驟40)，否則，執行步驟50)；由於採用Inform-Request的發送方式向管理站發送消息，判斷管理站是否正確接收到所發送的消息的一種方法是SNMP代理是否在預設的時間間隔內接收到管理站對所發送的Inform-Request報文的確認回復，如果是，則判斷管理站正確接收到所發送的消息，否則，判斷管理站沒有正確接收到所發送的消息。
另外，判斷管理站是否正確接收到所發送的消息的另一種方法是SNMP代理是否在預設的時間間隔內接收到管理站對所發送的Inform-Request報文的確認回復，如果是，則判斷管理站正確接收到所發送的消息，否則，SNMP代理根據預設的重發次數向管理站重新發送該消息，判斷管理站是否在預設的重發次數內對所發送的Inform-Request報文回復確認消息，如果是，則判斷管理站正確接收到所發送的消息，否則，判斷管理站沒有正確接收到所發送的消息。
40)設置該管理站專有當前消息流水號等於該成功發送消息的流水號，判斷管理站專有當前消息流水號的下一個流水號是否等於全局當前消息流水號，如果是，停止消息發送，否則，重新執行步驟10)。
管理站專有當前消息流水號的下一個流水號等於全局當前消息流水號，表明當前發送的消息是SNMP代理內全局範圍內最後一個消息，也即消息發送完畢，所以該分發線程暫停發送消息，直到有了新的消息生成並等待發送，管理站專有當前消息流水號的下一個流水號不再等於全局當前消息流水號，該分發線程重新開始發送消息。
50)判斷管理站和SNMP代理之間的通信是否正常，如果是，執行步驟10)，否則，等待一個預設的時間間隔，重新執行步驟50)，重新檢測管理站和SNMP代理之間的通信狀態。
此時，由於管理站沒有正確接收到所發送的消息，消息分發線程通知啟動通信檢測單元檢測管理站和SNMP代理之間的通信狀態，如果是管理站和SNMP代理之間的通信故障導致管理站無法正確接收到消息，該消息分發線程暫停發送消息，並且隨時保持檢測管理站和SNMP代理之間的通信狀態，一旦恢復，立即轉至步驟10)，重新發送消息。
由於此時當前消息並沒有被管理站正確接收，所以在步驟30)，該管理站專有當前消息流水號並沒有改變，所以，當通信狀態恢復後轉至步驟10)後所發送的消息仍然是當前沒有被正確發送出去的消息。
與此同時，本發明也提出一種簡單網絡管理協議消息傳送裝置，如圖3所示，主要包括存儲單元和消息分發單元，其中，與該SNMP所連接的每個管理站，都有一個消息分發單元與其對應。如圖4所示，消息分發單元又進一步包括消息獲取單元、判斷單元、消息收發單元以及通信檢測單元。
下面對其實施例進行具體說明。
圖5是該裝置的具體實施例結構示意圖，主要包括寄存器、待發送消息隊列、消息獲取單元、判斷單元以及、發送結束判斷單元、消息收發單元以及通信檢測單元。
寄存器用來寄存全局當前消息流水號和管理站專有當前流水號，其中全局當前流水號標識下一個即將生成的消息的流水號，管理站專有當前流水號標識最近一個成功發送給與消息分發單元對應的管理站的消息的流水號。
待發送消息隊列用來存儲待發送的消息，每一個攜帶有流水號信息的待發送消息都按照全局當前流水號的順序存儲在這個待發送消息隊列中。
消息獲取單元，從待發送消息隊列中獲取該管理站專有當前消息流水號對應的下一個消息。
判斷單元，用於判斷消息獲取單元所獲取的消息是否是發送給與其對應的管理站的消息，如果是，將該消息發送給消息收發單元，否則，設置該管理站專有當前消息流水號等於該成功發送消息的流水號，通知發送結束判斷單元消息是否發送完畢。
消息收發單元，用於將從判斷單元接收的消息發送給與其對應的管理站，並判斷管理站是否接收到所發送的消息，該判斷功能由消息收發單元中的消息確認單元完成，如果判斷為是，設置該管理站專有當前消息流水號等於該成功發送消息的流水號，通知發送結束判斷單元消息是否發送完畢，否則，通知通信檢測單元檢測SNMP代理與管理站之間的通信是否正常。判斷採用前面實施例中所述的相同方法判斷管理站是否接收到所發送的消息。
發送結束判斷單元，在消息獲取單元獲取下一個消息之前，用於判斷管理站專有當前消息流水號的下一個流水號是否等於全局當前消息流水號，如果是，停止從隊列中獲取消息，否則，通知消息獲取單元按照順序獲取下一個消息；通信檢測單元，與消息收發單元相連，用來檢測SNMP代理和管理站之間的通信是否正常，如果通信正常，通知消息獲取單元重新當前消息進行發送，否則，等待一個預設的時間，繼續檢測SNMP代理和管理站之間的通信狀態，直到通信狀態恢復，通知消息獲取單元重新當前消息進行發送。
以上所述僅是本發明的優選實施方式，應當指出，對於本技術領域的普通技術人員來說，在不脫離本發明原理的前提下，還可以作出若干改進和潤飾，這些改進和潤飾也應視為本發明的保護範圍。
權利要求
1.一種簡單網絡管理協議消息傳送方法，應用於客戶端向伺服器端傳送簡單網絡管理協議消息的網絡環境中，其特徵在於，將客戶端中待發送消息按照順序存儲在消息隊列中，客戶端中設置有多個與伺服器端分別對應的消息分發單元a)消息分發單元從消息隊列中獲取一個消息；b)判斷所述獲取的消息是否是發送給與所述消息分發單元對應的伺服器端，如果是，向所對應的伺服器端發送該消息，執行步驟c)，否則，執行步驟d)；c)判斷所述伺服器端是否接收到所發送的消息，如果是，執行步驟d)，否則，執行步驟e)；d)從所述消息隊列中按照順序獲取下一個消息，然後執行步驟b)；e)重新發送所述消息，並執行步驟c)。
2.如權利要求1所述的簡單網絡管理協議消息傳送方法，其特徵在於，步驟d)包括步驟d1)判斷當前所獲取的消息是否是隊列的最後一個消息，如果是，則停止消息發送，否則，執行步驟d2)；d2)從所述消息隊列中按照順序獲取下一個消息，並執行步驟b)。
3.如權利要求1所述的簡單網絡管理協議消息傳送方法，其特徵在於，步驟e)具體地包括步驟e1)判斷客戶端與該伺服器端的鏈路是否正常，如果是，執行步驟e2)，否則，等待一個預設的時間，重新執行步驟e1)；e2)重新發送該消息，並執行步驟c)。
4.如權利要求1所述的簡單網絡管理協議消息傳送方法，其特徵在於，在步驟c)中，所述的判斷伺服器端是否接收到所發送的消息步驟為判斷是否接收到伺服器端回復的確認接收到消息的響應消息，如果是，確定伺服器端接收到所發送的消息，否則，確定伺服器端未接收到所發送的消息。
5.如權利要求1所述的簡單網絡管理協議消息傳送方法，其特徵在於，所述的將客戶端中待發送消息按照順序存儲在消息隊列中為按照消息生成的時間先後順序將客戶端中待發送消息存儲在消息隊列中。
6.如權利要求1至5任一項所述的簡單網絡管理協議消息傳送方法，其特徵在於，所述的客戶端以通知請求的方式向伺服器端發送消息。
7.一種簡單網絡管理協議消息傳送裝置，用於向至少一個伺服器端傳送簡單網絡管理協議消息，其特徵在於，包括存儲單元以及分別與各伺服器對應的至少一個消息分發單元，其中存儲單元，用於按照順序存儲待發送消息；消息分發單元，分別與各伺服器端對應相連，用於將所述存儲單元內的消息依次發送給相對應的伺服器。
8.如權利要求7所述的簡單網絡管理協議消息傳送裝置，其特徵在於，所述的消息分發單元進一步包括消息獲取單元、判斷單元、消息收發單元以及故障處理模塊，其中消息獲取單元，用於從存儲單元中獲取待發送消息；判斷單元，用於判斷消息獲取單元所獲取的消息是否是發送給與其對應的伺服器的消息，如果是，將該消息發送給消息收發單元，否則，由消息獲取單元獲取下一個消息；消息收發單元，用於將從判斷單元接收的消息發送給與其對應的伺服器端，並判斷伺服器端是否接收到所發送的消息，如果是，由消息獲取單元獲取下一個消息，否則，由故障處理單元處理；通信檢測單元，與消息收發單元相連，用來檢測客戶端和伺服器之間的通信是否正常，如果通信正常，由消息收發單元重新發送當前消息，否則，等待一個預設的時間，繼續檢測客戶端和伺服器之間的通信狀態。
9.如權利要求8所述的簡單網絡管理協議消息傳送裝置，其特徵在於，還包括發送結束判斷單元，與消息獲取單元相連，在消息獲取單元獲取下一個消息之前，用於判斷當前發送的消息是否是隊列內最後一個消息，如果是，消息獲取單元停止從隊列中獲取消息，否則，按照順序獲取下一個消息。
10.如權利要求8所述的簡單網絡管理協議消息傳送裝置，其特徵在於，所述的消息收發單元還包括消息確認單元用於判斷是否接收到伺服器端回復的確認接收到消息的響應消息，如果判斷為是，確定伺服器端接收到所發送的消息，否則，確定伺服器端未接收到所發送的消息。
11.如權利要求10所述的簡單網絡管理協議消息傳送裝置，其特徵在於，所述的消息確認單元還包括回復確認單元用於判斷客戶端是否接收到伺服器端回復的確認接收到消息的響應消息，如果判斷為是，確定伺服器端接收到所發送的消息，否則，客戶端向伺服器端重複發送該消息，判斷客戶端是否在預設的重複發送次數內接收到伺服器端回復的確認接收到消息的響應消息，如果判斷為是，確定伺服器端接收到所發送的消息，否則，確定伺服器端未接收到所發送的消息。
全文摘要
本發明公開了一種簡單網絡管理協議消息傳送方法及裝置，包括以下方法將客戶端中待發送消息按照順序存儲在消息隊列中，客戶端中設置的每個與伺服器端分別對應的消息分發單元分別執行以下步驟a)從隊列中獲取一個消息；b)判斷所述獲取的消息是否是發送給與該消息分發單元對應的伺服器端的消息，如果是，向伺服器端發送該消息，執行步驟c)，否則，執行步驟d)；c)判斷伺服器端是否接收到所發送的消息，如果是，執行步驟d)，否則，執行步驟e)；d)從隊列中按照順序獲取下一個消息，執行步驟b)；e)重新發送該消息並執行步驟c)。採用本發明，避免了突發的消息對網絡性能和設備性能的影響，提高了消息傳送的可靠性，同時也提高了設備的可維護性。
文檔編號H04L29/06GK101056194SQ200610036278
公開日2007年10月17日 申請日期2006年6月30日 優先權日2006年6月30日
發明者藍智能 申請人:華為技術有限公司