RE: [hyades-dev] The proposed layer 0 of the new Hyades infrastructure

[Michael.Norman@xxxxxxxxxxxxx]

RIchard/Andrew

In this it looks like you are thinking of opening a socket conenction 
between each pair of communicating entities.  Is this the plan? or is 
the DCE to implement some multiplexing to avoid the n^2 socket blowup 
and the 0(N) select overhead in fine-grain peer-to-per stuff? If this is 
the case, then there's probably some other stuff you'll need to stick at 
layer zero to get the multiplexing to work efficiently and/or fairly and 
you may even need Merlin and Schweitzer's algorithm (or something 
equivalent) to avoid deadlock.

Antony knows about this stuff if you want to talk to him.  Thee's a Java 
implementation of it in the bottom of the choreography engine which does 
a lot of fine-grain peer-to-peer stuff.  We should try and keep the 
protocols the same as those in the DCE as high up the stack as we can.

Mike




-----Original Message-----
From: andrew.kaylor [mailto:andrew.kaylor@xxxxxxxxx]
Sent: Wednesday, April 28, 2004 6:21 PM
To: hyades-dev
Subject: RE: [hyades-dev] The proposed layer 0 of the new Hyades
infrastructure


Richard,

This (your envelope description) is what I had intended with the
"Message Block" section of my document, although I expressed it (in less
detail) in terms of the structure that this stuff gets read into rather
than the order in which it comes across the wire.

I inadvertently left off the magic number, but I agree that it is needed
(and makes sense to be outside the structure).  I'm not so convinced
that we need both major and minor version numbers for the protocol.  For
the most part, I expect changes to be handled by variations in the
header ID for global command format changes or interface IDs for more
specific changes.  For what little is left a single version number would
seem to be sufficient, and even that may be able to be handled by
changing the magic number.

But basically I'm open to whatever you think is necessary in the
envelope.

As for the "returnPipeName", you have understood my intention correctly.
That was an oversight in my documentation.

The lack of some sort of failure notification in the connect messages
was more of an oversight in my thinking.  I was thinking that if the
connection failed we'd have no way to say so, with even the security
authorization taking place outside the command exchange.  Yet I see that
you are probably right in that there may be cases where the connection
"works" but the server chooses to reject it.

-Andy

-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx]
On Behalf Of Richard Duggan
Sent: Wednesday, April 28, 2004 8:39 AM
To: hyades-dev@xxxxxxxxxxx
Cc: hyades-dev@xxxxxxxxxxx; hyades-dev-admin@xxxxxxxxxxx
Subject: Re: [hyades-dev] The proposed layer 0 of the new Hyades
infrastructure





Andy,

Thanks for taking the time to write this up.  This is good bases for
communication.

When I think of level 0, the envelope is specifically what I have in
mind.
What does the envelope look like?  Specifically, how do we determine
this
is a Hyades message and how to handle it.  Here is what I had in mind:

byte0-byte3 :  Magic Number ? a magic number to identify this is a
Hyades
message.  Strictly used to ensure we do not try and process garbage.
For
example, if a message is corrupt we spin until we find the next instance
of
the magic number and we tray and continue processing from this point

byte4- byte7:  Protocol Major Version ? this is a migration mechanism
that
allows us to change the protocol as we move forward.  If sizes of
various
fields change, etc.  The version can be used to manage the change.

byte8-byte11:  Protocol Minor Version  - continuation of byte4-byte7.
The
idea here is we can make our code more granular this way to handle minor
changes separate from huge overhauls.

byte12- byte15:  Flags ? miscellaneous  flags that allow us to specify
behaviour of the reader of the message.  A concrete example of a flag is
to
specify whether this message requires an acknowledgement that it has
been
received in full.

byte 16-byte19:  Payload size.  This is the size of the payload that
starts
at byte 20.

I have left out the ticket and key.  The ticket is useful when you are
using an acknowledgment system as it identifies the message.  The key is
a
bigger question.  Looking for some feedback of what the expectation is
there.

Once you get closure on the envelope (level 0), you can start looking at
the routing information and behavioural sequencing.   I tend to qualify
this additional capability as level 1, and you have provided a good base
of
behaviour in the document.  Finally, I think all the services which have
customized protocol specifications plug-in at level 2. The benefit of
handling these separately is that you get to handle the portions of the
protocol in a very fined grained manor.  A negative impact is that you
start having a bit less efficiency on the wire as you will start having
multiple length and possibly version identifies for each layer of the
protocol.


Other issues:

1.  I assume the returnPipeName in CID_PIPE_CONNECT is the name of the
pipe
that the endpoint initiating the conversation will use to reading the
protocol  from.

2.  Is there a command when a CID_CONNECT fails.  For example, if a
client
is not allowed to connect for some reason such as security.  Currently
there are use cases for the green threads through the connection phases
but
none for when things go wrong.



Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396



 

             "Nguyen, Hoang M"

             <hoang.m.nguyen@i

             ntel.com>
To 
             Sent by:                  <hyades-dev@xxxxxxxxxxx>

             hyades-dev-admin@
cc 
             eclipse.org

 
Subject 
                                       [hyades-dev] The proposed layer 0

             04/27/2004 12:22          of the new Hyades infrastructure

             PM

 

 

             Please respond to

                hyades-dev

 

 






I sent this document on Andy Kaylor?s behalf.
Any early comment or feedback is always welcome and appreciated.

Regards,

 [attachment "Hyades Protocol Layer Zero.doc" deleted by Richard
Duggan/Toronto/IBM]

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev
_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev