[hyades-dev] Notes from HCE protocol meeting 7/29/04

[Allan K Pratt <apratt@xxxxxxxxxx>]

Notes from the Hyades HCE protocol meeting, July 29, 2004

From Intel: Hoang Nguyen started the call, Andy Kaylor got there late. 

Attendees included Allan Pratt, Joe Toomey, and Kent Siefkes of IBM / 
Rational, plus two people from CompuWare whose names I didn't get. There 
might have been others.

These notes are by Allan Pratt, apratt@xxxxxxxxxx.

We decided that the weekly meetings going forward should be scheduled for 
9:00 AM Pacific Time on Thursdays.

Reviewing version 0.5 of the protocol specification document:

Allan asked about specified character encoding for text-based messages. 
The HCE protocol is binary, not text-based, described in terms of C 
structs, so this does not apply to the HCE protocol itself. But it will 
apply to many agent commands, and Allan thinks it's worth discussing 
somewhere in the specifications. If something is said to be "text" (like a 
command line, or an environment variable setting), are the characters 
ASCII, or UTF-8, or UNICODE, or EBCDIC, or whatever's "natural" in the 
local architecture, or something else? If we don't specify then every 
agent author will have to invent and document their own solution.

Andy brought up a question he's struggled with: how to get unique 
interface id's for agents. He hasn't come up with a good way for the agent 
author to create a unique id for himself. One approach is to have a 
registry at eclipse.org, but that requires administration. The "registry 
at eclipse.org" system has a side benefit of letting us (eclipse.org) be 
aware of developers playing in this space. Allan doesn't think that's a 
compelling reason to create this open-ended future administration burden.

A common (and notably Eclipse-wide) approach to distributed ID uniqueness 
is to use reversed domain names like "com.ibm.something" as is the 
convention with Java package names. Every contributor of note will already 
have a domain name and can manage their own namespace. The interface ID is 
part of every message, and the string would be bulky and inconvenient; if 
we go this way, the agent would pass its key to the HCE at startup and get 
a session-scope "key" (a unique int) in return to use as its interface id 
in messages. Andy worried that this would be a burden to agent authors, 
since a single agent might talk to multiple HCE instances and would get a 
different key from each. Allan thinks this is a non-issue: any agent 
already has a per-HCE data structure, to hold the socket number for that 
HCE if nothing else. This approach does add a string to the protocol, so 
character encoding becomes an HCE issue. (See above.)

Another ID-uniqueness suggestion involved using the reserved, fixed IP 
address assigned to a given company. Allan thinks this would work for 
large companies like Intel and IBM, but it would present a problem for 
smaller shops with outsourced network hosting and dynamic IP addresses.

Someone noted that the diagram shows client -> agent communication, and 
asked whether the picture is the same in reverse. Andy says yes.

Someone noted that the current Hyades RAC uses shared memory to 
communicate with agents, and would the new system be able to do that? Andy 
says it's been considered, but he hasn't got anything specified.

Andy mentioned that there is talk of specifying an agent-to-agent 
communication path as well.

Allan asked whether this system includes client-to-HCE communication for 
querying the HCE itself, its capabilities, and the agents it knows of. 
Answer: yes, already in the doc. Also, page 9 has the Agent Management 
Interface with commands for starting agents.

Someone brought up the reference counting of agents. They suggested that 
some agents, once started, don't want to be stopped when the last client 
disconnects. Once a monitoring agent starts, future clients might benefit 
from historical data that's collected during the time that no client is 
attached. We thought of two ways for an agent to achieve this: one is to 
have a flag in metadata saying "don't reference count me; never kill me" 
and the other is to have the agent acquire a reference to itself, so the 
count never goes to zero. The metadata approach has the virtues of being 
explicit and discoverable by clients, and of having the implementation in 
the HCE so it's shared. But it has the disadvantage of being static: it 
doesn't let an agent decide dynamically, based on current circumstances, 
whether it should stick around. We'll probably end up with both: something 
in the metadata which flags those agents which ALWAYS want to be 
persistent, and something in the spec that says an agent can get a 
reference to itself to defeat the reference counting. By mentioning this 
sort of thing in the document, we help lead implementers to consistent 
solutions to common problems.

Allan brought up the topic of agents which can't exist in isolation, those 
which can only exist as part of a target process being observed. He thinks 
it should be possible to express this relationship in the metadata, so a 
client that doesn't have private knowledge of the agent can still start 
and use it successfully. He will draft a document describing the four or 
five types of such agents for the team's consideration. Briefly, they are: 
the JVMPI / JVMTI approach (special command line options), the .Net 
approach (special environment variables), A "wrapper command" (instead of 
"myproc" you run "monitor myproc"), and an agent which starts and runs 
separately but then is instructed what process to watch. 

Andy noted that the HCE protocol document doesn't talk about the agent 
that knows how to start processes. He said he had a preliminary draft but 
it's known to have holes and errors; people asked for it anyway, since 
this is sure to be a central part of the system and needs early 
discussion.

-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM