File: snmp_instr_functions.html

package info (click to toggle)
erlang-doc-html 1%3A11.b.2-1
links: PTS
area: main
in suites: etch, etch-m68k
size: 23,284 kB
ctags: 10,724
sloc: erlang: 505; ansic: 323; makefile: 62; perl: 61; sh: 45
file content (617 lines) | stat: -rw-r--r-- 16,371 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
  <TITLE>Instrumentation Functions</TITLE>
  <SCRIPT type="text/javascript" src="../../../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
      ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="10"><!-- Empty --></A>
<H2>10 Instrumentation Functions</H2>

<P>A user-defined instrumentation function for each object attaches
the managed objects to real resources. This function is called by
the agent on a <CODE>get</CODE> or <CODE>set</CODE> operation. The function
could read some hardware register, perform a calculation, or
whatever is necessary to implement the semantics associated with the
conceptual variable. These functions must be written both for scalar
variables and for tables. They are specified in the association
file, which is a text file. In this file, the <CODE>OBJECT
IDENTIFIER</CODE>, or symbolic name for each managed object, is
associated with an Erlang tuple <CODE>{Module,</CODE> <CODE>Function</CODE>,
<CODE>ListOfExtraArguments}</CODE>.


<P>When a managed object is referenced in an SNMP operation, the
associated <CODE>{Module, Function, ListOfExtraArguments}</CODE> is
called. The function is applied to some standard arguments (for
example, the operation type) and the extra arguments supplied by the
user.


<P>Instrumentation functions must be written for <CODE>get</CODE> and
<CODE>set</CODE> for scalar variables and tables, and for <CODE>get-next</CODE>
for tables only. The <CODE>get-bulk</CODE> operation is translated into a
series of calles to <CODE>get-next</CODE>.

<A NAME="10.1"><!-- Empty --></A>
<H3>10.1 Instrumentation Functions</H3>

<P>The following sections describe how the instrumentation
functions should be defined in Erlang for the different
operations. In the following, <CODE>RowIndex</CODE> is a list of key
values for the table, and <CODE>Column</CODE> is a column number.


<P>These functions are described in detail in <A HREF="snmp_def_instr_functions.html">Definition of Instrumentation
        Functions</A>.


<A NAME="10.1.1"><!-- Empty --></A>
<H4>10.1.1 New / Delete Operations</H4>

<P>For scalar variables:


<PRE>
variable_access(new [, ExtraArg1, ...])
variable_access(delete [, ExtraArg1, ...])
      
</PRE>

<P>For tables:


<PRE>
table_access(new [, ExtraArg1, ...])
table_access(delete [, ExtraArg1, ...])
      
</PRE>

<P>These functions are called for each object in an MIB when the
MIB is unloaded or loaded, respectively.
<A NAME="10.1.2"><!-- Empty --></A>
<H4>10.1.2 Get Operation</H4>

<P>For scalar variables:


<PRE>
variable_access(get [, ExtraArg1, ...])
      
</PRE>

<P>For tables:


<PRE>
table_access(get,RowIndex,Cols [,ExtraArg1, ...])
      
</PRE>

<P><CODE>Cols</CODE> is a list of <CODE>Column</CODE>. The agent will sort
incoming variables so that all operations on one row (same
index) will be supplied at the same time. The reason for this is
that a database normally retrieves information row by row.


<P>These functions must return the current values of the
associated variables.
<A NAME="10.1.3"><!-- Empty --></A>
<H4>10.1.3 Set Operation</H4>

<P>For scalar variables:


<PRE>
variable_access(set, NewValue [, ExtraArg1, ...])
      
</PRE>

<P>For tables:


<PRE>
table_access(set, RowIndex, Cols [, ExtraArg1,..])
      
</PRE>

<P><CODE>Cols</CODE> is a list of tuples <CODE>{Column, NewValue}</CODE>.


<P>These functions returns <CODE>noError</CODE> if the assignment was
successful, otherwise an error code.
<A NAME="10.1.4"><!-- Empty --></A>
<H4>10.1.4 Is-set-ok Operation</H4>

<P>As a complement to the <CODE>set</CODE> operation, it is possible
to specify a test function. This function has the same syntax as
the set operation above, except that the first argument is
<CODE>is_set_ok</CODE> instead of <CODE>set</CODE>. This function is called
before the variable is set. Its purpose is to ensure that it is
permissible to set the variable to the new value.

