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


       snmpkit - SNMP communication library


       #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);


       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.


       Ben Woodard <>


       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++.


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