Subject: Re: agentx X pure snmp

From: Wes Hardaker <[email-masked]>
Date: 01 Mar 2000 15:26:04 -0800

>>>>> On Tue, 29 Feb 2000 21:39:04 -0300 (EST), Alexandre Briani Kieling <[email-masked]> said:

Alexandre> Is the implementation of extensible agents easier than the
Alexandre> traditional way of implement snmp agents?

The big win with AgentX (or any subagent protocol) is that multiple
applications can attach to one running agent.  With only one agent per 
machine, how do you manage the printing service, the ethernet devices, 
the web server, etc...  all with one program?  The only 2 answers are:

1) make them all one program (hah)
2) develop some sort of ability for them to talk to the running snmp agent.

Clearly, #2 is the only reasonable choice.

Alexandre> Is it true that many subagents have better performance than
Alexandre> one big snmp agent?

Probably not on a single processor system.  On a SMP system, probably.

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

---

From: Dave Shield <[email-masked]>
Date: Thu, 02 Mar 2000 10:08:53 +0000

I'll add my tuppen'orth to this discussion.

The main benefit of AgentX and similar technologies
(as various people have said) is the additional flexibility
this provides.  It makes it possible to extend the agent
without requiring an interruption in service.

  Another benefit, that hasn't been mentioned so far, is that
it provides a level of security between the various subagents.
A problem in one subagent, that might cause it to crash,
should have no effect on the others, so the overall agent
will continue to run (at a reduced level of service).
  In contrast, a problem in one area of a monolithic might
well bring the whole thing down.   Such a thing "ought not
to happen", but we all know that programs have bugs in them,
and ignoring the implications is foolish.

> Is the implementation of extensible agents easier than
> the traditional way of implement snmp agents?

Hmmmm.... not sure about this.
Are you talking about developing a complete agent "from scratch",
or extending an agent to include support for a new MIB.
Assuming the second, and a decent agent library framework, then
I doubt there'd be much to choose between them.  The main advantage
of the subagent route would be the limited effect of errors in the
new code, and not having to restart the main agent.
  (Though I'd typically do this on a non-standard port anyway, so
as not to affect the main agent).

  If you're talking about developing an agent from scratch, then
including subagent support is additional work over a monolithic
agent, and hence harder.
  Even if you're talking about a "pure subagent"  (which is easily
the simpler side of things!), a protocol like AgentX is more complex
than SNMPv1/2, so such an agent would probably be harder.
My gut feeling is that SNMPv3 swings things the other way, though I
haven't been involved in the UCD v3 work, so would hesitate to say
this categorically.  (But witness the fact that the UCD SNMPv3 work
involved three or four programmers full time, while the AgentX team
is li'l ol' me, mostly working of an evening or between other tasks!)

> Is it true that many subagents have better performance than one big snmp
> agent?

Probably not.  With subagents, you've immediately introduced an additional
overhead for processing a request.  I'd be horrified if the internal
dispatch mechanism of a monolithic agent was less efficient than the
AgentX handling!
  Even with a multi-processor system, it's probably not as simple as Wes 
makes out.  There's nothing inherent in a monolithic agent to prevent it
handling the various components of a request in parallel.  The UCD agent
isn't thread safe - but if it were, the architecture could be tweaked to
use separate threads for each requested object without too much work.
  *All other things being equal*, a monolithic agent will always be faster
than a subagent version.  Of course, subagents provide a very simple way
of parallelising the variable processing, without needing the careful
design required for a multi-threaded agent.

  The other option open to a monolithic agent is inter-module communication.
This could provide significant benefits - particularly for SET handling.
AgentX (and similar mechanisms) are inherently forced to use a multi-step
mechanism to achieve the "all-at-once" nature of SETs.  A monolithic agent
*could* potentially use direct communication to ensure that everything would
be handled correctly.  In fact, the UCD agent uses a multi-pass mechanism
(which is convenient when it comes to the AgentX implementation), but this
is not essential, in the same way as it is for subagents.

  As Richard points out, one performance benefit of the subagent approach
is that the subagent for a particular application can be embedded in the
binary for that application.  This then opens up greater possibilities for
efficient access to the necessary management data (which is always the
hardest bit of implementing a new MIB).   Essentially, you've given up
possible saving in the agent, for savings in the application.  This is
almost invariably a Good Deal!

> Is it better to develop a new module and compile it
> with a existent snmp agent like ucd-snmp or is it better to develop a
> extensible agent using agentX?

Well, the design of the UCD agent is such that the module developer
doesn't need to make that choice.  The UCD Module-API is the same in
both cases.
  I can't speak for any other development environment, but there's nothing
inherent in the handling of a request that forces this distinction.

>                                     Is there any situation where only
> extensible agents can do the job?

Off the top of my head - any situation where the necessary management
information isn't available externally to the application itself.
I'll re-iterate this point, that is almost always the hardest bit of
implementing a MIB module - how do you get the answers in the first place!

> I do not mean to bother you with so many questions.

S'OK - once I get started, it's hard to shut me up.
(Whaddaya mean, you'd noticed!)

Dave

---

From: Wes Hardaker <[email-masked]>
Date: 02 Mar 2000 09:35:18 -0800

>>>>> On Thu, 02 Mar 2000 10:08:53 +0000, Dave Shield <[email-masked]> said:

Dave> Even if you're talking about a "pure subagent" (which is easily
Dave> the simpler side of things!), a protocol like AgentX is more
Dave> complex than SNMPv1/2, so such an agent would probably be
Dave> harder.  My gut feeling is that SNMPv3 swings things the other
Dave> way, though I haven't been involved in the UCD v3 work, so would
Dave> hesitate to say this categorically.

I'd say that in general, agentx should always be easier to implement.
You don't ever have to implement any form of security in the
protocol.  This is what made implementing an SNMPv3 implementation so
much more difficult  (the protocol half is easy).

Dave> (But witness the fact that the UCD SNMPv3 work involved three or
Dave> four programmers full time, while the AgentX team is li'l ol'
Dave> me, mostly working of an evening or between other tasks!)

Actually, thats not quite true...  It was 3-4 part time programmers,
in general.  But, your single person work on agentx still shows how
much easier it is to just do agentx.