Hi All,
First of all Thanks Dave for valuable support.
Well My requirement is like this:
1) I have a Agent and Sub-Agent Running on My system.( I am
using C coding )
2) While Run time , I have a multiple Sub-Agents implemented
by third party and they provide me a few API calls through which I can
community with there Sub-Agents.
3) At run time I will get a Root OID. based on that if any
query(Snmpget,Snmpgetnext) comes from another PC with that OID or Sub-tree of
the Root OID, I have to respond to it.
? -> Is it possible to implement?
** I have to collect the request packet(I don't know how to
collect the request ?) and send the packet (snmpget,snmpgetnext request) to
the Third Party Sub-Agents using there API.***
** Is there any way to collect the snmp getRequest packet and
collect the packet into a char buff( pdu of snmpget/snmpgetnext request). Pass
it to my avillable thired party API's and collect the return value and make a
Responce packet to send a Responce to the Request.
Thanks & Regards
manu
________________________________
From: Dave Shield <[email protected]>
To: ntwrkd <[email protected]>
Cc: Wes Hardaker <[email protected]>;
[email protected]
Sent: Thursday, February 19, 2009 2:17:55 PM
Subject: Re: extending the snmp agent through many exec's
2009/2/19 ntwrkd <[email protected]>:
> Why would I use one versus the other?
Well, one significant difference is in the handling of SET requests.
pass_persist() just has a single invocation for a SET request,
and each varbind is processed separately. That could lead to
problems if any of the assignments in the SET request could
potentially fail.
An embedded perl module uses the full multi-pass processing
(I believe), so can handle SET request reliably.
Another difference is that the pass_persist script will handle
each varbind separately for GET* requests as well. An embedded
perl module will be passed all of the related requests in one go.
That might allow for more efficient processing. Particularly if
retrieving the necessary data is relatively costly.
> When would extending the agent via C modules be viable?
A C-code module is more suitable for a stable MIB structure.
You said originally that
"[the OIDs]frequently change using a manual process."
If you're modelling a MIB table, and simply meant that rows
will be added and deleted dynamically, then a C module
would be a sensible approach.
But if it's the design of the MIB structure itself that's constantly
being changed, then a C-code module would involve frequent
re-coding and re-compilation.
(It's also not really in line with the SNMP ethos - MIBs are
expected to be stable)
Dave
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
