Quoting Paul S <[email protected]>:
Quoting Wes Hardaker <[email protected]>:
Paul S <[email protected]> writes:
From packet analysis, I see that when bulkwalk() is called, the SNMP
library first queries that device's EngineID if this is not already
cached.
SNMPv3 does have a larger start up cost because of this while it does
engine synchronization. It would surprise me that bulkwalk is the only
function with this problem. Are you sure the same symptoms don't occur
with other types of requests (walks or even gets)?
Actually, I'm not sure as I'm only using bulkwalk(), but I have no
doubt that engine synchronisation must happen for walks/gets if its not
already cached.
I have now tested this further. Yes, both bulkwalk() and get() block
until the EngineID is obtained, or the device times-out.
Issue No.1:
This blocking means that I cannot call MainLoop(), which means the
hundreds of other devices whose SNMP is currently being handled by
MainLoop() are suspended until unavailable devices are timed-out.
This is having a major knock-on to my ability to run a regular
poll-loop should ever a number of devices be unavailable.
Issue No.2:
get() and bulkwalk() differ in the event of a failing to auto-obtain
an EngineID:
Upon timeout, get() performs a callback with an empty varlist, and the
session is closeable by setting undef. This releases the UDP socket,
which can be seen as freed by the OS.
bulkwalk() never performs the callback in the event it times-out
obtaining the EngineID. Subsequent setting such a session as undef
does NOT release the UDP socket. In an environment where devices are
polled in a loop, inaccessible devices will build up a large number of
"stuck" sessions and UDP sockets, ultimately leading to OS resource
starvation.
I am unable to see anything in SNMP.pm that can point me in a
direction to look next - any suggestions? Is this something handled
with the XS or the library itself? Are there any workarounds to
Issues 1 and 2 above, or would a code snippet help to demo the issue?
Many thanks,
Paul
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
