Peter J M Polkinghorne <Peter.Polkinghorne@gec-hrc.co.uk> said:
Peter> What follows is firstly my exposition of how I understand the
Peter> scotty agent to work - this is currently not fully documented
Peter> and I hope this helps. Following this there are some
Peter> suggested changes.
Your analysis is quite nice. :-)
Peter> Now I have a few comments - mostly they relate to supporting
Peter> the creation of Table entries.
You are correct. Scotty could have better support for SET requests.
Lets see ...
Peter> a) CREATE behaves rather differently from SET - in that it is
Peter> entirely up to the CREATE binding to initialise the Value of
Peter> the Inst. For SET, it is done automaticly. This can lead to
Peter> invalid values existing.
This is already fixed in my sources.
Peter> b) Although there the bindings for COMMIT & ROLLBACK, more
Peter> automated support in terms of either scratchpad / saved / new
Peter> variables would be nice. That is support the default cases.
Peter> So the SNMP semantics of Set PDU atomicity can be better
Peter> supported.
I agree.
Peter> c) However may be I am missing something, since the example
Peter> agents, when tables are created have no rollback or commit
Peter> bindings.
I added commit and rollback bindings without changing the
examples. That's why they are still broken with regard to the SNMP
`as if simultaneous' semantics.
Peter> d) For scalars to have true atomicity (assuming read/write
Peter> rather than read/create): the following bindings are needed:
[... some code deleted ...]
Your code is correct and I agree that it is far too complex to expect
that every Tcl programmer will for each simple SNMP variable.
Peter> e) And its even more complex for a Table entry. Basicly you
Peter> have to record Table entry status and on rollback remember
Peter> whether to unbind or restore saved values. The creation can
Peter> be triggered potentially any variable.
I think there is no general solution for tables. So we need to do some
checks using bindings, but we should have a default behaviour that
makes sense in most cases.
Peter> Finally there is the consistency problem (ie is the table
Peter> entry OK) which ought to be checked once after all the inital
Peter> sets have been done, but before the Commits or Rollbacks.
Peter> However the Scotty agent only allows error reporting on the
Peter> SET or CREATE or GET events alas.
Peter> So consistency checking is hard since there is no second phase
Peter> check point. My suggested idea is to allow COMMIT to report
Peter> an error & be reinvoked as ROLLBACK or event new event of
Peter> CHECK. See CMU RESERVE1 & RSERVE2 sequence for agent PDU
Peter> processing.
I agree again. After some more thoughts about your mail, I have come
to the following conclusion:
1) I will split the PDU processing into two different functions, one
doing get/getnext/getbulk processing and the second doing set
processing. (This will make the code a bit easier to understand.)
2) I will add a CHECK binding that will be evaluated after the first
loop over the varbind list while processing set requests. The check
binding may return an error result to signal consistency problems.
3) The commit/rollback bindings will be invoked after the CHECK
bindings have been evaluated, depending on the result of the
previous PDU processing.
4) I will add some code to get the atomicity described in your mail,
point d). Yesterday, I though about creating default bindings similar
to the ones you described when instantiating writable variables.
Creating default bindings would allow an advanced hacker to redefine
them. However, today I think that it can't hurt to have this behavior
hard coded in the agent. Therefore, you do not have to care about set
bindings until you are required to do some side effects or your are
required to maintain dependencies between MIB variables.
Will these changes solve your problems? Should I do anything else to
make `as if simultaneous' SNMP set processing easier?
Juergen