简单网络管理协议SNMP(Simple Network Management Protocol)是为网络管理系统提供的底层网络管理的框架。其应用范围非常广泛，诸多种类的网络设备、软件和系统中都有所采用。SNMP协议发展到目前的第3版，已经成为一个非常成熟的网络管理协议[1]。不过由于每个设备的支持程序有所不同，所以面向SNMP的成熟网络管理框架依然非常少见[2]。在SNMP的支持方面，Cisco是走在最前沿的[3]，除了完整地支持RFC1213中MIB-2的定义外，还在部分设备中支持RFC2819和RFC2021中的RMON。基于Cisco的主流性，开发“可扩展”的基于SNMP的网络管理框架变得非常现实。

1 开发平台与架构的选择

.NET平台的C#语言有着丰富的语言特性，例如Lambda表达式(在Auto-Topology控件及软件框架中已多次使用)可以显著地提升开发效率，而且支持C#的官方开发环境Visual Studio是公认的更加有助于团队协作的集成开发环境。再者，C#中匿名对象、对象初始化器、闭包支持LINQ等利于DSL表现的特性，加之良好的异步编程支持，使C#成为了首选语言，自然，首选的平台则为.NET。

软件必须面对的两个基本问题是“通用性”与“可扩展性”。所谓通用性，就是在绝大多数的网络环境中都能够使用的基本功能;所谓可扩展性，就是在保证通用的前提下，充分发挥特有设备特别功能的能力。这使得通用框架的设计难度加大。

如何使网络管理任务充分简化是需要重点考虑的，软件的工作方式将会影响操作的行为，C/S结构或者纯粹的单体软件无疑有着更为强大的图形展现能力，而B/S结构则在伸缩性与跨平台方面有着更为良好的表现。一个较为折衷并且有经济效益的选择，就是在框架级别实现通用与跨平台，在表现层分离为不同的解决方案。最终，软件采用了普通软件的工作方式。

虽然可以自主开发SNMP底层的通讯类库来支持整个项目，但考虑到开发周期等因素，还是寻求一款更为优秀的开源组件来承担基础通讯。有两款开源组件可供选择：SnmpSharpNet和SharpSnmpLib。在仔细研究了这两款组件后发现，SharpSnmpLib更新频率更高，而且代码更加利于维护，于是选择SharpSnmpLib来支持开发。

2 系统分析

2.1 重点问题

由于SNMP协议在不同的设备上支持的情况不同，所以要求软件的一些通用功能兼容大部分设备，这是很有挑战的。常见的网络管理任务基本都建立在以拓扑图为蓝本的扩展之上，所以无论设备如何不同、协议支持情况有多复杂，自动网络拓扑发现功能是一个不能缺少的核心功能。如何在兼容常见设备的基础上实现扩展功能成为研究的重点问题。

2.1.1 与现有的大部分硬件设备保持兼容

与其说实现兼容，倒不如理解为只使用大部分硬件都能支持的功能来实现。一个显而易见的解决方案就是只使用RFC1213中定义的MIB-2功能组。MIB-2中定义了网络管理中经常使用的对象，并且得到了绝大多数设备的支持。如果只使用MIB-2中定义的功能来支撑软件的核心功能，那么软件与硬件的兼容性问题自然也会少很多。

2.1.2 通过SNMP的方式得到网络拓扑

SNMP协议的相关功能中没有直接获取拓扑结构的对象，在一些私有MIB中(例如Cisco中关于CDP的相关对象)有这样直接的功能，但是对网络环境与设备要求苛刻(CDP协议只在纯Cisco网络中有用，虽然有部分非Cisco开始支持CDP，但是数量很少)[4]，所以这不是一个通用的解决方案。

为了保持设备和网络的兼容性，前面提到应该采用“保守”的对象来实现核心功能，所以拓扑图的自动发现只能从MIB-2中查找相应的解决方案。网络拓扑，顾名思义就是网络设备之间的逻辑关系，那么反映到网络技术中，最为直接的对应就是路由表。但是路由表中只有网络设备间的关系，支持SNMP的PC信息却不在路由表中。如何解决支持SNMP的PC发现呢?一个方案就是查找网络设备中的“地址转换表”，这其中有PC的IP信息，通过对这些PC逐一进行SNMP测试，就可完整地支持整个SNMP网络[5]。另外，需要知道设备自身接口的IP，这在MIB-2的IP功能组(1.3.6.1.2.1.4)中都有定义。

2.2 难点问题

2.2.1 拓扑图的布局

拓扑图的机制确定之后，另一个难题就是如何将各个设备以及相关线路布置在屏幕上。由于设备之间的唯一关系就是相互间的链路，没有与物理结构相关的数据可以获得，所以要想完全通过软件绘制出与物理结构相同或相似的拓扑图是非常困难的，可以参考的相关资料和论文非常少[6]。

拓扑图的分布是个学术难题，环状权值分布仅作为一种理论尝试，为了今后有更好的理论支撑，可以灵活地修改布局算法，软件在开发过程中采用“策略模式”(Strategy)将布局算法抽象出来，易于替换。

2.2.2 映射领域模型到存储模型

领域模型记录了一个系统中的关键概念和词汇表，显示出了系统中的主要实体之间的关系，并确定了它们的重要方法和属性。对于一个SNMP应用系统来说，主要的领域模型就是SNMP实体。另外一个扩展功能就是对网络设备的“管理”，这涉及到资产评估、设备统计、维修管理等相关的应用，换句话讲，如何将软件获取到的信息与现实中的设备对应起来，是软件需要解决的一个方面。

3 总体描述及框架设计

3.1 系统核心

系统实现所涉及的核心问题分别如下：

(1)如何获取和绘制拓扑结构图，并合理地调整拓扑样式;

(2)同步引擎的合理调度，以及信息存储结构;

(3)功能的合理分类，以及对相关OID的分析、组织、建模;

(4)基础构建块的选择。

由于系统采用了分层开发，以及可扩展性等多方面的考虑，软件在逻辑上分为4层——持久层、基础层、业务层、表示层，基本的工作模式如图1所示。

3.2 存储模型

存储模型为“设备管理”以及相关的扩展应用提供持久化的机制，并为统计、分析等要求查询对比历史数据的需求提供基础。

对于数据库的选择，从成本上考虑，有Microsoft SQL Server Express、Microsoft SQL CE、MongoDB、NoSQL可供选择，而从部署上考虑有MongoDB、部分NoSQL、Microsoft SQL CE可选择，最后从性能上考虑，采用Microsoft SQL CE来支持存储模型。

经过持久后的数据可以在相对固定的时间内有效，在此基础上，进行统计、跟踪、分析等功能就会迅速许多，同时，网络的负荷也会明显降低。

3.3 领域逻辑设计

系统与SNMP网络交互的主要逻辑依赖于SNMP协议所传输的SNMP对象数据，SNMP对象又依赖于相关的MIB来描述其特性与结构。软件所需要的领域逻辑主要集中在对SNMP实体的操作上，但是SNMP的操作是对程序不友好的。也就是说，无法通过流畅的API来操作SNMP使之为软件所用。所以需要设计一种领域逻辑，将SNMP的特定领域转化为程序友好的领域。考虑图2所示的领域转化。

SNMP的操作原语被转化为对应的编程概念，使SNMP的领域完整地转化为程序设计的领域。这为AOP编程以及存储模型的扩展奠定了基础。