Hi Dave,
Thanks for your detailed explanation. I now understand your point.
But here are a few more questions (sorry to bother you so much):
1. The RFC says assignments within one SET is "as if simultaneous", does
it imply there's no sequence guaranteed? Further, does it imply "SET
redFish=xxx, blueFish=yyy" should have the same result as "SET
blueFish=yyy, redFish=xxx"? This is what you pointed out, I just wanted
to know on what you based (derived) your points.
2. I checked nsLogging, the main func is handle_nsLoggingTable(), one of
the parameters is "netsnmp_request_info *requests", it has a list of
varbinds, so you can work around (or ignore) the varbind order since you
can loop through the list to look for what you want. But how about if
varbinds belong to 2 mibs?
Say I have a SET as following:
SET fishTable.blueFish=xxx, birdTable.yellowBird=aaa,
fishTable.redFish=yyy, birdTable.greenBird=bbb
How will agent handle it? Will agent sort the varbinds first to form
2 SETs as following?
(1) SET fishTable.blueFish=xxx, fishTable.redFish=yyy
(2) SET birdTable.yellowBird=aaa,
birdTable.greenBird=bbb
Then send (1) to fishTable handler, wait for response, and send (2) to
birdTable handler, wait for response, then combine both responses and
return? How do you determine which handler is to be called first,
fishTable handler or birdTable handler?
In fishTable handler (and also birdTable handler), I can loop through
the varbind list to work around the sequence issue in case redFish has
to be set before blueFish. But how about if birdTable.yellowBird has to
be set before fishTable.redFish? (as indicated in the originally
received SET pdu), how do you enforce such order?
Thanks a lot,
Yong Chen
-----Original Message-----
From: Dave Shield [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 20, 2005 1:29 AM
To: Yong Chen (yongche)
Cc: net-snmp-users@lists.sourceforge.net
Subject: RE: Multiple sets in one pdu
On Wed, 2005-10-19 at 10:52 -0700, Yong Chen (yongche) wrote:
> But in ChangeLog, it says:
>
> Fixes:
> - the agent should properly handle requests in the right order.
> (e.g., restrict the agent to processing only one SET at a time)
Yes - that's concerned with the processing of two *different* SET
requests. Not the processing of two varbind assignments in the
*same* SET request.
If an agent receives:
SET oneFish = xxx
SET twoFish = yyy
then it should finish handling the "oneFish" assignment *before*
starting to look at the "twoFish" assignment.
If it receives:
SET redFish = xxx, blueFish = yyy
then it needs to process *both* assignments "at the same time".
> Also the ordering of varbinds in a SET request may have some
> significance because of dependency between the varbinds.
That's why handling SET requests properly is Non-Trivial!
The usual basic technique is to walk through the full list of
assignments, checking them individually and making any preparations for
acting on them.
Then walk through the list again, updating the individual assignments.
Then walk through the list *again*, checking that the final state is
consistent.
Then walk through the list again, tidying up.
If one assignment ("oldFish") relies on another ("newFish"), it is *NOT*
valid to assume that the varbinds occur in the most helpful order. The
agent *MUST* be able to process both
SET oldFish = xxx, newFish = yyy
and
SET newFish = yyy, oldFish = xxx
with *exactly* the same results in either case.
> Where can I find doc regarding the simultaneously processing SET
> assignments?
RFC 3416, section 4.2.5
See p22, second para.
> And I've been reading the code, but not finding the "as if
> simultaneously" processing of SETs. Can you please point me to the
> code?
There is no One Single Place where this is handled.
Each MIB will have different requirements for what assignments rely on
other ones, so the "as if simultaneous" code will be specific to each
particular MIB.
For an example, have a look at 'agent/mibgroup/agent/nsLogging'.
This shows one possible approach to ensuring that SEt requests will be
processed correctly, independent of varbind order.
I probably wouldn't write this in quite the same way now, but it show
the basic ideas.
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
