"Peder Chr. Norgaard" <pcn@tbit.dk> said:
Peder> This may very well be a useful extension; it may even solve my
Peder> problem but in a *very* inelegant way. I would have to build
Peder> one jumbo script with knowledge about both the entire MIB and
Peder> all the functions to lookup next rows. I would not be able to
Peder> use knowledge and techniques which I am quite certain, are
Peder> already present in the current implementation.
Yes, you may get into problems if you do not know that there are
instances `between' the dynamic tables that exist permanently.
Peder> One quite simple change, solving my problem with respect to
Peder> the GetRequest would be a change of the semantics of the
Peder> implementation of GetRequest. For now, the implementations
Peder> looks into the instance tree and reports noSuchName if the
Peder> specified instance is not present. I have not checked what
Peder> happens if the "get" callback removes an instance after the
Peder> agent has decided that it is there!
It crashes if you delete the instance in the callback. I guess I have
to fix this. :-(
Peder> I suggest that the relevant callback commands are called
Peder> always, regardless of the presence of the specified instance.
Peder> *After* the callbacks have run, the agent can test for
Peder> presence of instance and report noSuchName if the instance is
Peder> still not there (or if it has been removed by the callback,
Peder> referring to the discussion below).
This does not work as the callback doesn't let you know which instance
is actually read by a getnext request. You will have the again the
problem that your script has to know which instance will be read by
the getnext request. You therefore propose the following:
Peder> No doubt, correct processing of GetNextRequests is a bit more
Peder> complicated. I have been thinking a bit: there must be,
Peder> somewhere in the current implementation, a mechanism for
Peder> getting next instance from the instance tree. What we need is
Peder> a way to specify callbacks to be invoked by this mechanism
Peder> when it searches past instances whose presence may change over
Peder> time - that is, elements of conceptual rows. Several such
Peder> callbacks may be called in one search, if the search passes
Peder> wholly empty tables, or starts with the a fully specified
Peder> instance that happens to be in the last row of a table.
Peder> I suggest you implement a binding like:
Peder> snmp bind <label> getnext [command]
Peder> The <label> for this function should be restricted to be
Peder> either the oid of a table, or the oid of a table element.
This might work for getnext, but it is not easy to implement. You
still need some logic to handle simple get and set requests. What
happens is that we end up with two passes through the varbindlist for
getnext request and one pass for get or set requests, which is
somewhat expensive for those agents that do not need to handle this
kind of 'dynamic tables'. I am not fully convinced if this is a good
solution to the problem.
Again, if you know that there is an instance foo before the 'dynamic
table' fooTable, you can do the right thing just by inspecting the
oids before the varbind list is processed:
proc UpdateInstances {vbl t} {
foreach vb $vbl {
switch $t {
getnext {
switch -glob [lindex $vb 0] \
[mib oid foo]* { UpdateFooTable } \
[mib oid fooTable]* { UpdateFooTable }
}
default {
switch -glob [lindex $vb 0] \
[mib oid fooTable]* { UpdateFooTable }
}
}
}
}
$s bind "" begin { UpdateInstances "%V" "%T" }
If you do not care about updating the table a bit too much, you can
even use any instance before the dynamic table that is known to exist
all the time.
I have hacked some support for this solution yesterday by adding a
begin and an end binding that is called before PDU processing starts
and after PDU processing has finished. It should not be too difficult
to add another escape substitution %T which expands to the PDU type.
This may not be the ideal solution, but this one is easy to implement
and does not add complexity to the agent for all those cases where you
do not have this problem. Comments?
Juergen