Re: agent X's role

On 11/14/05, Dave Shield <[email protected]> wrote:
>
> On Wed, 2005-11-09 at 16:53 +0000, Guillaume Desticourt wrote:
> > i did not really understood the interest of AgentX when
> > developping a subagent.
> > what can we do with agent X that you cannot with SNMP?
>
> There are two main problems with using SNMP directly
> as a subagent extension approach.
>
>
> > let say i have a midlevel manager which sends (forward) snmp
> > get to subagent.
>
> First question - how does the midlevel manager know to send
> requests to that subagent?
> SNMP is basically driven from the requesting side, so the
> midlevel manager would typically have to be manually configured
> to know about this new subagent.
>
> AgentX supports dynamic registration - the subagent could
> connect to the master agent, and offer to support a new
> area of the OID tree.



I don't see the point, the subagent should have to be manually configured to
connect to the midlevel manager, we have moved the conf file that's all...

> these "get" can be made with snmp, so why should i send
> > them with the agent X protocol?
>
> The other main advantage with AgentX is nothing to do with
> GET (or GETNEXT) requests. What happens if you have a *SET*
> request, that needs to be split over two or more proxied
> subagents? In particular, what happens when one of the
> proxied SET requests fails?
>
> Remember that SET processing should be all-or-nothing.
> If one half of the SET request fails, then the other
> half shouldn't be applied either. But that's not
> really possible with straight SNMP-based subagents
> AgentX support a multi-pass SET processing model, so
> can handle multiple validation, update and undo passes.
> It's not quite the same as the Net-SNMP internal SET
> processing model, but it's fairly close.
>
>
> Make sense?


yes, it does for the SET processing.
but I don't see in what aspect the use of AgentX makes the architecture more
"dynamic"...
thank you for your explaination.

regards,

--
Guillaume Desticourt