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

[Sutherland, Hunt A (GE, Research)]

James,

I like your proposal - agreed.  Some comments for clarification.

-----Original Message-----
>> From: eisa-bounces at list.isis.vanderbilt.edu
[mailto:eisa-bounces at list.isis.vanderbilt.edu] On Behalf Of James Hill
>> Sent: Thursday, December 11, 2008 12:51 PM
>> To: eisa at list.isis.vanderbilt.edu
>> Subject: [EISA] Proposal for handling control messages between DAC
and EINode
>> 
>> 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.

Agreed.

>> I think we should send the name of the target software probe to the
EINode, and let the EINode resolve the probe.

Agreed.

>>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);

Agreed.

>> 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. :-(

Agreed.
>> 
>> 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:
>> 

I expanded the notion of the text format.  I think that the probe name
would be optional but required when the command is directed to a probe.

   {header} {[<probe>] <command,options>}

    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 forward 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
>> _______________________________________________
>> EISA mailing list
>> EISA at list.isis.vanderbilt.edu
>> http://list.isis.vanderbilt.edu/mailman/listinfo/eisa
>> 
>> 
>>