Wes Hardaker wrote: >>>>>> "RB" == Rob Bloodgood <[EMAIL PROTECTED]> writes: > > RB> However, during development I discovered that when using SNMPv3, the > RB> constructor blocks until an authentication reply is received (or times > RB> out). > > I believe you're confusing a few things: > > 1) the constructor doesn't authenticate things > 2) the constructor does create SNMPv3 keys, which can be > mildly-computationally intensive compared to creating non-SNMPv3 sessions > 3) the constructor does do engineID probing > > You can't short-cut the key creation (it'll need to spend the CPU time > at some point or another) > > The engineID probing (it sends a packet to the agent and then waits for > the response) may be blocking, you're right. I believe the library > actually can delay the engineID probing and it may make it possible for > it to be asynchronous. I wasn't the one who implemented that code; so I > forget ;-)
This sounds exactly what I'm looking for... with regular queries and a valid session object, I can send a packet and then "go about my business" until the socket with the response goes hot (or a timeout fires). However, the engineID probing runs, as you said, synchronously during the constructor. > However, there is nothing in theory that would make it impossible to do > what you want. I don't remember the current state of the library and > how much work it would take. Heh, well I made the decision to limit my interface to that provided by the Perl API (SNMP.pm/xs), because otherwise I would have had to cook my own compilation step (including locating the compiler and the devel headers) which would have prevented widespread deployment of my module. However, if something entered the "official" module's source, I could certainly take advantage of it when it was available. Specifically, I would like to be able to defer the probing in the constructor, then probe asynchronously, even if I have to be extra careful not to issue any queries until the probe is complete. And while I'm at it, A question for somebody who works on the Perl API: Why is it so hard to get at the specific filehandle associated with a given session object? I finally realized I could take 'before' and 'after' snapshots of the list of active filehandles when calling the constructor... but a direct API call (with whitespace, I think 8 lines of C) would have made more sense. > RB> Additionally, if authentication fails, the constructor returns undef and > RB> I haven't been able to figure out where the error message (or code) > RB> explaining this is accessible (altho it shows up as part of the > RB> $SNMP::debugging output). Is there a (potentially global) way to access > RB> this data, and return an accurate error message of some kind? > > Something else I vaguely remember running into but forget the answer to > (sorry). Beuhler? (Does somebody know? :-) L8r, Rob ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
