Hi Dave, thanks for you quick reply!
On 02/22/2010 05:40 PM, Dave Shield wrote: > On 22 February 2010 16:03, Gerlando Falauto > <[email protected]> wrote: > >> The subagent is a thread within a multi-threaded application; the actual >> data is stored as shared data (dynamic data structures) within the >> application itself. >> > My first question would be - how dynamic is the structure of the table? > I.e. how often do rows get added or deleted? > I would say, not that often. The configuration would be seldom changed in a production system. However, one thing I forgot to mention is that rows for most tables *can* and *will* be added and deleted through SNMP (i.e., most tables are *not* read only, and rows can be added as well). This would essentially happen at startup, with all rows for a half dozen tables being added pretty much at the same time; that's why the current solution does not scale well. > If the list of rows is reasonably stable, then the simplest approach > would probably be to use the 'mib2c.table_data.conf' template, > and use this to determine which row of the table is needed for > any given request. > The table handler could then use this index information to > retrieve the dynamic data for that row directly from the application. > I'm not quite sure I'm following you. You mean, _container_table_handler() calling _data_lookup() calling CONTAINER_FIND() (i.e., .find() in my custom container?). Or are you suggesting I don't even create a new container type (and use the standard container to keep just the indexes of the existing rows, and then use that information in my own handler (i.e, the one is passed to netsnmp_create_handler_registration())? I'm not even sure I got the difference between mib2c.container.conf and mib2c.table_data.conf... In that case, how would I handle locking anyway? I don't see any suitable injection point... > If the rows are more dynamic, then you'd probably have to > use the underlying application to identifying which row to use > as well. > A possibly suitable starting point might be the (relatively > new, and mostly untested) "mib2c.raw-table.conf" template. > Oh, I see. I didn't know about this one. This might be the best indeed. (The raw-est, the better... :-)). I can only see 2 drawbacks using this approach: 1) I need to implement my own locking state machine in my_own_table_row_handler() (e.g. lock at the beginning for GET, GETNEXT, SET_RESERVE1, unlock at the end of GET, GET_NEXT, UNDO, COMMIT... please correct me if I'm wrong...). -- I believe operations that span multiple substates (e.g. SET_RESERVE1...COMMIT) will always have a final transition where to perform unlock. 2) I may need to search the internal database several times for the same indexes (e.g., once for SET_RESERVE1, once for SET_RESERVE2 etc...). and for each column. This *should* not be an issue if the search operation is efficient enough, though (and the entire database is locked!). I believe I might also implement my own caching by storing the data pointer for the row somewhere within the netsnmp_request_info data structure... right? > Personally, I find that style of code easier to follow than the > MfD framework. Though that may have something to do with > the fact that I wrote both of them! > I agree with you. Having all code in a single .c file it's way less intimidating than having to jump around a few of them, just to mention one. At least if one has to get their hands dirty (I believe I do have to), understanding how the code is running and how the data is flowing. > Others swear by the MfD framework. It wouldn't be my > choice, but don't let that put you off. > I don't need to use MFD at all costs -- I spent quite some time already trying to understand the inner workings of this piece of software to stick with something that's been designed "for dummies" :-) Kidding aside, I also need a solution that's as close as possible to the existing code (which uses the mib2c.iterator_access.conf). So for all practical purposes, rather than moving all the way over to MFD, I'd prefer something in between (i.e., having all the custom code in a _access.c file, for instance). Since I'm quite new to all this, please let me know if I'm talking nonsense. :-) Thanks a lot! Gerlando ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
