现在的位置: 首页 > 综合 > 正文

摘抄来的SNMP的建议

2013年10月07日 ⁄ 综合 ⁄ 共 1711字 ⁄ 字号 评论关闭
 

从我接触SNMP的过程中,我发现在我们这块领域内存在两个很大的缺陷,就是真正有用的文档太少了更别说中文的了,从最开始写Snmp管理端的时候,对动态加载MIB那一块就感觉资料非常少,不得以自己一行一行分析Mib文件,研究ASN.1,自己写了个Delphi版的mib Parser。到我们想去动手自己写snmp协议库的时候,资料更是少!这是其一!其二:目前大部分做这方面开发的朋友,都是在用SNMP++,NET-SNMP,它们的代码其实都让人感觉有点发怵,更有胜者,看看adventnet它的Agent Toolkit C
Edition
,它写的封装snmp协议库(C版本)的源代码,那更让人却步!

其实说到底SNMP Agent的实现机理和内部框架是比较清晰和容易掌握的。现把我在开发CSnmp的过程中的系统架构和实现难点总结出来于大家分享,希望能对那些不仅仅是用

已有的SNMP库开发网络应用管理程序的朋友有一点帮助。

  
首先用非常一句话概括CSnmp的功能,它是一个实现了snmpV2csnmpV3标准,并打开705端口实现AgentXRFC 2741)大部分重要PDUAGENT,并提供开发支持AgentX

协议的SubAgent的开发API(目前只提供JAVA版本的,紧接着下一步立刻提供C版本的API)

CSnmp的架构如下:管理端<-――>MasterAgent<―――>SubAgent

1.       MasterAgent打开两个端口161, 705161负责接受从管理端来的请求(GetPDU, GetNextPDU,
GetBulkPDU
)705负责向每个subAgent发送AgentXGetPDU, AgentXGetNext,
AgnetXGetBulk
请求,当然这些请求是按照AgentX协议的标准来封装的(AgentX协议相对标准的SNMP来说较为简单),同时705端口还负责接受从SubAgent处来的请求,比如说agentx-Open-PDUagentx-Register-PDUagentx-Notify-PDU等。

2.      
正因为打开了两个端口,那么就应该在软件实现中至少有一个HashMap(暂取名为Map1)负责存储从管理端来的request。这个HashMapIndex是向subAgent发送的请求包中的transactionID

    3.当subAgent接受到从MasterAgent来的请求后,解AgentXPDU包,看到底是做什么的,并进行与之相应的处理,把产生的结果按The
agentx-Response-PDU
的要求打包,发送给MasterAgent

    4MasterAgent705端口接受到,开始发出请求的相应,解开这个AgentX Response PDU包,从解包结果中把transactionID取出来,到刚才的Map1中根据transactionID去找到开始从Manager(管理端)进来的请求,并根据该请求把subAgent返回的值按SNMP协议打包,发还给Manager,从而完成了一次完整的交互过程。

 

下面,就大家非常关心的Mib问题,从实现层面上来做一分析。Mib信息分别在SubAgentMasterAgent中都要存储。Mib的存储由两种数据结构共同合作来实现,一个是HashMap(暂取名为mibMap),一个是Vector(暂取名为mibVector)。mibMap是为了快速搜索由subAgent注册的mib Subtree(“注册”:就是subAgent告诉MasterAgent说该mib 节点下的所有子节点你都可以到我这个subAgent去找)。而mibVector则是为了方便的实现getNext这一操作。有了这个mibVector,所有在MasterAgent中被subAgents注册的mib节点都是按照“字典“顺序排序的。其实,每个从Manager发给MasterAgent的请求,在解包后的第一步就是看该请求中的mib OID是不是在mibMap中,有的话接着进行下面的操作,没有的话直接返回管理端,并报以相应的错误。

抱歉!评论已关闭.