On Mon, 2005-12-12 at 19:08 -0800, Yong Chen (yongche) wrote:
> 1. Let's say I have SET pdu in UCD 4.x style as following:
>
> set a1=1 b1=2 c1=3 a2=4 b2=5 c2=6
> Does net-snmp agent change the order of varbinds? And why?
I haven't checked the internal processing, but it's quite
possible that varbinds are sorted into OID order, as part
of
> Is there anyway we can keep the order (of original pdu varbinds)?
No.
Since SET processing should happen "as if simultaneous", it's
bad practise to rely on a particular ordering. The two requests
SET a1=1 b1=2
and
SET b1=2 a1=1
should have exactly the same effect.
> 2. For example, I need to set 'b' before I can set 'a'.
> Basically this means in ACTION phase of write_method_a for a1,
> I can't do anything because b1 is not set yet.
Not quite - in the ACTION phase for a1, you can't do anything
unless you've already assigned b1.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But you are perfectly at liberty to make this assignment at an
earlier stage (e.g. RESERVE2).
> 3. One way is, ask client to send varbinds in the order that they can be
> set sequentially.
Nope - not allowd (see above).
> 3. Another way is, I can set 'a1' within 'b1' ACTION phase in
> write_method_b (right after 'b1' is set)
That's certainly an alternative approach.
Another possibility would be to assign a structure to hold
a working copy of the new row (say in the RESERVE2 pass),
and note which is the last varbind referring to that row.
Then the various ACTIVE processing can update the working
row (without touching the underlying subsystem), and it's
only the "last varbind" that would check the consistency
of the overall assigment, and update the underlying system.
> if 'a1' set fails, the error report will report 'b1'
> oid, not oid of 'a1', because it's in write_method_b().
As far as possible, you should try to check the validity of
assignments *before* applying them (i.e. in the RESERVE1 pass).
That's not always possible, but is certainly the ideal.
That way, the error can be associated with the correct varbind.
If it's a problem with inconsistent values (a1=1, b1='z')
then it doesn't actually matter which one gets the blame :-)
Dave
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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
