[SNMP4J] need suggestion..

[Frank Fock]

Hi Jackie,

Wenchun (Jackie) Cheng wrote:

>Hi to all,
> 
>Suppose I am implementing a high performance SNMP monitor application which
>usess snmp v3 to poll several devices. And the snmp v3 users on the device
>may not be using the same auth/priv passphrases. 
> 
>For example, 
>on device group A,
>the user is "snmpuser" and the auth/priv passphrases are
>"passauth"/"passpriv".
> 
>on device group B,
>the user is "snmpuser" and the auth/priv passphrases are
>"authpass"/"privpass".
> 
>Since there is only one instance of SecurityModels to hold v3 user model, it
>can only hold one generic (not associated with any authoritiveEngineID)
>UsmUser with name "snmpuser". It seems like I can only add v3 user on the
>  
>
Have you seen the addUser method in USM that takes the engineID too? See:
http://www.snmp4j.org/doc/org/snmp4j/security/USM.html#addUser(org.snmp4j.smi.OctetString, 
org.snmp4j.smi.OctetString, org.snmp4j.security.UsmUser)

By adding each user specifically to each target's engine ID, it should 
be no problem
to access them.

>fly, which means add the user before sending any snmp packet to the target.
>  
>
Why should "adding on the fly" work if adding the user before would not?

>Other than this method, can anyone suggest what the best way (or possible
>way) to implement the system?
>  
>
See above. The USM is not a singleton! It has a public constructor. However,
there exists a singleton registry for security models named 
SecurityModels to facilitate
security model access within a SNMP4J application. For most use cases, 
this approach
should be sufficient. If you need more than one USM, you can subclass 
the SecurityModels
class and provide a public constructor and then set such a instance to 
your MPv3.

> 
>As a side question, what may be the reason to implement SecurityModels as a
>singleton?
>  
>
As explained above, for most uses a singleton is best. If you need 
special handling, then
subclass it.

Hope this helps.

Best regards,
Frank