Re: How to support GetNextRequest in scotty agent where rows come and go?

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Tue, 25 Jul 1995 12:42:16 +0200

Hi!

"Peder Chr. Norgaard" <pcn@tbit.dk> said:

Peder> Thus my question No 1, cooked down to a general question:
Peder> there are lists of objects in the target that come and go without
Peder> telling the proxy agent. In the MIB these lists are represented with
Peder> conceptual tables. But the agent cannot maintain up-to-date knowledge
Peder> about which rows are present in a table at any given time; it needs to
Peder> ask the target via the private management protocol whenever a
Peder> GetRequest with explict index, or a GetNextRequest that would move
Peder> into a new row is to be answered.

Peder> The private management operations for moving from row to row
Peder> are simple; what I cannot figure out from the documentation and the
Peder> examples is where to hook the calls of these operations into the
Peder> scotty agent instance tree, creating rows as needed.

This is really interesting. I never thought about this problem before
and thats why there is no support for this. I think you are looking
for a mechanism to evaluate a Tcl script before the varbind list is
processed. Some other people also asked if they could get information
about PDUs to allow applications to show the SNMP messages on the
network (much like the snmp watch output). I am currently thinking
about adding a command option

snmp# trace [script]

where script is evaluated like a normal callback (using the same %
substitutions). It looks like this would solve both problems, as it
allows you to inspect the varbind list before the processing by the
agent starts. What do you think: Is this a useful extension and would
it help to solve your problem?

Peder> Also the proxy agent need to be able to react to certain kind
Peder> of exceptions from the private management protocol requests by
Peder> removing rows from the scotty agent instance tree, mapping the fact
Peder> that an object has disappeared. Again, I cannot figure out how to
Peder> hook these operations in the tree so that (for example) a GetRequest
Peder> to such a "dead object" results in a proper SNMP error message,
Peder> whereas a GetNextRequest to same object would result in the agent
Peder> moving to the next instance in the tree.

What is wrong with simply deleting the instance (by unsetting the
corresponding global Tcl variable)? A GetNextRequest to a non existing
instance should automatically select the lexicographic next object.

Juergen