Re: SNMPv3 bulkwalk()/callback blocking during background EngineID queries

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