Re: Connect 1 agent/application to several snmpd/master

Hi Wes,

Thanks a lot for reply,
The design proposal does not change the single threading model put in place
on subagent Agentx side.
As I read your email and the RFC deeper, you may refer to transaction ID
that is self to a single SNMP management request, and that may not be
somehow "interrupted".
I assume that those locks do not deal with separate MIB contexts on the
same session.

What about adding some restrictions in the use case I depicted earlier ?
- A registered MIB entity should not be shared across more than one
connection.

I think this would mean that a SNMP management request would never be
"interrupted" by an other SNMP management request on the same context.
This check could be done when parsing the configuration.

agentxsocket unix:/var/run/netns/test/agentx_snmpd    name1,name2,name3
agentxsocket unix:/var/run/netns/test2/agentx_snmpd
name1                      <--- would be refused because name1 already
previously attached
agentxsocket unix:/var/run/netns/test3/agentx_snmpd    name4,name5,name6
<--- would be accepted

In fact, in proposed model, I assume I have multiple agentx connections
sharing the same process memory, but not sharing same objects, sessions.

Regards,

Philippe

On Fri, Nov 13, 2020 at 12:51 AM Wes Hardaker <
[email protected]> wrote:

> Philippe Guibert <[email protected]> writes:
>
> > Thanks for letting me know if that approach should be considered or
> > not,
>
> Personally, I'll have to think a lot about it.  But in general, agentx
> was designed (and if you haven't read the RFC for it, you probably
> should to get a better understanding of the protocol's design).
>
> Specifically, there needs to be locking issues in the subagent to
> consider when attached to multiple upstream parent agents.  SNMP SETs,
> in particular, go through a multi-phase transition to ensure you can
> safely perform and/or undo a SET.  Right now, that handling is done in
> the parent agent to ensure that only one SET is handled at a time.
>




>
> I suspect there are some other issues to think about too.
>
> --
> Wes Hardaker
> Please mail all replies to [email protected]
>

_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders