blob: 5a52135962b57b63e196fd0a03b6387767653c90 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
High-level SNMP
===============
There are a handful of most basic SNMP Applications defined by RFC3413 and
called Standard Applications. Those implementing Manager side of the system
(:RFC:`3411#section-3.1.3.1`) are Command Generator (initiating GET, SET,
GETNEXT, GETBULK operations) and Notification Receiver (handling arrived
notifications). On Agent side (:RFC:`3411#section-3.1.3.2`) there are
Command Responder (handling GET, SET, GETNEXT, GETBULK operations) and
Notification Originator (issuing TRAP and INFORM notifications). In
PySNMP Standard Applications are implemented on top of SNMPv3 framework.
There're two kinds of high-level programming interfaces to Standard SNMP
Applications: synchronous and asynchronous. They are similar in terms of
call signatures but differ in behaviour. Synchronous calls block the whole
application till requested operation is finished. Asynchronous interface
breaks its synchronous version apart - at first required data are prepared
and put on the outgoing queue. The the application is free to deal with
other tasks till pending message is sent out (by I/O dispacher) and
response is arrived. At that point a previously supplied callback function
will be invoked and response data will be passed along.
.. toctree::
:maxdepth: 2
/docs/v3arch/asyncore/oneliner/manager/cmdgen/contents
/docs/v3arch/asyncore/oneliner/agent/ntforg/contents
The asynchronous version is best suited for massively parallel SNMP
messaging possibly handling other I/O activities in the same time. The
synchronous version is advised to employ for singular and blocking
operations as well as for rapid prototyping.
.. toctree::
:maxdepth: 2
/docs/v3arch/asyncore/oneliner/manager/cmdgen/async.rst
/docs/v3arch/asyncore/oneliner/agent/ntforg/async.rst
SNMP security configuration is conveyed to SNMP engine via
:py:class:`~pysnmp.entity.rfc3413.oneliner.auth.CommunityData`
and :py:class:`~pysnmp.entity.rfc3413.oneliner.auth.UsmUserData`
classes:
.. toctree::
:maxdepth: 2
/docs/v3arch/asyncore/oneliner/security-configuration
Type of network transport SNMP engine uses along with transport
options is summarized by
:py:class:`~pysnmp.entity.rfc3413.oneliner.target.UdpTransportTarget`
and
:py:class:`~pysnmp.entity.rfc3413.oneliner.target.Udp6TransportTarget`
container classes:
.. toctree::
:maxdepth: 2
/docs/v3arch/asyncore/oneliner/transport-configuration
SNMP engine may serve several instances of the same MIB within
possibly multiple SNMP entities. SNMP context is a method to
unambiguously identify a collection of MIB variables behind
SNMP engine.
See :RFC:`3411#section-3.3.1` for details.
.. toctree::
:maxdepth: 2
/docs/v3arch/asyncore/oneliner/snmp-context
MIB variables represent a collection of managed objects,
residing in MIBs. Command Generator applications refer
to MIB variables and their values using
:py:class:`~pysnmp.smi.rfc1902.ObjectType` and
:py:class:`~pysnmp.smi.rfc1902.ObjectIdentity` classes.
.. toctree::
:maxdepth: 2
/docs/smi/mib-variables
SNMP Notifications are enumerated and imply including certain
set of MIB variables.
Notification Originator applications refer to MIBs for MIB notifications
that are represented by
:py:class:`~pysnmp.smi.rfc1902.NotificationType` class instances.
.. toctree::
:maxdepth: 2
/docs/smi/mib-notification-types
|
