2.MIB文件
首先需要的是定义了待实现MIB模块的MIB文件。
严格的说，这个文件并不是必需的，因为代理自己并不直接使用MIB定义。但是，基于以下三个原因推荐从MIB文件开始：
（1）它提供了待实现模块的初始规格说明。当你清楚自己该做什么时编码就很容易了。
（2）如果新的MIB文件与其他MIB文件一起读入，这个MIB文件可使上层的应用程序格式化从代理获得的数据（如：区分OID和值），而不仅仅是无格式的数。（注意：需要应用程序载入新的MIB文件。详情查看相关的FAQ）
（3）MIB2C工具使用MIB文件生成C头文件和C实现文件。
这是开发新模块最简单的方法了。
（v5（指NET-SNMP）版本的MIB2C是相似的，但和这里描述的v4版本不完全一致）
如果打算实现一个标准的MIB模块，或一个生产商定制的模块，文件的结构就已经为你做好了。如果要实现一个完全新的，私有的模块，除了代理的代码外，这个MIB文件也得你自己写。
MIB文件格式和语法不再本文的描述范围之内，大多数介绍SNMP的书籍都会提供这方面的信息。一本推荐的书是：
《Understanding SNMP MIBS》(Perkins & McGinnis, Prentice Hall, ISBN 0-13-437708-7).
MIB树的划分
MIB树的划分完全由内部实现方法决定。一个合理的划分可以使实现简单明了，使开发和维护都变得容易。不幸的是，MIB的划分是与具体模块相关的，所以必须视具体情况而定。对于一个完备的模块，合理的做法是将一个模块实现为单个”块“（例如SNMP子树RFC1907或TCP子树RFC2011）。更复杂多样的模块（如Host Resources MIB-RFC1514）一般视为由许多独立的子模块构成。
划分MIB树的一些建议：
（1）由有相同OID前缀的对象组成的MIB子树一般由单个模块实现
（2）不同的子树由不同的模块实现
（3）表既可以由单个模块处理，也可由多个不同模块处理。
（4）依赖于相同数据源的变量应实现于同一模块中。（反之不必）
另一个基本原则是，不同的子树和表，都应分开处理。目前许多已实现的代理都是这样做的，如大部分MIB-II模块都是实现于不同的文件之中。
阅读(1778) | 评论(0) | 转发(0) |
