[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[hyades-dev] Notes from HCE protocol meeting 7/29/04
- From: Allan K Pratt <apratt@xxxxxxxxxx>
- Date: Thu, 29 Jul 2004 10:44:28 -0700
- Delivered-to: email@example.com
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@xxxxxxxxxxx
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
-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM