snmp_index

MODULE

snmp_index

MODULE SUMMARY

Abstract Data Type for SNMP Indexing

DESCRIPTION

The module snmp_index implements an Abstract
Data Type (ADT) for an SNMP
index structure for SNMP tables. It is implemented as an ets
table of the ordered_set data-type, which means that all operations are
O(log n). In the table, the key is an ASN.1 OBJECT
IDENTIFIER.

This index is used to separate the implementation of the SNMP
ordering from the actual implementation of the table. The SNMP
ordering, that is implementation of GET NEXT, is implemented in this
module.

For example, suppose there is an SNMP table, which is best
implemented in Erlang as one process per SNMP table row. Suppose
further that the INDEX in the SNMP table is an OCTET STRING. The
index structure would be created as follows:

snmp_index:new(string)

For each new process we create, we insert an item in an
snmp_index structure:

The key_types() type is used when creating the
index structure, and the key() type is used when inserting
and deleting items from the structure.

The key_types() type defines the types of the SNMP INDEX
columns for the table. If the table has one single INDEX column,
this type should be a single atom, but if the table has multiple
INDEX columns, it should be a tuple with atoms.

If the INDEX column is of type INTEGER, or derived from
INTEGER, the corresponding type should be integer. If it
is a variable length type (e.g. OBJECT IDENTIFIER, OCTET STRING),
the corresponding type should be string. Finally, if the
type is of variable length, but with a fixed size restriction
(e.g. IpAddress), the corresponding type should be
fix_string.

For example, if the SNMP table has two INDEX columns, the first
one an OCTET STRING with size 2, and the second one an OBJECT
IDENTIFER, the corresponding key_types parameter would be
{fix_string, string}.

The key() type correlates to the key_types()
type. If the key_types() is a single atom, the
corresponding key() is a single type as well, but if the
key_types() is a tuple, key must be a tuple of the
same size.

In the example above, valid keys could be {"hi", "mom"} and {"no", "thanks"}, whereas "hi",
{"hi", 42} and {"hello", "there"} would be invalid.

Warning

All API functions that update the index return a NewIndex
term. This is for backward compatibility with a previous
implementation that used a B+ tree written purely in Erlang for
the index. The NewIndex return value can now be ignored.
The return value is now the unchanged table identifier for the
ets table.

The implementation using ets tables introduces a semantic
incompatibility with older implementations. In those older
implementations, using pure Erlang terms, the index was garbage
collected like any other Erlang term and did not have to be
deleted when discarded. An ets table is deleted only when the
process creating it explicitly deletes it or when the creating
process terminates.

A new interface delete/1 is now added to
handle the case when a process wants to discard an index table
(i.e. to build a completely new). Any application using
transient snmp indexes has to be modified to handle this.

As an snmp adaption usually keeps the index for the whole of the
systems lifetime, this is rarely a problem.