#67 SnmpV3MessageProcessingModel: don't cache contextEngineId

[Bernd Deichmann]

Following Szenario:
- working for a longer time with an application specific custom contextEngineId.
- at some point in time the cache expires and now the custom contextEngineId is in cache.
- later application starts to use default contextEngineId again(None value).
- SnmpV3MessageProcessingModel now uses the cached custom contectEngineId, but should use value of snmpEngineId.

I think the contextEngineId should not be cached (RFC3412, 7.1.4 is very unspecific here).

And why does the cache expire at all? I do not see the benefit of it. In my application I could fix the contextEngineId problem by resetting the expiration timer after each call. This avoids recaching and the contextEngineId of first contact stays in cache.

[Ilya Etingof]

I think the problem is as follows:

* every time SNMPv3 MP receives a message from a remote entity it caches remote entity's ContextEngineId (binding it with remote entity's transport address)
* when your app attempts to use remote entity's EngineId discovery feature (by passing NULL ContextEngineId), SNMPv3 MP takes previously learned ContextEngineId from cache and use it, effectively skipping the discovery phase and using custom EngineId while it happens to be in cache.

Cache expiration aims at two purposes:

* conserving local memory what's the case when the engine briefly talks to a very large number of other engines
* remote engine migrates to the same transport address previously used by some other engine

The fix I propose is to cache remote entity's ContextEngineId only when they come with REPORT PDU what is an [indirect] indication of the EngineId discovery (rather than normal traffic) is in progress.

Please try the attached patch to pysnmp and let me know if it passes your tests.

[Ilya Etingof]

[Bernd Deichmann]

As far as I understand SNMP only the snmpEngineId gets detected, not the contextEngineId. The manager side uses the detected snmpEngineId value if it addresses the default context or something different if a different context is addressed.
If this is right I still see no reason for caching the contextEngineId.

[Ilya Etingof]

That's right, it is actually EngineId that gets cached and later used under the name of ContextEngineId. My fix effectively disables (user-supplied) ContextEngineId caching.

[Ilya Etingof]

And the question remains - does this fix work in your setup?

[Bernd Deichmann]

The fix works, thank you!