Dave, Sorry coming back to this topic again, how do I walk through the list in 5.x? for instance, the nsLogging example has handle_nsLoggingTable(), is that the forth input parameter: 'requests', has all incoming varbinds? I just go through it via "request->next"?
Actually I'm doing SET for a table in UCD 4.x style, then how do I walk through the incoming varbinds for a SET? Thanks a lot, Yong Chen The usual basic technique is to walk through the full list of assignments, checking them individually and making any preparations for acting on them. RESERVE1 ? Then walk through the list again, updating the individual assignments. RESERVE2 ? Then walk through the list *again*, checking that the final state is consistent. ACTION ? Then walk through the list again, tidying up. COMMIT ? -----Original Message----- From: Dave Shield [mailto:[EMAIL PROTECTED] Sent: Thursday, October 20, 2005 1:29 AM To: Yong Chen (yongche) Cc: net-snmp-users@lists.sourceforge.net Subject: RE: Multiple sets in one pdu On Wed, 2005-10-19 at 10:52 -0700, Yong Chen (yongche) wrote: > But in ChangeLog, it says: > > Fixes: > - the agent should properly handle requests in the right order. > (e.g., restrict the agent to processing only one SET at a time) Yes - that's concerned with the processing of two *different* SET requests. Not the processing of two varbind assignments in the *same* SET request. If an agent receives: SET oneFish = xxx SET twoFish = yyy then it should finish handling the "oneFish" assignment *before* starting to look at the "twoFish" assignment. If it receives: SET redFish = xxx, blueFish = yyy then it needs to process *both* assignments "at the same time". > Also the ordering of varbinds in a SET request may have some > significance because of dependency between the varbinds. That's why handling SET requests properly is Non-Trivial! The usual basic technique is to walk through the full list of assignments, checking them individually and making any preparations for acting on them. Then walk through the list again, updating the individual assignments. Then walk through the list *again*, checking that the final state is consistent. Then walk through the list again, tidying up. If one assignment ("oldFish") relies on another ("newFish"), it is *NOT* valid to assume that the varbinds occur in the most helpful order. The agent *MUST* be able to process both SET oldFish = xxx, newFish = yyy and SET newFish = yyy, oldFish = xxx with *exactly* the same results in either case. > Where can I find doc regarding the simultaneously processing SET > assignments? RFC 3416, section 4.2.5 See p22, second para. > And I've been reading the code, but not finding the "as if > simultaneously" processing of SETs. Can you please point me to the > code? There is no One Single Place where this is handled. Each MIB will have different requirements for what assignments rely on other ones, so the "as if simultaneous" code will be specific to each particular MIB. For an example, have a look at 'agent/mibgroup/agent/nsLogging'. This shows one possible approach to ensuring that SEt requests will be processed correctly, independent of varbind order. I probably wouldn't write this in quite the same way now, but it show the basic ideas. Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ 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
