[evla-sw-discuss] MIB to screen communications"

[John Ford]

Barry Clark writes:
 > I've been looking at the communications between the MIB and screens 
 > package.  All possible ways of doing it seem to me to have significant
 > disadvantages.

<snip>

I agree with much of what Barry said in this post, but I think that
the GBT M&C system (Ygor) has most of what you need.  Each of our
systems has a server on it that knows which monitor points are on it,
and how to encode the data.  They also use the same method to encode
control parameters.

The client program, which can be anything from a TCL script, Glish
client, C++ program, or what have you, can pick up the
encoding/decoding information, along with all the relevant labelling,
limits, etc. from a shared library that resides on the host.  This
works well, as standard programs can be used to log data or display
it, from disparate sources.

We have one program that can attach to any monitor point, and write
out that data to the disk.  Any number of these can connect to the
monitor point (sampler2Log.)

One program that can attach to any manager and twiddle parameters,
read the monitors, or turn it on and off.  Any number of these can
connect to the device (DeviceExplorer.)

The device end of the connection is responsible for packaging up the
data and sending it off, but not for any display formatting, etc.  The
host end of the connection decides what to do with the data.  The
opposite holds true for control parameters.

Custom control screens for each device can be constructed easily using
this method, because all the encoding and decoding is done for you.
Note that custom control screens are not required for debugging and
engineering use, as the parameters can be directly controlled by the
Device Explorer.

Note that the M&C implementation uses RPC as the underlying protocol.
I'm not sure that's the best way to go, but it seems to work pretty
well.  It's also fairly easy to replace RPC with some other protocol.
I haven't seen one yet that I really like, though.  I'm starting to
get a bit stale with the latest alphabet soup of protocols.

Ygor does have the advantage of being in production on several
telescopes (GBI, GBT, 85-3.)

John

 > 
 > 1.  VT100 screen implementation, a la VLBA.  This doesn't fit well with
 > Rich Moeser's discovery and hierarchy scheme, which is regarded
 > as highly desirable.  Also, we would not consider this for logging monitor
 > data, meaning that we would have to have a disjoint set of software for
 > reading the monitor log.
 > 
 > 2.  HTTP, XML, and other ascii based implementations.  Very verbose, 
 > so we might not want to store these things in the monitor log.  Also, 
 > this is not very easily adaptable to the sort of monitor data version 
 > control that we have found valuable on the VLBA.  (On the VLBA, when
 > (not "if" but "when") we change the format of an entry in the monitor 
 > log, we write a routine that converts the old version to the new, and 
 > use this routine to make sure the software dealing with the 
 > monitor data extraction (or with real-time data display in this case)
 > has been using the new form well before it actually gets logged in the
 > new form.  Stacking these routines means very old monitor data remains
 > readable with no additional maintenance effort.)
 > 
 > 3.  RMI.  In the standard invocation this goes by TCP sockets, which 
 > makes things slow and difficult to recover from a network glitch.  I 
 > don't know if this could be implemented over a UDP socket, though just
 > serializing the object and broadcasting it could obviously be done
 > (wastes a lot of space retransmitting all the methods).   Not clear
 > to me how this would do as an archive format.  Storing a Java serialized
 > object in the monitor archive is probably pretty inefficient.  The 
 > format updating mentioned above can be done, but, as usual with Java,
 > it requires a lot of boring typing that has to be done exactly right.
 > 
 > 4.  XDR.  This is developed for RPC, so rpcgen will put together a 
 > program to stuff your data into a message, blast it off to somebody
 > else, decode it at the other end, execute the command, and ship the
 > answer back.  One doesn't have to use the whole schmear, and can put
 > a program together oneself to pack and unpack data.  But it does get
 > to be work.  It is also not very efficient.  To simplify conversions,
 > they force all data items to occupy a multiple of four bytes in the
 > eXternal representation.  Since we will have a lot of stuff which has
 > natural lengths of two bytes (eg A/Ds), stuff will get expanded.
 > We might well have to write the underlying conversion routines for
 > Nucleus, since it doesn't come with RPC, but not a real big deal.
 > 
 > 5.  Straight binary with byte reordering.  This is commonly done for 
 > all the stuff in the various network protocol headers.  Macros and
 > definitions for bytes, shorts, and ints are given, eg, in Sun's
 > /usr/include/sys/byteorder.h.  We'd have to extend it to floats.
 > This is the most compact form, but it's a little non-trivial to 
 > use.  We can't just slap a structure definition on top of the data
 > stream, as we do with the VLBA, because we want to accomodate a larger
 > variety of machines, with different structure alignment requirements
 > as well as different endianness.
 > 
 > My personal tendency would be to take approach 5, because it uses almost
 > no fancy software, and there are therefore fewer bushes behind which 
 > problems can lie in ambush.  Anybody out there have any other approaches,
 > or a compelling argument for another one of these?
 > _______________________________________________
 > evla-sw-discuss mailing list
 > evla-sw-discuss at listmgr.cv.nrao.edu
 > http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
 >