[Firstly, having asked a question, can you please *NOT* repeat the same question
again. The people who support this software are unpaid volunteers,
and answering
queries has to fit around other commitments - most particularly paid
employment.
Having sent your first message, please be patient and wait for a response.
Nagging us for an answer is not likely to improve your chances.
Thanks
]
On 14/12/06, Clement Hsu <[EMAIL PROTECTED]> wrote:
> I am Clement. when I try to develop my own mib, I found I do not
> realize the c template after mib2c, why you using switch (reqinfo->mode)
>
> switch (reqinfo->mode) {
>
> case MODE_GET:
This block is used to handle GET (and typically GETNEXT) requests for the
object in question - i.e. retrieving the current value.
> case MODE_SET_RESERVE1
> case MODE_SET_RESERVE2:
> case MODE_SET_FREE
> case MODE_SET_ACTION:
> case MODE_SET_COMMIT:
> case MODE_SET_UNDO
These are used to provide a multi-pass approach to handling SET requests
in an "atomic" manner - either all varbind assignments are applied, or none are.
The idea is that if things fail with one varbind, the whole SET request can be
unwound again, to restore the original state.
There's a discussion of this in section 8 of the file AGENT.txt.
This describes an earlier module API, so the structure of MIB module
code isn't quite what you'll be used to, but the basic model is the same.
> I don't understand what these cases do , and how to apply these to write my
> own function call
> even I have read snmpdemoapp and asyncapp, I still confused deeply.
Both of those files are concerned with the *client* side of a request - they
are applications, not agent modules. The code is completely different.
Don't confuse the two.
> Take data_set.c for instance , the code structure seems different,
Correct.
Although the table_dataset handler is concerned with the agent side,
it's a very specialised example, where the data_set helper can basically
do all of the work, and the MIB-specific handler is really just there to
deal with any special handling. This isn't really typical of most MIB
modules.
You don't say which version of the software you're using, but have a
look at the output of using 'mib2c.table_data.conf', 'mib2c.container.conf'
or 'mib2c.iterator.conf'. These three have a very similar handler structure,
with the switch statement shown above.
(Note that the MfD helper uses a completely different organisation, so
don't try to compare this with anything else).
> Furthermore, the notification.c declare oid and oid_length first,
Again, this is designed for use *within* the agent, so doesn't have to worry
about actually sending the request. All it needs is to provide the varbind
list - the session and PDU handling is dealt with by the main agent
infrastructure.
> but in snmpdemoapp, the first thing to do
> is creating snmp_session, then snmp_pdu, and variable_list.
That's because these are both client-side code, so have to do all the work
themselves - including creating the session and PDU structure.
Remember - any code generated for the agent is just part of a larger whole.
Any client-side code is effectively standalone.
Dave
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
