On 15 September 2011 13:24, <ramon.padi...@selex-comms.com> wrote: > Are you saying that the agent, under certain conditions on receipt of a > GETNEXT request, can invoke a call on my handler with a mode indicating get > (rather than getnext)?
In order to answer this properly, I'll have to explain a bit about the architecture of the agent framework. When the basic agent receives a GetNext request, it looks up the OID(s) and passes this request (as a GetNext) to the appropriate handler chain(s). Note that I said "handler chain" rather than simply "handler" - that's important. As far as the agent is concerned, this is a GetNext request, so is being handled as such. If the handler was registered using "netsnmp_register_handler", then this chain would simply consist of the MIB handler routine itself (and nothing else). So the handler would indeed receive a GetNext request. But in the vast majority of cases, the handler is not registered directly - instead the initialisation routine uses a different call (netsnmp_register_scalar, netsnmp_register_table_data_set, netsnmp_register_table_iterator, etc) Such "helpers" will set up a series of handlers, each dealing with some of the donkey-work of processing the request. So the scalar object helper can deal with checking whether the request is for the (sole) valid instance, and reject anything else. The core table helper looks after extracting the index values from the OID, and making them available to other more specialised table helpers (as well as the final MIB-specific handler). The iterator helper looks after searching the list of valid rows to determine the correct one. And so on. Now *some* of these helpers have enough information to determine which is the "lexicographically next" OID following the requested one, so can automatically adjust the request accordingly (updating the OID and index values). This effectively turns a GETNEXT request into an equivalent GET request. The MIB-specific handler can therefore ignore all the GetNext complications, and treat everything as an exact request (GET/SET). Other helpers (e.g. raw table) don't have this information, so pass the GetNext request down to the MIB-specific handler unchanged. In which case that handler must deal with all of this itself. > If so, how do I know what these conditions are so that I can code up my > handler accordingly? The basic question is which helpers (if any) you are using. Most of the mib2c templates use one of these "knowledgeable" table helpers, so don't need to worry about GETNEXT. The template code that is produced explicitly says this. The main exception is probably the raw table template, which simply handles the OID index parsing, but not much else. Whether you need to worry about GetNext depends on exactly how your module is being registered. Which is one reason why I suggested that you post the code. Dave ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