<PRE>
variable_access(is_set_ok, NewValue [, ExtraArg1, ...])
      
</PRE>

<P>For tables:


<PRE>
table_access(set, RowIndex, Cols [, ExtraArg1,..])
      
</PRE>

<P><CODE>Cols</CODE> is a list of tuples <CODE>{Column, NewValue}</CODE>.

<A NAME="10.1.5"><!-- Empty --></A>
<H4>10.1.5 Undo Operation</H4>

<P>A function which has been called with <CODE>is_set_ok</CODE> will
be called again, either with <CODE>set</CODE> if there was no error,
or with <CODE>undo</CODE>, if an error occurred. In this way,
resources can be reserved in the <CODE>is_set_ok</CODE> operation,
released in the <CODE>undo</CODE> operation, or made permanent in the
<CODE>set</CODE> operation.

<PRE>
variable_access(undo, NewValue [, ExtraArg1, ...])
      
</PRE>

<P>For tables:


<PRE>
table_access(set, RowIndex, Cols [, ExtraArg1,..])
      
</PRE>

<P><CODE>Cols</CODE> is a list of tuples <CODE>{Column, NewValue}</CODE>.

<A NAME="10.1.6"><!-- Empty --></A>
<H4>10.1.6 GetNext Operation</H4>

<P>The GetNext Operation operation should only be defined for 
        tables since the
agent can find the next instance of plain variables in the MIB
and call the instrumentation with the <CODE>get</CODE> operation.


<PRE>
table_access(get_next, RowIndex, Cols [, ExtraArg1, ...])
      
</PRE>

<P><CODE>Cols</CODE> is a list of integers, all greater than or equal
to zero. This indicates that the instrumentation should find the
next accessible instance. This function returns the tuple
<CODE>{NextOid, NextValue}</CODE>, or
<CODE>endOfTable</CODE>. <CODE>NextOid</CODE> should be the
lexicographically next accessible instance of a managed object
in the table. It should be a list of integers, where the first
integer is the column, and the rest of the list is the indices
for the next row. If <CODE>endOfTable</CODE> is returned, the agent
continues to search for the next instance among the other
variables and tables.


<P><CODE>RowIndex</CODE> may be an empty list, an incompletely
specified row index, or the index for an unspecified row.


<P>This operation is best described with an example.

<A NAME="10.1.6.1"><!-- Empty --></A>
<H5>10.1.6.1 GetNext Example</H5>

<P>A table called <CODE>myTable</CODE> has five columns. The first
        two are keys (not accessible), and the table has three
        rows. The instrumentation function for this table is called
        <CODE>my_table</CODE>.
        
<P>
<CENTER>
<IMG ALT="getnext1" SRC="getnext1.gif"><BR>
<EM><A NAME="getnext1"><!-- Empty --></A>Contents of my_table
        </EM>

</CENTER>

<P>
<TABLE CELLPADDING=4>
  <TR>
    <TD VALIGN=TOP><IMG ALT="Note!" SRC="note.gif"></TD>
    <TD>

<P>N/A means not accessible.
            </TD>
  </TR>
</TABLE>

<P>The manager issues the following <CODE>getNext</CODE> request:
         
         
         
        
<PRE>
getNext{ myTable.myTableEntry.3.1.1,
         myTable.myTableEntry.5.1.1 } 
        
</PRE>

<P>Since both operations involve the 1.1 index, this is
        transformed into one call to <CODE>my_table</CODE>:
         
        
<PRE>
my_table(get_next, [1, 1], [3, 5])
        
</PRE>

<P>In this call, <CODE>[1, 1]</CODE> is the <CODE>RowIndex</CODE>, where
        key 1 has value 1, and key 2 has value 1, and <CODE>[3, 5]</CODE> is
        the list of requested columns. The function should now return
        the lexicographically next elements:
         
        
<PRE>
[{[3, 1, 2], d}, {[5, 1, 2], f}]
        
</PRE>

<P>This is illustrated in the following table:
         
        
<P>     
<P>
<CENTER>
<IMG ALT="getnext2" SRC="getnext2.gif"><BR>
<EM><A NAME="getnext2"><!-- Empty --></A>GetNext from [3,1,1] and [5,1,1].
        </EM>

</CENTER>

<P>The manager now issues the following <CODE>getNext</CODE> request:
         
        
<PRE>
getNext{ myTable.myTableEntry.3.2.1,
         myTable.myTableEntry.5.2.1 } 
        
