Re: Multiple MibWalks

Juergen Schoenwaelder (schoenw@cs.utwente.nl)
Wed, 6 Nov 1996 18:01:13 +0100

Thorsten Geelhaar <tgeelhaa@funghi.Materna.DE> said:

Thorsten> I want make a snmp request like this :

Thorsten> proc Multiple_Walk { vbl1 err } {

Thorsten> if {$err == noError} {
Thorsten> snmp1 getnext $vbl1 {
Thorsten> snmp2 walk vbl2 1.2.3.4.1 { .. }
Thorsten> Multiple_Walk "%V" "%E"
Thorsten> }
Thorsten> }

Thorsten> snmp1 getnext 1.2.3.4 { Multiple_Walk "%V" "%E"}

Thorsten> My Question is : Would the complete walk executed
Thorsten> between the seperate getnext requests or could it be
Thorsten> that both will be mix. So that you get for example the
Thorsten> answer for the first getnext and then one for a part
Thorsten> of the walk and the second getnext and so on.

Execution will happen as follows: First, the asynchronous getnext in
the last line is executed. This will send a packet to the agent. Once
an answer is received and the Tcl interpreter enters the event loop,
the Multiple_Walk procedure is invoked. If there was no error, the
asynchronous getnext in the Multiple_Walk is executed. This will again
send a packet to the agent. The Tcl interpreter will now return from
the Multiple_Walk procedure. Once an answer for the second getnext is
received and the Tcl interpreter enters the event loop, the walk
command will be executed. This is a synchronous operation which means
that no events are processed during the walk command. The Tcl
interpreter will call the Multiple_Walk procedure when the walk
command has finished, passing it the result of the second getnext
request. If there was no error, the asynchronous getnext in the
Multiple_Walk is executed. This continues until an error stops this
loop.

Note however that synchronous commands can eat up some responses for
asynchronous commands since the implementation does not bother to
queue responses for asynchronous SNMP operations while processing a
synchronous command. This is usually not a problem since you can loose
packets on the network anyway and hence the next retry will usually
succeed (Tnm will only retry if the Tcl interpreter enters the event
loop again - which means that the synchronous command has finished).
But this reasoning is more an excuse for being a bit too lazy.

Does this answer your question? (Now I will start to think about why
people want to build a loop like this...)
Juergen

--
Juergen Schoenwaelder schoenw@cs.utwente.nl http://www.cs.utwente.nl/~schoenw
Computer Science Department, University of Twente,   (Fax: +31-53-489-3247)
P.O. Box 217, NL-7500 AE Enschede, The Netherlands.  (Tel. +31-53-489-3678)