[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] Protocol Layer Zero, rewritten




I tried to step back and evaluate Andy's proposal without dragging along
too much baggage from the current implementation. I hope that was the
right approach. It makes me ask questions I wouldn't ask if we're just
formalizing the current impl with some tweaks. Also, I just commented on
your most recent (shorter :-) proposal and haven't yet made it through the
rest of longer document. IOU.

1. Architecture
This is a meta-issue. We haven't really defined the component architecture
for the collection framework, so it makes it hard to talk consistently and
unambiguously about things like who connects to who, who offers what
services, etc. I think everything we write during this effort could
benefit from defining some of the terms we're using. We talk about the
"engine", the "server", "client" and "agent", but none of this is clearly
defined anywhere. For example:

-  What's encapsulated by the Hyades Collector Engine (or DCE :-). Is this
whole framework of client (workbench)
   API's, RAC (or it's replacement) and agent interfaces? From Andy's use
case diagrams, I think the answer
   is yes, but it might be worth defining somewhere.
- What do we mean by "server"? Is this the same as the engine?
- If engine != server, what is the "engine"?

Does a client semantically connect  to a server or to an agent? Is the
existence of the man-in-the-middle (i.e. RAServer) a required part of the
HCE specification or an implementation detail? It affects the terminology,
IMO.

I'm not trying to suggest that the burden for defining this should be
Andy's. But it would be helpful to know specifically what some of these
terms mean in Andy's document.

2. Usage of SOCKET_CONNECT & PIPE_CONNECT

There's verbage in the descriptions of these two message types to the
effect that only clients are "expected" to connect via sockets and only
agents are "expected" to connect via a pipe. We're either blurring the
line here between specification and implementation or we're being a little
too wishy washy. :-)

Does the specification require that only clients use sockets and only
agents use pipes? If so, let's just say so. It doesn't preclude loosening
the restriction at a future time.

I don't think we can straddle the fence - if I'm writing a client, it
doesn't help me to know that the underlying implementation *might* support
a pipe connect.

Conversely, if we don't intend to restrict the usage, then we probably
shouldn't talk about "expectations" in the message definition.

We've mentioned clients & agents, but not servers in this discussion of
expectations. Yet servers are mentioned in the objec type discussion. If
we leave this verbage in about expected usage, we need to mention servers
somewhere. How do they connect?

3. Object ID in  SOCKET_CONNECT & PIPE_CONNECT

I'm puzzled about the object id field. It is "not used for clients". Why
not? Why do I need to be able to identify an agent or server, but not a
client? Again, this feels like the current impl is influencing the
definition more than it should.

4. DISCONNECT & DISCONNECT_ACK

Neither of these messages has a payload. If I understand correctly,
DISCONNECT is a disconnect request from the connection initiator (client,
agent, other server). Is there no need to identify the connection? Seems
like it should. If not, then why is a connecton id included in the
CONNECTION_COMPLETE message? I guess the connection is implicitly
identified by the pipe/socket it comes in on. But I still wonder in that
case why a conn id is used elsewhere in the messages.

Ditto with the ack. What disconnect am I acknowledging?

Or does the implied architecture limit you to a single connection?

5. Object id's and server id's

We're specifying that the object id for an agent is its pid. Is it really
the pid or is the pid an impl of the requirement that it be a unique id?
Again, I'm nit picking because I'm trying to find the line between
specification and implementation.

If it is a unique id we're after, does the pid necessarily satisfy this
requirement? What if I have more than one agent running in the same
process? Does the architecture preclude this kind of implementation? What
is the OID used for?

Where do server id's come from? How is the namespace of all server id's
managed?

-Kim

Kim Coleman
PurifyPlus Development
IBM Rational Software, Cupertino, CA
(408) 863-4094 (T/L 560)
kcoleman@xxxxxxxxxx