</PRE>

<P>This is transformed into one call to <CODE>my_table</CODE>:
         
        
<PRE>
my_table(get_next, [2, 1], [3, 5])
        
</PRE>

<P>The function should now return:
         
        
<PRE>
[{[4, 1, 1], b}, endOfTable]
        
</PRE>

<P>This is illustrated in the following table:
         
        
<P>     
<P>
<CENTER>
<IMG ALT="getnext3" SRC="getnext3.gif"><BR>
<EM><A NAME="getnext3"><!-- Empty --></A>GetNext from [3,2,1] and [5,2,1].
        </EM>

</CENTER>

<P>The manager now issues the following <CODE>getNext</CODE> request:
         
        
<PRE>
getNext{ myTable.myTableEntry.3.1.2,
         myTable.myTableEntry.4.1.2 } 
        
</PRE>

<P>This will be transform into one call to <CODE>my_table</CODE>:
         
        
<PRE>
my_table(get_next, [1, 2], [3, 4])
        
</PRE>

<P>The function should now return:
         
        
<PRE>
[{[3, 2, 1], g}, {[5, 1, 1], c}]
        
</PRE>

<P>This is illustrated in the following table:
         
        
<P>     
<P>
<CENTER>
<IMG ALT="getnext4" SRC="getnext4.gif"><BR>
<EM><A NAME="getnext4"><!-- Empty --></A>GetNext from [3,1,2] and [4,1,2].
        </EM>

</CENTER>

<P>The manager now issues the following <CODE>getNext</CODE> request:
         
        
<PRE>
getNext{ myTable.myTableEntry,
         myTable.myTableEntry.1.3.2 } 
        
</PRE>

<P>This will be transform into two calls to <CODE>my_table</CODE>:
         
        
<PRE>
my_table(get_next, [], [0]) and
my_table(get_next, [3, 2], [1])
        
</PRE>

<P>The function should now return:
         
        
<PRE>
[{[3, 1, 1], a}] and
[{[3, 1, 1], a}]
        
</PRE>

<P>In both cases, the first accessible element in the table
        should be returned. As the key columns are not accessible,
        this means that the third column is the first row.
        
<P>
<TABLE CELLPADDING=4>
  <TR>
    <TD VALIGN=TOP><IMG ALT="Note!" SRC="note.gif"></TD>
    <TD>

<P>Normally, the functions described above behave exactly as
         shown, but they are free to perform other actions. For
         example, a get-request may have side effects such as setting
         some other variable, perhaps a global <CODE>lastAccessed</CODE>
         variable.
            </TD>
  </TR>
</TABLE>
<A NAME="10.2"><!-- Empty --></A>
<H3>10.2 Using the ExtraArgument</H3>

<P>The <CODE>ListOfExtraArguments</CODE> can be used to write generic
functions. This list is appended to the standard arguments for
each function. Consider two read-only variables for a device,
<CODE>ipAdr</CODE> and <CODE>name</CODE> with object identifiers 1.1.23.4 and
1.1.7 respectively. To access these variables, one could implement
the two Erlang functions <CODE>ip_access</CODE> and <CODE>name_access</CODE>,
which will be in the MIB. The functions could be specified in a
text file as follows:


<P> 

<PRE>
{ipAdr, {my_module, ip_access, []}}.
% Or using the oid syntax for 'name'
{[1,1,7], {my_module, name_access, []}}.
    
</PRE>

<P>The <CODE>ExtraArgument</CODE> parameter is the empty list. For
example, when the agent receives a get-request for the
<CODE>ipAdr</CODE> variable, a call will be made to
<CODE>ip_access(get)</CODE>. The value returned by this function is the
answer to the get-request.


<P>If <CODE>ip_access</CODE> and <CODE>name_access</CODE> are implemented
similarly, we could write a <CODE>generic_access</CODE> function using
the <CODE>ListOfExtraArguments</CODE>:


<PRE>
{ipAdr, {my_module, generic_access, ['IPADR']}}.
% The mnemonic 'name' is more convenient than 1.1.7
{name, {my_module, generic_access, ['NAME']}}.
    
</PRE>

<P>When the agent receives the same get-request as above, a call
will be made to <CODE>generic_access(get, </CODE>'<CODE>IPADR')</CODE>.


<P>Yet another possibility, closer to the hardware, could be:


