On 11/05/07, Deybach Florent <[EMAIL PROTECTED]> wrote:
> > > Ok and what if the update is not ignited by the agent ? > > > i.e. The agent cannot fetch itself the values in another application but > > > the agent "register" on a server > > > and the server send periodically (but when never know when, so we have > to > > > listen) the values in order to update them in the MIB. > > > > Have a look at the 'register_readfd()' API. > > Ok, I get it: > > /* Here are the key functions of this unit. Use register_xfd to register > * a callback to be called when there is x activity on the register fd. > * x can be read, write, or except (for exception). When registering, > * you can pass in a pointer to some data that you have allocated that > * you would like to have back when the callback is called. */ > > int register_readfd(int, void (*func)(int, void *), void *); > > But what is fd (the first parameter) ? You originally said: > > > ... the server send periodically (but when never know when, so we have > > > to listen) the values in order to update them in the MIB. The server must send these values over some communication channel, which in the Unix world will boil down to a file descriptor. That file descriptor is what you pass to the 'register_readfd()' routine. Then whenever there's something waiting to be read on that file descriptor (i.e. new values from the server), the agent will invoke your callback routine to read this data and process it appropriately. It is a file descriptor > I don't understant the paragraph : > "When registering, you can pass in a pointer to some data that you have > allocated that you would like to have back when the callback is called" This is just making it possible to pass arbitrary data into the callback routine. That facility might be useful if you've got the same callback routine handling several file descriptors, or if the same callback routine can be registered in different situations (and you want to distinguish between them within the callback routine itself). But if you've just got the one scenario for invoking this callback routine, then you can ignore this paramter, and leave it null. > It means that I have access to it in the callback function ? Yes > Moreover, there are no examples of use of this function... No. It's not necessary for the basic operation of the Net-SNMP agent, so we don't actually use it. This mechanism was provided as a general way to hook into the main event-processing loop - in case developers had some "non-SNMP" communication that they needed to support. I.e. precisely the scenario you've outlined. Dave ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ 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
