Now that we know ''where'' something needs to be registered, we ~~needs~~ to indicate ''what'' will actually handle the request. Information about the handler is stored in a struct, netsnmp_mib_handler, which indicates the ''handler''. It can store extra handler information and holds the handler access_method. The access_method is a pointer to the procedure that will actually fulfill and processes the SNMP requests for the registered OID location. For simple MIB handling, the access_method procedure is what the MIB coder will have to fill-in or write in order to handle the MIB requests. This is often done on a access_method per MIB table basis. The struct netsnmp_mib_handler definition follows:

Now that we know ''where'' something needs to be registered, we need to indicate ''what'' will actually handle the request. Information about the handler is stored in a struct, netsnmp_mib_handler, which indicates the ''handler''. It can store extra handler information and holds the handler access_method. The access_method is a pointer to the procedure that will actually fulfill and processes the SNMP requests for the registered OID location. For simple MIB handling, the access_method procedure is what the MIB coder will have to fill-in or write in order to handle the MIB requests. This is often done on a access_method per MIB table basis. The struct netsnmp_mib_handler definition follows:

Actually, most handler implementations aren't "singular". That is, they break the processing up into several steps and the resulting code is actually chained together in a ~~serious~~ of function calls, ending in the lowest-level handler's code. For example, there are ''helpers'' which are handlers that are designed to "sit in the middle" of a request and do some processing before the request gets to the lower level. This is useful if some of the code is so common that it's silly to implement the same code in a zillion low level handlers. For example, the most common problems are separating indexes and the column from a table's OID, caching data from slow operations, and sorting data into a standard SNMP order. So in the end, simple MIB objects (e.g. scalars) will likely have few steps in the handler chain, but complex MIB objects (e.g. tables) may have many handlers in the middle to "help out along the way".

Actually, most handler implementations aren't "singular". That is, they break the processing up into several steps and the resulting code is actually chained together in a series of function calls, ending in the lowest-level handler's code. For example, there are ''helpers'' which are handlers that are designed to "sit in the middle" of a request and do some processing before the request gets to the lower level. This is useful if some of the code is so common that it's silly to implement the same code in a zillion low level handlers. For example, the most common problems are separating indexes and the column from a table's OID, caching data from slow operations, and sorting data into a standard SNMP order. So in the end, simple MIB objects (e.g. scalars) will likely have few steps in the handler chain, but complex MIB objects (e.g. tables) may have many handlers in the middle to "help out along the way".

Most of these "middle-class" handlers will have their own registration functions that properly take the lower level's registration object and add themselves to the chain, and then call something higher up to complete the registration. We refer to this process as "injection". I.e., a registration function typically "injects" its own handler into the chain.