hai, M> I know that i will get queries for only certain columns which will be > M> always walks. > > No, you don't know that. You may know that *your* management application will > only send walks for columns, but you have no idea what some other user who has > access to your agent will do. Thus breaking the SNMP specs is a bad idea. >
I completely understand that. Actually we were doing the proper thing, that is, whenever end of column is reached always try the next column and so on until a proper value is obtained. It was working properly. But we have a manager application which shows all these values in GUI. Because of remote communication, it was taking time. It was required to get the latest values and not the cached ones whenever a new walk for a column is given. Then to reduce time taken people here suggested that why don't we avoid requests for next column. This was suggested primarily because this agent is going to be used *only* by our manager application and no one else which gives only walks and gets. For gets we will get only the value for the requested instance and so no problem. > M> At the end of the walk even though next column values can be > M> obtained through remote communication, i want to avoid this due to the > M> time taken. > > If this is your goal, there are other options. Add an object that returns the > number of rows in the table. The manager can get this object, then issue a > GETBULK for the column, and specify the exact number of rows to get. That > should prevent the extra get-next w/out breaking the agent for other apps. > Actually what we are doing is a proxy agent for some device of a third party who have defined their mib. So we can't add a new object. Currently we support GET and GETNEXT only. Anyway to support GET-BULK using the table handler what should we do? Should we add bulk-to-next handler? Currently we are using netsnmp_create_handler_registration() and netsnmp_register_table() to register for tables. > Also, depending on how you get your data, caching can be a big help, even if > it > is for a short time. If you are trying to optimize for periodic walks, you can > cache for just long enough to complete the walk (1 sec, 5 sec?). > This is the last resort when we can't achieve our desired thing even if violates the SNMP standard. > M> Same case with requests for which responses are not received > M> within a certain time. Anyway the manager would have timed out and so i > M> don't want to have another request given by the agent for the next > M> mibtree. > > What if the manager increases it's timeout? Again, guessing what users will do > usually ends up getting you in trouble when they do something you don't > expect. > Again in the manager application, the operators expect the values to be shown somewhat quickly. Otherwise they complain and our people want to avoid that. > M> > That's not necessarily true. With a little work you can use caching > M> > to work with array-user. If you upgrade to 5.2.1, you can use the new mfd > M> > helper too. > M> > M> Can i get some documentation and examples for mfd helper? > > http://www.net-snmp.org/tutorial/tutorial-5/toolkit/mfd/ > > M> Does it support contexts and delegation? > > Not yet, but it should. But I can work with you to get it working if you are > interested. > Surely. But i will get some idea of mfd before starting. I will inform you once i am done. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
