[evla-sw-discuss] Communications - MIB to screen

[Barry Clark]

This is a suggested module to provide communications between MIBs and
screens.  I had previously suggested the bottom layer, which was felt
to be an insufficient, and possibly invidious, description.  This is
a more fleshed out version, with three layers, despite the fact that
the higher levels have not been carefully thought through, to give a 
better overview of how things might work.

The first screen we should work on should be getting Rich's existing screen
into a productive general purpose tool.  The path beyond there is less
obvious, whether this screen can be extended to fill all the needs, or
whether more complicated devices will require separate screens.  In the
latter case, we can still predict that they can be based on similar
communication philosophies.

I specifically address here the following types of communication from the
MIB:
    Monitor point to be snooped by screen
    Monitor point to be logged
    Monitor data to verify command

BOTTOM LAYER

I suggested a bottom layer of binary communications via broadcast 
datagrams, with data constued in network byte order, with types byte,
short, integer, and float (the last being an extension to the "network
byte order" convention), with datatype alligned with their lengths
(that is, shorts on even offsets, integers and floats on offsets 
divisible by four).


SECOND LAYER

A record (or packet, or whatever you want to call it) would consist of
a Preface and a collection of Monitor-points.

The preface:

struct Preface 
    {
    int originator;		/* for a MIB, inet address would be a reasonable
				   choice of itentifier */
    struct Timetag
	{
	int MJD;		/* modified Julian day */
	float time;		/* fraction of a day */
	} timetag;
    short length;		/* length of record in bytes */
    short intent;		/* see below */
    short origen;		/* ditto */
    short software;		/* a software revision number */
    };

The "intent" would be a set of enums at least including
    Monitor point to be snooped by screen (and ignored by logger, etc)
    Monitor point to be logged (logger can write directly to disk)
    Monitor data to verify command (data returned to the observing layer
       to verify equiment is configured as commanded by the observing script)

The "origen" would be things like
    Message generated periodically
    Message provided on request

The Monitor-point would begin with a short identifier, and then have a 
structure defined elsewhere.

THIRD LAYER

In order to interpret one of these records, one must know the structure 
(and maybe units and scaling) of the monitor point data following the 
preface.  (A lot of them will just be "volts", and a short, but very much 
more complicated structures could be defined.)  The screenside third layer 
simply asks the MIB for the description of the monitor point.  (This is 
what I meant in the slide I showed May 28 that the screen could ask the MIB 
"What are your monitor points?")  The third layer software would then turn 
the monitor point into whatever form the user wants.  (The classic object 
oriented approach would be to create a flock of little Voltage objects, 
or whatever, and hand them back to the caller, which seems like superfluous 
fol-de-rol to me, but whatever turns you on.  I'd be inclined to have the 
third level software smart enough to know what monitor points the caller 
is interested in, and supply only them, but again, whatever turns you on.)

The smarts of the third layer would be in the protocol used to describe
the monitor point.  I have no opinion of what that should be at the moment,
but I should think XML would be an interesting candidate, with a purchased
XML parser.

This interface protocol does involve more work than some packaged 
implementations, for instance RMI.  On the other hand, it also provides 
a general solution of considerable flexibility.  For instance, using
this for monitor data logging as well is straightforward - the third layer 
there has to look up the appropriate monitor point description in a historical
archive, keyed by device identifier and software revision number, instead of
just asking the MIB.  The monitor data logger need know nothing about
the properties of the data it is being asked to log, and the MIB need not
have a second description of data for logging purposes.