bionic (3) libsnmpkit.3.gz

Provided by: libsnmpkit-dev_0.9-16ubuntu1_amd64 bug

NAME

       snmpkit - SNMP communication library

SYNOPSIS

       #include <snmpkit.h>

       SNMPSTRUCTFILLER *new_snmpstructfiller(SNMPSESSION *session);
       void delete_snmpstructfiller(SNMPSTRUCTFILLER *doomed);
       void snmpstructfiller_append(SNMPSTRUCTFILLER *sf, const char *oidstr,Tags tag, unsigned int offset);
       void snmpstructfiller_remove(SNMPSTRUCTFILLER *sf,const char *oidstr);
       void *snmpstructfiller_get(SNMPSTRUCTFILLER *sf,void *tobefilled);
       void *snmpstructfiller_get_next(SNMPSTRUCTFILLER *sf, void *tobefilled);

       SNMPTABLE *new_snmptable(SNMPSESSION *session,unsigned int structlen);
       void delete_snmptable(SNMPTABLE *doomed);
       void snmptable_append(SNMPTABLE *st,const char *oidstr,Tags tag, unsigned int offset);
       void snmptable_remove(SNMPTABLE *st,const char *oidstr);
       void *snmptable_get(SNMPTABLE *st,unsigned int *len);

DESCRIPTION

       snmpkit  is  a toolkit for doing SNMP queries of network connected devices. Its design is quite different
       than other snmp libraries such as those published by CMU and  UC  Davis.  Those  SNMP  libraries  largely
       preserve  the  OSI  model  in  their  programming  interfaces.  In  other  words  words  they expect that
       applications are going request objects by name from the MIBs. This introduces quite a lot of overhead  as
       the  objects  are  translated  in and out of the textual representations each and every time a request is
       done. They also assume that they are communicating with only one host. snmpkit is different,  because  it
       assumes  that the program is going to do be querying a few well known object on a large numbers of hosts.
       In other words the design of the library is exactly the opposite of the traditional  SNMP  libraries.  It
       doesn't  bother  with  all  the  MIB processing. It figures that the objects that the programmer wants to
       query are well known at the time of application development and therefore it is worth the  time  to  read
       the  MIB  by  hand and figure out what the OID for the object is and hard code that into the application.
       Since it assumes that you are going to be communicating with a large  number  of  hosts,  it  provides  a
       mechanism to allow many sessions on one socket.

       For  example,  say you want to find out the page count on all the printers you have enterprise wide. This
       amounts to 3500 different printers. One approach to this would  be  to  have  a  script  sequentially  go
       through  each  and  every printer and query it's page count. This would take a very long time because the
       out of those 3500 printers there would be a handful which are either turned off, broken, or for which you
       have  incorrect  information.  The  queries would be reasonably fast up until the point where you hit one
       which didn't respond and then your script would pause for quite some time before giving up and going onto
       the  next one. One solution to this problem would be to parallelize the task so that you start up several
       of the processes at once. In this case, the problem is that each one of those queries would  consume  one
       process  as  well  as  one  socket per host. Care would have to be execised so as not to not forkbomb the
       computer or run out of open file descritors. This approach allows you to multiplex all the  SNMP  queries
       on one socket.

       The  third  thing  that  is  different  about  snmpkit  is  that  it is optimized to fill structures with
       information. If you are fetching individual objects, you basically specify the objects that you want in a
       structure  and  tell  the structure filler where within the structure to put the object and then call the
       one of the get functions. If you want to fetch all the rows in a table it is very  similar.  You  specify
       the  what objects you want and their offsets into the structure and then you specify the structure length
       and it will fetch all the rows within the structure and return a vector of all  the  structures  and  the
       number of structures that are fetched.

AUTHOR

       Ben Woodard <ben@users.sourceforge.net>

BUGS

       Interface  bug -- The method of filling structures is really nasty code. It does all sorts of really evil
       futzing with pointers. It should probably be rewritten to call a function  which  puts  the  variable  in
       place. The thing is it took a long time to get right but now it works and it is very efficient.

       Interface  bug  --  The  snmptable  functions  return  a  pointer  to  a  dynamically allocated vector of
       structures. It should probably return some type of container instead.

       Interface bug -- With this interface there is no way  to  perform  any  sets.  The  snmpstructfiller  and
       snmptable should include functions to do sets.

       The  library  can  possibly throw different kinds of C++ execptions that won't be caught by the glue code
       and therefore it can cause your program to crash inexplicably.

       The library is implemented using a lot of hand crafted data structures. It should  be  rewritten  to  use
       many of the features available in libstdc++.

SEE ALSO

       snmpsock(3), snmpsession(3), snmpstructfiller(3), snmptable(3)