[EISA] Proposal for handling control messages between DAC and EINode

[James Hill]

Hey Folks,

I'm currently implementing the code in the EINode for handling control
messages, and I would like to propose a change to the control structure
sent between the DAC and EINode. Currently, we are sending the UUID of
the target probe in the message instead of the probes human readable
name, which should not have any spaces. ;-) Although this approach is
feasible and was decided to reduce the amount of variable length data, I
think it may not be necessary. I think we should send the name of the
target software probe to the EINode, and let the EINode resolve the
probe. I think this is a better approach because:

1. It will reduce the amount of work done by the DAC; 
2. Resolving the probe's UUID at EINode will be more optimal since the
EINode will have to keep track of a LOT of probes on disk, whereas the
EINode's lookup table will be in-memory (and much faster);
3. The EINode will not have to convert the human readable name to a UUID
since it stores the probes by name. ;-) This will prevent the *Tower of
Babel* performance anti-pattern from creeping into our specification and
implementation for this feature of EISA.
4. The current method would require the EINode to parse the EINode's
metadata, which is currently on halt because we need to update XSC. This
is the major showstopper. :-(

These are just a few of the reasons for proposing a new approach. The
current approach for sending a control message to a probe, such as the
heartbeat probe, would like as follows:

[header][options]

Ex. [header][hertz=10]

Where [header] is the standard header for the message, including the
UUID of the probe in binary format. The second block of data is text
format options would parse to changes its hertz. Under the proposed
approach, sending a control message to a probe, such as the heartbeat
probe, would be as follows:

[header][command] 
Ex. [header][heartbeat hertz=10]

This time the header does not contain the UUID of the target probe.
Instead, the probe name is embedded in the second data block (or the
command). If you notice, this look more like a *command* that you
execution from the command prompt, which is what I think we are shooting
for with this features of EISA. The EINode would look at the first
*argument* and determine what probe to forwar the control message. In
this example, it would forward the commnd to the *heartbeat* probe. 

If the proposed approach is satisfactory to everyone, then I would like
to implement handling of control messages in this manner. Please let me
know if there are any question/comments.

Thanks,

James

--------------------------------------------
James H. Hill - Ph.D. Candidate
Research Assistant - ISIS / DOC Group

Department of EECS / Computer Science Program
Vanderbilt University, Nashville, TN

Email: j.hill at vanderbilt.edu
URL: http://www.dre.vanderbilt.edu/~hillj