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

Peder Chr. Norgaard (pcn@tbit.dk)
Tue, 25 Jul 1995 22:56:40 +0200 (CDT)

>
> Hi!
>
> "Peder Chr. Norgaard" <pcn@tbit.dk> said:
>
> 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?

Hello Juergen:

This may very well be a useful extension; it may even solve my problem
but in a *very* inelegant way. I would have to build one jumbo script
with knowledge about both the entire MIB and all the functions to lookup
next rows. I would not be able to use knowledge and techniques which
I am quite certain, are already present in the current implementation.

I would very much prefer a solution that looks more like a natural
extension of the current specification, and I will be happy to discuss
the specification. I can also do a limited amount of coding and testing,
provided you wish me to do so - this problem is a real show stopper for my
project! An initial discussion follows.

--

One quite simple change, solving my problem with respect to the GetRequest would be a change of the semantics of the implementation of GetRequest. For now, the implementations looks into the instance tree and reports noSuchName if the specified instance is not present. I have not checked what happens if the "get" callback removes an instance after the agent has decided that it is there!

I suggest that the relevant callback commands are called always, regardless of the presence of the specified instance. *After* the callbacks have run, the agent can test for presence of instance and report noSuchName if the instance is still not there (or if it has been removed by the callback, referring to the discussion below).

--

No doubt, correct processing of GetNextRequests is a bit more complicated. I have been thinking a bit: there must be, somewhere in the current implementation, a mechanism for getting next instance from the instance tree. What we need is a way to specify callbacks to be invoked by this mechanism when it searches past instances whose presence may change over time - that is, elements of conceptual rows. Several such callbacks may be called in one search, if the search passes wholly empty tables, or starts with the a fully specified instance that happens to be in the last row of a table.

I suggest you implement a binding like:

snmp bind <label> getnext [command]

The <label> for this function should be restricted to be either the oid of a table, or the oid of a table element.

The %o expansion and %i expansion should not describing the variable that triggered the search, but rather the current position of the search. That is, if the <label> is the oid of a table, %o will be a the oid of a table element, and if <label> is the oid of a table element, %o will always be identical to <label>. %i will be either empty (for searching from start) or (perhaps prefix of, in case of multivalued indices) an index value of the table.

When the seaching process has finally found an instance, any "get" binding should be called. The agent implementer can use the request id and other data, as discussed in one of my other questions, to save unnecessary work in cases where get and getnext bindings are both defined.

> > 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.

Probably nothing (wrong, that is), as discussed above.

> > Juergen >

best regards --peder chr.

Peder Chr. Norgaard Telebit Communications A/S Denmark