[AGENT++] Session

[Frank Fock]

Hi Marcus,

Almost missed your posting! Really late - here is my response:
Another "solution" for the session problem, would be to use TCP
instead of UDP, but this would need some implementation effort
for SNMP++ (and AGENT++).

With minmal effort, your solution 1 is my favorite. The "drawback"
of the unsecure report can be avoided if the manager does not set
the reportable flag.

Best regards,
Frank

Fehde, Marcus wrote:

>Frank,
> 
>we're obliged to implement a session concept for exclusive access to our SNMP agent by one management application at a time. 
>Up to now, we followed two different approaches which have one thing in common:
>There's a particular MIB object that provides a lock string. This lock has to be retrieved in order to generate the information required by a management application to identify itself as the session owner. This object isn't any longer readable after the session was acquired and hence other managers can't acquire the session.
>The acquired information are used for
>1. generating a particular user account. Both sides know the generation rules, but only the lock owner and the agent know the key. Within the agent USM and VACM are configured accordingly. One disadvantage of this approach is that (e.g. after a timeout) a subsequent request would cause an unsecured report (unknownUser).
>2. generating a particular context name (or contextEngineId). Every incoming PDU is examined whether it contains the secret session context and if so the context is exchanged for the default context. This means that we would have something like a virtual context. The biggest disadvantage of this approach is that this would have a big impact on the library since the context is used on multiple places.
> 
>We're aware that these approaches would prevent from using standard management tools or at least complicate it. But this doesn't matter since our agent is supposed to be used with our own management tools.
>Anyhow we don't want to change the general SNMP standard at all. All company specific extensions shall base on the official standards.
> 
>Do you have any suggestions, e.g. different approaches or comments on our approaches?
>Thank you in advance.
> 
>
>Best regards/Mit freundlichen Gruessen 
>
>Marcus Fehde
>Dipl. Ing. Technische Informatik (FH)
>
>Research & Development 
>Business Unit Anaesthesia 
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>
>DRÄGER MEDICAL 
>
>Dräger Medical AG & Co. KGaA 
>Moislinger Allee 53-55 
>D-23542 Lübeck 
>
>Tel:  + 49-451-882-3646 
>Fax: + 49-451-882-4410 
>E-mail: marcus.fehde at draeger.com 
>www.draeger-medical.com 
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>
> 
> 
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>AGENTPP mailing list
>AGENTPP at agentpp.org
>http://agentpp.org/mailman/listinfo/agentpp
>  
>