Convert to async MIB instrumentation API (#210)
MIB instrumentation API changed to allow for asynchronous
managed objects access. The MIB instrumentation methods
called by the state machine now return immediately and
resume once the callback is called.
The built-in SNMPv2-SMI objects are still synchronous.
This change is a prerequisite for fully asynchronous managed objects
implementation.
MIB instrumentation API changed to allow for asynchronous
managed objects access. Although built-in SNMPv2-SMI objects
are still synchronous, the MIB instrumentation API is async
what allows users to replace default MIB instrumentation
with their own, potentially asynchronous.
CommandResponder refactored to facilitate asynchronous
MIB instrumentation routines. The `readVars`, `readNextVars`
and `writeVars` MIB controller methods return immediately and
deliver their results via a call back.
SMI/MIB managed objects API overhauled for simplicity and
flexibility breaking backward compatibility.
Overhaul SMI/MIB instrumentation API
SMI/MIB managed objects API overhauled for simplicity and
flexibility breaking backward compatibility.
This change would allow way more control over custom MIB
managed objects and also is the prerequisite for
asynchronous MIB instrumentation.
asyncore and AsyncoreDispatcher respectively to provide better hint
to fellow devs on the underlying transport being used
- backward compatibility preserved through dummy asynsock symbols
* compiler.addMibCompiler() now supports ifAvailable and ifNotAdded flags
* rfc1902.ObjectIdentity() now always tries to instantiate and attach
MIB compiler to snmpEngine (if not done yet), also .addMibCompiler()
renamed to .addAsn1MibSource() to signify the fact that MIB compiler
is attached behind the scene
API redesign:
* MibVariable becomes ObjectIdentity and moves to pysnmp.smi.rfc1902
* ObjectType and NotificationType classes resempling corresponding MIB MACROs
implemented
* SNMP Standard Applications and examples modified to support ObjectType
and NotificationType parameters
sendmsg()/recvmsg() based socket communication what could be used,
among other things, in the context of a transparent SNMP proxy
application. Technically, the following features were brought
into pysnmp with this update:
* Sending SNMP packets from a non-local IP address
* Receiving IP packets for non-local IP addresses
* Responding to SNMP requests from exactly the same IP address
the query was sent to. This proves to be useful when listening
on both primary and secondary IP interfaces.
of SNMP engine inner workings. This is thought to be a generic
framework for viewing (and modifying) various internal states
of pysnmp engine. Previously introduced non-RFC APIs (like
getting peer's transport endpoint) will be gradually migrated to
this new framework.
receivers (identified by IDs) chosen by a public data routing method.
* SnmpEngine.[un]registerTransportDispatcher() methods now accept optional
receiver ID token to be used by transport dispatcher's data router. This
allows for multiple SNMP engines registration with a single transport
dispatcher.
* Relevant example added
Ilya Etingof
elie