<PRE>
{ipAdr, {my_module, generic_access, [16#2543]}}.
{name, {my_module, generic_access, [16#A2B3]}}.
    
</PRE>
<A NAME="10.3"><!-- Empty --></A>
<H3>10.3 Default Instrumentation</H3>
<A NAME="snmp_3"><!-- Empty --></A>
<P>When the MIB definition work is finished, there are two major
issues left.


<P>
<UL>

<LI>
Implementing the MIB


</LI>


<LI>
Implementing a Manager Application.

</LI>


</UL>

<P>Implementing an MIB can be a tedious task. Most probably, there
is a need to test the agent before all tables and variables are
implemented. In this case, the default instrumentation functions
are useful. The toolkit can generate default instrumentation
functions for variables as well as for tables. Consequently, a
running prototype agent, which can handle <CODE>set</CODE>, <CODE>get</CODE>,
<CODE>get-next</CODE> and table operations, is generated without any
programming.



<P>The agent stores the values in an internal volatile database,
which is based on the standard module <CODE>ets</CODE>. However, it is
possible to let the MIB compiler generate functions which use an
internal, persistent database, or the Mnesia DBMS. Refer to the
Mnesia User Guide and the Reference Manual, section SNMP, module
<CODE>snmp_generic</CODE> for more information.



<P>When parts of the MIB are implemented, you recompile it and
continue on by using default functions. With this approach, the
SNMP agent can be developed incrementally.



<P>The default instrumentation allows the application on the
manager side to be developed and tested simultaneously with the
agent. As soon as the ASN.1 file is completed, let the MIB
compiler generate a default implementation and develop the
management application from this.


<A NAME="10.3.1"><!-- Empty --></A>
<H4>10.3.1 Table Operations</H4>

<P>The generation of default functions for tables works for
tables which use the <CODE>RowStatus</CODE> textual convention from
SNMPv2, defined in STANDARD-MIB and SNMPv2-TC.


<P>
<TABLE CELLPADDING=4>
  <TR>
    <TD VALIGN=TOP><IMG ALT="Note!" SRC="note.gif"></TD>
    <TD>

<P>We strongly encourage the use of the <CODE>RowStatus</CODE>
        convention for every table that can be modified from the
        manager, even for newly designed SNMPv1 MIBs. In SNMPv1,
        everybody has invented their own scheme for emulating table
        operations, which has led to numerous inconsistencies. The
        convention in SNMPv2 is flexible and powerful and has been
        tested successfully. If the table is read only, no RowStatus
        column should be used.

    </TD>
  </TR>
</TABLE>
<A NAME="10.4"><!-- Empty --></A>
<H3>10.4 Atomic Set</H3>

<P>In SNMP, the <CODE>set</CODE> operation is atomic. Either all
variables which are specified in a <CODE>set</CODE> operation are
changed, or none are changed. Therefore, the <CODE>set</CODE> operation
is divided into two phases. In the first phase, the new value of
each variable is checked against the definition of the variable in
the MIB. The following definitions are checked:


<P>
<UL>

<LI>
the type

</LI>


<LI>
the length

</LI>


<LI>
the range

</LI>


<LI>
the variable is writable and within the MIB view.


</LI>


</UL>

<P> At
the end of phase one, the user defined <CODE>is_set_ok</CODE> functions
are called for each scalar variable, and for each group of table
operations.


<P>If no error occurs, the second phase is performed. This phase
calls the user defined <CODE>set</CODE> function for all variables.


<P>If an error occurs, either in the <CODE>is_set_ok</CODE> phase, or in
the <CODE>set</CODE> phase, all functions which were called with
<CODE>is_set_ok</CODE> but not <CODE>set</CODE>, are called with <CODE>undo</CODE>.


<P>There are limitations with this transaction mechanism. If
complex dependencies exist between variables, for example between
<CODE>month</CODE> and <CODE>day</CODE>, another mechanism is needed. Setting
the date to 'Feb 31' can be avoided by a somewhat more generic
transaction mechanism. You can continue and find more and more
complex situations and construct an N-phase set-mechanism. This
toolkit only contains a trivial mechanism.


<P>The most common application of transaction mechanisms is to
keep row operations together. Since our agent sorts row
operations, the mechanism implemented in combination with the
RowStatus (particularly 'createAndWait' value) solve most
problems elegantly.

<CENTER>
<HR>
<SMALL>
Copyright &copy; 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>