| 1 |
NAME |
| 2 |
AnyEvent::SNMP - adaptor to integrate Net::SNMP into Anyevent. |
| 3 |
|
| 4 |
SYNOPSIS |
| 5 |
use AnyEvent::SNMP; |
| 6 |
use Net::SNMP; |
| 7 |
|
| 8 |
# just use Net::SNMP and AnyEvent as you like: |
| 9 |
|
| 10 |
# use a condvar to transfer results, this is |
| 11 |
# just an example, you can use a naked callback as well. |
| 12 |
my $cv = AnyEvent->condvar; |
| 13 |
|
| 14 |
# ... start non-blocking snmp request(s)... |
| 15 |
Net::SNMP->session (-hostname => "127.0.0.1", |
| 16 |
-community => "public", |
| 17 |
-nonblocking => 1) |
| 18 |
->get_request (-callback => sub { $cv->send (@_) }); |
| 19 |
|
| 20 |
# ... do something else until the result is required |
| 21 |
my @result = $cv->wait; |
| 22 |
|
| 23 |
DESCRIPTION |
| 24 |
This module implements an alternative "event dispatcher" for Net::SNMP, |
| 25 |
using AnyEvent as a backend. |
| 26 |
|
| 27 |
This integrates Net::SNMP into AnyEvent: You can make non-blocking |
| 28 |
Net::SNMP calls and as long as other parts of your program also use |
| 29 |
AnyEvent (or some event loop supported by AnyEvent), they will run in |
| 30 |
parallel. |
| 31 |
|
| 32 |
Also, the Net::SNMP scheduler is very inefficient with respect to both |
| 33 |
CPU and memory usage. Most AnyEvent backends (including the pure-perl |
| 34 |
backend) fare much better than the Net::SNMP dispatcher. |
| 35 |
|
| 36 |
A potential disadvantage is that replacing the dispatcher is not at all |
| 37 |
a documented thing to do, so future changes in Net::SNP might break this |
| 38 |
module (or the many similar ones). |
| 39 |
|
| 40 |
This module does not export anything and does not require you to do |
| 41 |
anything special apart from loading it *before doing any non-blocking |
| 42 |
requests with Net::SNMP*. It is recommended but not required to load |
| 43 |
this module before "Net::SNMP". |
| 44 |
|
| 45 |
GLOBAL VARIABLES |
| 46 |
$AnyEvent::SNMP::MAX_OUTSTANDING (default: 50, dynamic) |
| 47 |
Use this package variable to restrict the number of outstanding SNMP |
| 48 |
requests at any point in time. |
| 49 |
|
| 50 |
Net::SNMP is very fast at creating and sending SNMP requests, but |
| 51 |
much slower at parsing (big, bulk) responses. This makes it easy to |
| 52 |
request a lot of data that can take many seconds to parse. |
| 53 |
|
| 54 |
In the best case, this can lead to unnecessary delays (and even |
| 55 |
time-outs, as the data has been received but not yet processed) and |
| 56 |
in the worst case, this can lead to packet loss, when the receive |
| 57 |
queue overflows and the kernel can no longer accept new packets. |
| 58 |
|
| 59 |
To avoid this, you can (and should) limit the number of outstanding |
| 60 |
requests to a number low enough so that parsing time doesn't |
| 61 |
introduce noticable delays. |
| 62 |
|
| 63 |
Unfortunately, this number depends not only on processing speed and |
| 64 |
load of the machine running Net::SNMP, but also on the network |
| 65 |
latency and the speed of your SNMP agents. |
| 66 |
|
| 67 |
AnyEvent::SNMP tries to dynamically adjust this number dynamically |
| 68 |
upwards and downwards. |
| 69 |
|
| 70 |
Note that you can use Net::SNMP::XS to speed up parsing of responses |
| 71 |
considerably. |
| 72 |
|
| 73 |
$AnyEvent::SNMP::MIN_RECVQUEUE (default: 4) |
| 74 |
$AnyEvent::SNMP::MAX_RECVQUEUE (default: 64) |
| 75 |
These values specify the minimum and maximum receive queue length |
| 76 |
(in units of one response packet). |
| 77 |
|
| 78 |
When AnyEvent::SNMP handles $MAX_RECVQUEUE or more packets per |
| 79 |
iteration it will reduce $MAX_OUTSTANDING. If it handles less than |
| 80 |
$MIN_RECVQUEUE, it increases $MAX_OUTSTANDING. |
| 81 |
|
| 82 |
This has the result of adjusting the number of outstanding requests |
| 83 |
so that the recv queue is between the minimum and maximu, usually. |
| 84 |
|
| 85 |
This algorithm works reasonably well as long as the responses, |
| 86 |
response latencies and processing times are the same size per packet |
| 87 |
on average. |
| 88 |
|
| 89 |
COMPATIBILITY |
| 90 |
This module may be used as a drop in replacement for the |
| 91 |
Net::SNMP::Dispatcher in existing programs. You can still call |
| 92 |
"snmp_dispatcher" to start the event-loop, but then you loose the |
| 93 |
benefit of mixing Net::SNMP events with other events. |
| 94 |
|
| 95 |
use AnyEvent::SNMP; |
| 96 |
use Net::SNMP; |
| 97 |
|
| 98 |
# just use Net::SNMP as before |
| 99 |
|
| 100 |
# ... start non-blocking snmp request(s)... |
| 101 |
Net::SNMP->session ( |
| 102 |
-hostname => "127.0.0.1", |
| 103 |
-community => "public", |
| 104 |
-nonblocking => 1, |
| 105 |
)->get_request (-callback => sub { ... }); |
| 106 |
|
| 107 |
snmp_dispatcher; |
| 108 |
|
| 109 |
SEE ALSO |
| 110 |
AnyEvent, Net::SNMP, Net::SNMP::XS, Net::SNMP::EV. |
| 111 |
|
| 112 |
AUTHOR |
| 113 |
Marc Lehmann <schmorp@schmorp.de> |
| 114 |
http://home.schmorp.de/ |
| 115 |
|
