On Wed, 2005-06-15 at 10:30, Magnus Fromreide wrote:
> Is there any documentation available for the north end
> interface of Net-SNMP?

Probably not, no.
It's not an area that we've needed to provide much explanation for.
The number of people working at that level is relatively small,
and we've tended to use the source :-)

There is a man page for "snmp_read" (which is at the heart of
all this), but it's not really very informative.

> As of today the only north ends that are implemented is SNMP and
> AgentX. The SNMP north end seems to be quite strongly entangled
> in the library

That's fair comment.

The Net-SNMP project probably suffers somewhat from the
incremental nature of its development.  The current status
isn't the result of clear design - it's "just growed".
So the "north end" code was implemented within the library
because that was the whole purpose of the package - the
agent received SNMP requests, which were unpacked by the
SNMP library.

It was really only with the addition of the AgentX support
that we needed to consider other possible mechanisms for
receiving requests.


>  and the AgentX one is not easy to follow either.
> 
> I dream of an agent built from modules where we could have
> multiple north ends (SNMP, AgentX, SMUX, whatever) that
> connect to a dispatch layer

The framework for that is more-or-less in place, and the
AgentX code (however convoluted) is probably the best
starting point.

If you look at 'agentx/master.c' or 'agentx/subagent.c',
you'll see that they open the session handle using the
call "snmp_open_ex()"  (rather than the simple "snmp_open")

This allows them to specify new routines to convert an
incoming data stream into a PDU structure (agentx_parse),
and encode a PDU structure into a suitable stream ready
for sending out (agentx_build).

The same approach could be used with any other "north end"
module.


That basically assumes that the encoded stream will be read
from or written to some form of file descriptor.  But the
modular transport mechanism already support alternative
approaches (see the 'snmpCallback' transport where the encoded
stream is really only dummy data anyway).

I don't know enough about how Windows DLLs work to comment on
how well these two mechanisms might be adapted.  But I hope that
gives you a basic idea of how things currently fit together.


Dave



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to