"Kubat, Philip" <PKubat@charter.com> wrote:
> I am trying to use asynch snmp get calls with Scotty to retrieve a
> snmpv1 "RMON style" history table. The table has several variables
> stored in it with about 5,000 entries per variable. I am able to
> "for-next" my way through this table using synch snmp gets without a
> problem (well except for speed). So to increase the speed of this
> "query" I thought that asynch gets would help, but I seems that there
> are two problems with this:
> 1> I looks like all the request go out before any of the responses
> are proceeded, I tried to use "snmp wait" but I lost the outstanding
> responses.
Right. Responses are processed only when the event loop has again
control. You can use "snmp wait" for this but it is tricky.
> 2> If I let is run in on large loop I get either core, segmentation
> faults or "to many tk requests outstanding" error. If I keep the loop
> to about 150 cycles it works.
A core is a bad result. :-(
> So...I figure a work around would be to create separate job for each
> variable and let each job run simultaneously. But.. it seem that only on
> job can run at a time. Is this right, can several jobs for be
> processing at the same time?
No, scotty is not threaded. Jobs are just a handy tool to describe
things that should be done at regular intervals. If the interpreter
is busy doing other things, the jobs are simply delayed.
> How does Scotty deal with async gets? Many jobs? Does is process each
> response as it receives it? Has any one written a script that might
> lead me in the right direction?
The problem that you are trying to solve (sending lots of async
requests) has already been solved in the form of a new -window session
option. You can for example specify a window of size 10 and the
protocol engine will make sure that no more that 10 async requests are
actually on the wire. If your script creates more than 10 requests,
scotty will queue them until the number of active requests drops below
10. This solution is transparent to the script which can create
hundreds of async requests if it likes to do so.
The only problem with this solution is that it is included in my
Tcl7.5/Tk4.1 sources which are still not ready for public use.
(Please don't ask when they will be available. I am getting this
question many times a day and this delays the next version even
further. Thanks.)
Juergen