一种简单网络管理协议消息传送方法及装置的制作方法

文档序号:7955161阅读:214来源:国知局
专利名称:一种简单网络管理协议消息传送方法及装置的制作方法
技术领域
本发明涉及通信领域,具体地讲涉及到一种简单网络管理协议消息传送方法及装置。
背景技术
简单网络管理协议(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日
发明者蓝智能 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1