This is a discussion on RE: How to differentiate snmpwalk & snmpgetnext request ?? within the SNMP Users forums, part of the Networking and Network Related category; Thanks Dave for the detailed explanation. I overlooked the limitation of snmpwalk even after Valantina has given the example. Thanks, ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Thanks Dave for the detailed explanation. I overlooked the limitation of snmpwalk even after Valantina has given the example. Thanks, Suresh. -----Original Message----- From: dave.shield@googlemail.com [mailto:dave.shield@googlemail.com] On Behalf Of Dave Shield Sent: Thursday, May 08, 2008 3:40 PM To: Pamidipati Suresh-G20238 Cc: valantina arumugam; net-snmp-users@lists.sourceforge.net Subject: Re: How to differentiate snmpwalk & snmpgetnext request ?? 2008/5/8 Pamidipati Suresh-G20238 <venkatasuresh.pamidipati@emerson.com>: > Regarding the example you mentioned, why do you want to gather all the > instances of the table in the 1st getnext itself when snmpwalk is > given.? I believe that Valantina is concerned about the data changing while the walk is taking place. For example, consider a table containing two columns and (initially) two columns. Walking this table would look like: GETNEXT table --> this.1 GETNEXT this.1 --> this.2 GETNEXT this.2 --> that.1[*] GETNEXT that.1 --> that.2 GETNEXT that.2 --> endOfTable The client could then display the two rows quite happily: this.1 that.1 this.2 that.2 But suppose that a new row (3) was created at exact moment that the walk had got to the point marked[*] The remaining sequence of GETNEXT requests would then be GETNEXT that.1 --> that.2 GETNEXT that.2 --> that.3 GETNEXT that.3 --> endOfTable leaving the client with the inconsistent table this.1 that.1 this.2 that.2 (?) that.3 Alternatively, suppose the second row was deleted at[*] The walk would then finish GETNEXT that.1 --> endOfTable giving the client a table: this.1 that.1 this.2 (?) Loading all the data at the start of the walk would allow the client to retrieve a consistent set of information (albeit one that was slightly out of date). Dave __________________________________________________ ____________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __________________________________________________ ____________________ ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757...un.com/javaone _______________________________________________ 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/...net-snmp-users |
![]() |
| Thread Tools | |
| Display Modes | |
|
|