Buz Owen <ado@BBN.COM> said:
Buz> If I create several snmp agent sessions in one scotty, they
Buz> seem to share the same instance bindings.
Yes, this is true.
Buz> For example:
Buz> # server code
Buz> set a [snmp session -port 1701 -agent {}]
Buz> set b [snmp session -port 1702 -agent {}]
Buz> $a instance sysName.0 na A
Buz> $b instance sysName.0 nb B
Buz> # client code - in another process on same host...
Buz> set s [snmp session -port 1701]
Buz> puts "1701 -> [$s get sysName.0]"
Buz> $s configure -port 1702
Buz> puts "1702 -> [$s get sysName.0]"
Buz> I get the following output
Buz> 1701 -> {1.3.6.1.2.1.1.5.0 {OCTET STRING} B}
Buz> 1702 -> {1.3.6.1.2.1.1.5.0 {OCTET STRING} B}
Buz> Both agents act like they were instanced to variable nb. I
Buz> suspect this is somehow related to my configuring -agent {}.
Buz> But it still seems like a bug.
Not really a bug. You are using only one interpreter and hence the
instance sysName.0 only exists once. It does make some sense to me to
allow multiple agents (perhaps with different parameters etc.) to
share the same instances. To get two independend agents, you would
need to create two different name spaces for them. This can be done by
creating a new interpreter and passing the interpreter handle to the
-agent option.
This is how things should work. However, there is a short-coming in
the implementation. Scotty currently only maintains one instance tree
for all Tcl interpreters. This needs to get fixed.
Buz> Anyway, is there any easy way to fix this?
It requires to rework some internal functions that deal with the
instance tree. Some care is needed to free the instance tree whenever
an interpreter is destroyed etc. It is not something I would do in an
hour - so this has to wait.
Buz> As an aside, I don't see why it is even meaningful for an snmp
Buz> agent be able to specify a safe tcl interpreter. An snmp
Buz> client can't send a tcl script to an snmp server.
Yes, this is true as long as your agent does not evaluate anything
stored inside of a SNMP instance/variable. You have to be careful to
avoid any direct or indirect calls to eval. The warning is just there
to remind you. (Just edit the source to get rid of it.)
Juergen