| Re: [hyades-dev] DCE interface definitions |
Andy,
I have gone through this in some detail. Here are some comments:
1. The Authentication commands may not be necessary. I originally put
these in the first version of the protocol when we wee using connectionless
oriented messages. The authentication key was on every message. This
isn't really secure in the end and we have since looked at SSL as the only
acceptable mechanism for security.
2. I believe that the less commands we build into the protocol the better
off we will be. I envision there may be a need to structure the protocol
in layers, where, at the lowest level, there is literally just the header
information and a payload. We can then add subsequent layers and
processing handlers for these layers. This allows us to incrementally add
more function and provide easier migration. It also allows for incremental
scalability. If someone has a need for a very lightweight protocol the
subsequent layer can be highly optimized, if there is a need for more
dynamic protocol content then that is achievable as well.
3. We need properly document the semantics of the protocol and the data
types it supports. Is the protocol normalized/cononicalized? What is the
endianess, most significant bit, of integers? Is there a need for floating
point numbers? If so, how are they represented. What about strings? Is
there only one type of string that supports all encodings. What is the
format of this string. Is there array types? etc.
4. Don't be too concerned with the impacts on existing code that people
have written to deal with messages (as indicated in the follow up note you
sent). On the client side, nobody is writing code at this layer. Hyades
defines interactions at the execution.core layer and the protocol is
abstracted from them. As for the agent side, agents deal with a very small
subset of the existing protocol. we should be able to map very easily. My
main goal to provide a protocol that scales to all of our consumers needs
and addresses some of the issues which were never quite done correctly in
the first version.
5. As a general structure naming convention, instead of naming things
ra_*****2, we can change this to be something like hdc_***. I'm not a big
fan of the dce_*** tag as there are standard distributed computing
environment API's that use this convention.
6. Can you give a detailed blurb on each of the fields in the main
protocol header? I'm looking for detailed semantics so I can better
understand how each field is used in the routing or messages.
7. I am assuming that we no longer need to support multiple commands in
the same message. Like I mentioned earlier, this was in the initial
protocol as at one point n time this was not connection oriented. I do not
believe there is a need, but I want to ask the question explicitly to make
sure everyone is aware of this design point.
8. Handshaking. Is there a need for any special handshaking when a
connection occurs. I think this is highly desirable due to issues that can
arise when you start adding support for such things as security.
What I would like to achieve in the short term is to hammer out the
semantics of the protocol. I would like to get closure on what I would
term 'the level 0' support. We can then step up one layer of abstraction
and start looking at commands, and flows of commands.
hope this is of some value,
Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396
"Kaylor, Andrew"
<andrew.kaylor@in
tel.com> To
Sent by: <hyades-dev@xxxxxxxxxxx>
hyades-dev-admin@ cc
eclipse.org
Subject
[hyades-dev] DCE interface
04/15/2004 08:08 definitions
PM
Please respond to
hyades-dev
I've attached my first draft of the interface for the DCE itself. It's
still rough at this point, and I'm not entirely sure it shouldn't be
rethought to make more sweeping changes. There were a lot of commands that
I wasn't sure how they were being used so I left them pretty much as they
were. I'm not sure how drastic a break we want to make from the old
protocol and how much of he DCE internals we are willing to rewrite.
I've made the definitions in the form of a C header file for clarity.
Where types are used that aren't defined here, I intend the current
definition.
The real items of interest in this file are a few new commands that I've
added (QUERY_AVAILABLE_AGENTS, QUERY_AGENT_INTERFACES, LAUNCH_AGENT) and
the definition of a new command structure (header plus data). Data
structures for the new commands, along with a comment giving a hint as to
what I have in mind, begin on line 152.
I'd like to follow this up with similar first passes for a standard agent
interface, an EXE controller interface, and an environment information
interface, but I'm hoping to get feedback on this quickly to see if you
think I'm proceeding too conservatively or if this looks like it's
basically going in the right direction.
-Andy(See attached file: Protocol.ZIP)Attachment:
Protocol.ZIP
Description: Zip archive